投影中属性的顺序是否会影响SQL查询的执行速度?

时间:2016-01-19 19:02:29

标签: mysql sql-server database performance projection

假设我有一个包含A,B,C,D,E,F,G,H,I列的表,我只需要选择A,C,F,I列(它可能是如果表有更多列,我还需要检索更多列。)

我的问题是,如果我按照升序列索引号(例如A,C,F,I)保留要在投影中检索的列的顺序而不是在完整的随机顺序(例如F,A,I,C)。为什么?

我理解顺序访问比随机访问更快,但是我的例子中没有一个是连续的,所以我不确定这两个投影顺序的性能差异是什么。

谢谢。

3 个答案:

答案 0 :(得分:1)

简答:NO。

答案很长:这取决于。

一般情况下,如果不知道您使用哪种产品,则无法回答此问题。

输出列的

排序无关紧要。

在大多数基于行的关系数据库(包括Microsoft,PostgreSQL和Oracle)中,输出列的排序没有明显区别。这是因为行数据是按块方式从内存中读取的(例如,以8kB或32kB块为单位)。读入内存后,处理非常便宜。

输出列的

数量可能会有所不同,尤其是在使用柱状(基于列的)存储构建的数据库中。此外,基于行的存储也很重要(仅仅因为内存处理成本和数据传输成本)。

请指明您是否有特定的数据库引擎。

答案 1 :(得分:0)

在SELECT语句SELECT A,B,C和SELEC B,A,C中写入列的顺序完全相同。这绝对是无关紧要的。

重要的一件事是天气与否,如果你只选择一个有100列的巨大桌子中的3个columsn。如果在A,B,C列上有一个复合非稀疏索引,数据库引擎可以使用它来避免执行完整的行读取。

如果你在SELECT语句中引用了A,B,C列的索引,那么可能......数据库引擎可能决定最好的办法是执行一个仅索引计划,而不需要加载所有字节涉及100列的单个DB行列。

随着说。 您在FROM子句中声明TABLES的顺序根本不相关。

您通常应该在FROM子句中将表命名为您认为具有更多选择性谓词来过滤数据的表格,并且您自己应该实现嵌套循环连接。

我见过像HSQL这样的数据库,其数据库引擎优化无法使用我创建的所有适当的索引,具体取决于我在FROM子句中命名表的顺序。 这取决于如何实现数据库查询优化以及它将探索多少个查询执行计划。在FROM子句中以适当的顺序编写表将帮助您。

了解如何规划索引以调整查询。

祝你好运。

答案 2 :(得分:0)

  

我的问题是,如果我按照升序列索引号(例如A,C,F,I)保留要在投影中检索的列的顺序而不是在完整的随机顺序(例如F,A,I,C)。为什么?

可能,但它不太可能是重要的,它将根据实施情况而有所不同。 MySQL和SQL Server可以很容易地得到完全不同的答案。

例如,我对SQL Server的理解是,它以称为页面的固定块读取磁盘,其大小为8千字节。对于LOB的一些例外,不允许单行跨越多个页面,这会产生8060字节的限制。如果您的数据超过了该数据并且您没有使用LOB,那么您实际上必须创建另一个表。因此,无论您做什么,当SQL Server从表中读取记录时,它都会读取整个页面,从而读取整个记录。

现在,有很多事情可以改变发生的事情。覆盖所有列,稀疏列,LOB等的索引将显着改变数据在表中的存储和访问方式。但这些都不会受到你订购事物的影响。查询引擎的部分工作是确定从磁盘检索数据的最有效方法。

底线: I / O比内存中这些列的排序成本高出几个数量级。除了一个可能的人为设想的例子之外,我无法想到这是编写查询的一个考虑因素。