SQL 查询优化：SELECT * FROM Persons 真的比 SELECT * FROM Persons WHERE City='Sandnes' 慢很多吗？ [关闭]答案

【问题标题】：SQL Query Optimization: is SELECT * FROM Persons really that much slower than SELECT * FROM Persons WHERE City='Sandnes'? [closed]SQL 查询优化：SELECT * FROM Persons 真的比 SELECT * FROM Persons WHERE City='Sandnes' 慢很多吗？ [关闭]
【发布时间】：2011-12-22 19:05:44
【问题描述】：

我有一个关于 SQL 查询速度快多少的问题

SELECT * FROM Persons WHERE City='Sandnes'

来自查询

 SELECT * FROM Persons

是吗？

来自网络上的各种来源的共识是，通过更过滤的查询可以提高性能，但它们似乎从未变得具体。

我知道答案取决于数据库有多大，所以假设有三个数据库，一个只有 1000 条记录，第二个有 1M 记录，第三个有 10M 记录。假设记录只有几个字节大，所以这些数据都适合服务器 RAM。

我可能会看到速度上的差异有多大，比如百分比？即使是一个大概的猜测也是有帮助的。

我正在使用 Microsoft SQL Server，但这不重要。

【问题讨论】：

看起来你应该自己衡量一下。
如果我知道答案，我不会问社区。你有没有衡量过它，或者只是凭信心接受它？
对地址表做了一些冒烟测试，100 万行；只是一个普通的SELECT * 需要 21'350 次读取和 13'695 毫秒的执行时间； SELECT * WHERE City = .... 提供 1'690 次读取和 169 毫秒的执行时间。
谢谢马克！这就是为什么我不是一个真正的 SQL 程序员，而是在电视上玩一个……并在这里问这个问题！ :)

标签： sql query-optimization

【解决方案1】：

我最喜欢的答案：“一切都取决于”！考虑一下：你有一个关于 city 的索引并且查询优化器使用它，所以你最终会从索引到表进行一系列查找，因为你正在请求所有列 (*)。如果索引不是很有选择性（例如，大多数记录都在特定的“城市”中），那么这将比索引具有选择性（例如，在选定城市中只有一小部分）慢得多，并且可能比完整的表慢扫描。因此，如果您的统计数据由于任何原因不准确，那么数据库返回过滤后的记录集可能需要比整个表更长的时间。回答您的问题的唯一方法是使用您的数据、软件和硬件进行基准测试。

【讨论】：

非常非常有趣的彼得勋爵——这就是我问这个问题的原因。 100 万年来，我从未想过这对于 READ 是正确的（对于 CRUD 操作，我已经读过索引会减慢您的速度，但对于读取却不是）。顺便说一句，这是一个实际问题，现在的建议是在 WHERE 之外为某个列添加“BETWEEN”子句——这可能会进一步减慢搜索速度吗？如果添加越来越多的条件？此外，对于这些数据，CITY 字段似乎不是同质的，而是分散开来的——因此它将有助于加快搜索速度，一切都一样。