1

SQL 数据库似乎是大多数软件的基石。但是，它似乎针对文本数据进行了优化。事实上，在执行任何涉及数字数据（特别是整数）的查询时，将数字转换为文本然后在应用程序和数据库之间以两种方式返回本机格式似乎效率低下。同样的低效率似乎也适用于 BLOB 数据。我的理解是，即使使用 Linq to SQL 之类的东西，这种双向转换也在后台发生。

有没有一般的方法可以用 SQL 绕过这种开销？是否有某些数据库管理系统比其他系统更有效地处理这个问题（即，使用非标准扩展/API）？

澄清。在下面的 select 语句中，IN 之后的数字列表可以更容易地作为 int 的原始数组传递，但似乎无法实现该优化级别。

SELECT foo FROM bar WHERE baz IN (23, 34, 45, 9854004, ...)
4

2 回答 2

2

不要假设。措施。

格式转换不太可能是数据库工作的可衡量成本，除非您将数据库误用作算术引擎。

LOB 的 IO 成本，尤其是具有字符转换的 CLOBS，可能会变得很重要；此处的补救措施是，一旦您知道可能有效的最简单的事情实际上会产生明显的性能影响，那就是尽量减少复制 LOB 数据的次数。使用任何 SQL 参数绑定样式允许您直接在其创建点或使用点与数据库之间传输数据——这通常是将 LOB 绑定到流或 I/O 通道。

但是，在您有办法衡量影响并有测量结果表明这是您的瓶颈之前，请不要这样做。

于 2008-10-20T20:24:56.727 回答
1

数据库中的数值数据不存储为文本。我想这取决于数据库，但它当然不必是也不是。

BLOB 的存储方式与您设置它们的方式完全相同——根据定义，数据库无法解释信息——我想如果它发现有用的话，它可能会压缩。BLOB 不会翻译成文本。

以下是 Oracle 存储数字的方式：

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#i16209

内部数字格式

Oracle 数据库以可变长度格式存储数字数据。每个值都以科学计数形式存储，其中 1 个字节用于存储指数，最多 20 个字节用于存储尾数。结果值限制为 38 位精度。Oracle 数据库不存储前导零和尾随零。例如，数字 412 以类似于 4.12 x 102 的格式存储，其中 1 个字节用于存储指数 (2)，2 个字节用于存储尾数 (4,1,2) 的三个有效数字。负数在其长度中包含符号。

MySQL信息在这里：

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

查看表格 - TINYINT 以 1 个字节（范围 -128 - 127）表示，如果存储为文本则不可能。

编辑：澄清一下——我会说在你的语言中使用看起来像这样的 API（伪代码）

stmt = conn.Prepare("SELECT * FROM TABLE where x in (?, ?, ?)");
stmt.SetInt(0, x);
stmt.SetInt(1, y);
stmt.SetInt(2, z);

我不相信底层协议使用文本来传输参数。

于 2008-10-20T20:18:28.363 回答