sql - 使用 COUNT(*) 或 SELECT * 是个好主意吗？

Question

我多次听说出于性能原因您不应该执行 COUNT(*) 或 SELECT *，但无法进一步挖掘关于它的信息。

我可以想象数据库然后使用所有 列来执行操作，这可能是一个令人印象深刻的性能损失，但我不确定。有人有关于该主题的更多信息吗？

Answer 1

1。关于 count(*) 与 count(something else)

SQL 是声明式的，您可以指定您想要的内容。这不同于指定如何 来获得您想要的内容。这意味着数据库引擎可以自由地以它认为最有效的方式实现您的查询。许多数据库优化器将您的查询重写为成本更低的替代方案(如果这样的计划可用)。

给出下表:

table(
   pk       not null
  ,color    not null
  ,nullable null
  ,unique(pk)
  ,index(color)
);

...所有以下在功能上是等效的(由于count 和nulls 的机制):

1) select count(*) from table;
2) select count(1) from table;
3) select count(pk) from table;
4) select count(color) from table;

无论您使用哪种形式，如果效率更高，优化器都可以自由地将查询重写为另一种形式。 (同样，并非所有优化器都足够复杂以执行此操作)。唯一索引(pk)会比整个表小(占用字节数)。因此，计算索引条目的数量比扫描整个表更有效。在 Oracle 中，我们有位图索引，它也可以压缩重复的字符串。如果我们在颜色列上使用这样的索引，它可能是要扫描的最小索引。 Oracle 还支持表压缩，这在某些情况下会使物理表小于复合索引。

<强>1。总而言之；博士；您的特定 dbms 将拥有自己的一组工具，这些工具可以启用不同的重写规则，进而执行计划。这使得这个问题有些无用(除非我们谈论特定 dbms 的特定版本)。我建议在所有情况下使用 COUNT(*)，因为它需要最少的认知努力才能掌握。

2。选择 a、b、c 与选择 *

在您编写并投入生产的代码中，SELECT * 的有效使用很少。想象一个包含蓝光电影的表(是的，电影在这个表中存储为一个 blob)。因此，您将 awesomesauce 抽象层拼凑在一起，并将 SELECT * FROM movies where id = ? 放在 getMovies(movie_id) 方法中。我不想解释为什么 SELECT name FROM movies 会在网络上传输得更快一些。当然，在大多数现实情况下，它不会产生明显的影响。

关于性能的最后一点是，当查询中所有引用的列(选择的、过滤的)都作为索引(称为覆盖索引)存在时，数据库根本不需要触及表。仅扫描索引即可完全解决。通过选择所有列，您可以从优化器中删除此选项。

关于 SELECT * 的另一件事比任何事情都严重得多，它会创建对表的特定物理布局的隐式依赖。让我解释。考虑下表:

table T1(name, id)
table T2(name, id)

下面的声明...

insert into t1 select * from t2;

...如果发生以下任何情况，将中断或产生不同的结果:

• 任何表格列都重新排列，例如 T1(id, name)
• T1 得到一个额外的非空列
• T2 获得另一列

<强>2。 TL;DR; 如果可能，明确指定您想要的列(最终，无论如何您都必须这样做)。此外，选择较少的列比选择较多的列更快。显式选择的一个积极副作用是它为优化器提供了更大的自由度。