哪个 SQL 查询将在更短的时间内执行 - 使用 WHERE 子句或不使用 WHERE 子句的查询,当:
- WHERE 子句处理索引字段(例如主键字段)
- WHERE 子句处理非索引字段
我想当我们使用索引字段时,查询WHERE
会更快。我对吗?
哪个 SQL 查询将在更短的时间内执行 - 使用 WHERE 子句或不使用 WHERE 子句的查询,当:
我想当我们使用索引字段时,查询WHERE
会更快。我对吗?
正如已经提到的,对此没有固定的答案。这一切都取决于特定的上下文。但只是为了一个答案。采取这个简单的查询:
SELECT first_name FROM people WHERE last_name = 'Smith';
要在没有索引的情况下处理此查询,必须检查表中每一行的每一列 last_name(全表扫描)。
使用索引,您可以只遵循 B-tree 数据结构,直到找到“Smith”。
对于非索引,最坏的情况看起来是线性的(n),而对于 B-tree,它会是 log n,因此计算成本更低。
不确定“使用 WHERE 子句或不使用 WHERE 子句的查询”是什么意思,但大多数情况下,在索引字段上使用 WHERE 子句的查询优于在非索引字段上使用 WHERE 子句的查询,这是正确的。
性能相同的一个实例(即索引无关紧要)是当您在 where 子句中运行基于范围的查询时(即 WHERE col1 > x )。这会强制扫描表,因此与对非索引列进行范围查询的速度相同。
实际上,这取决于您在 where 子句中引用的列、列中的数据类型、您运行的查询类型等。
在某些情况下,主键上的 where 子句会变慢。
最简单的是只有一行的表格。使用索引需要同时加载索引和数据页——两次读取。没有索引可以将工作减半。
这是一个退化的案例,但它指出了问题——所选行的比例。或者,更准确地说,是解析查询所需的页面比例。
当所需的数据在所有页面上时,使用索引会减慢速度。对于非主键,当表大于页面缓存并且访问是随机的时,这可能是灾难性的。
由于页面是按主键排序的,最坏的情况是额外的索引扫描——还不错。
一些数据库使用表的统计信息来决定何时使用索引以及何时进行全表扫描。有些没有。
简而言之,对于低选择性查询,索引会提高性能。对于高选择性查询,使用索引可能会导致性能稍差或性能差,具体取决于各种因素。
这可能取决于您正在编写的 where 子句的类型。在一个简单的 where 子句中,通常最好在您正在使用的字段上建立一个索引(并且 uindexes 可以而且应该建立在比 PK 更多的基础上)。但是,您必须为索引编写一个 saragble where 子句才能有所作为。有关 sarability 的一些准则,请参阅此问题:
我的一些查询非常复杂,并且应用了降低性能的 where 子句。对于解决方法,我使用了临时表,然后在它们上应用了 where 子句。这显着提高了性能。此外,在我加入的地方,尤其是左外加入,提高了性能。