恒真条件聚合（1=1）与count函数的性能对比探讨

嘿，我刚好也碰到过有人这么写代码，一开始懵了半天，后来特意研究了下，给你捋捋这事儿：

首先得明确，你说的没错——SUM(1=1)和COUNT(*)在功能上确实等效：因为1=1是永远为真的布尔表达式，在绝大多数数据库里会被隐式转换成数值1，每一行都会贡献一个1，求和结果就是总行数，和直接用COUNT(*)统计行数完全一致。

然后说说前开发者说的「所有场景下都更高效更快」这个观点，其实是站不住脚的：

• 现代主流数据库（MySQL、PostgreSQL、SQL Server这些）的查询优化器精得很，一眼就能看穿SUM(1=1)的本质，会直接把它优化成和COUNT(*)完全一样的执行计划——根本不会真的逐行计算1=1再求和，而是直接执行专门的计数逻辑。
• 甚至在某些场景下，COUNT(*)反而更靠谱：这是SQL标准里专门用来统计行数的语法，数据库厂商对它做了大量针对性优化，比如InnoDB引擎里的近似计数、PostgreSQL里的统计信息利用，这些优化SUM(1=1)未必能享受到。

这种写法最大的问题其实是可读性和维护性：

• 任何接手代码的开发者看到SUM(1=1)第一反应都是「这玩意儿是啥？为啥不直接写COUNT？」，得花时间去理解意图，完全没必要。
• 还有兼容性风险：有些数据库（比如Oracle早期版本）对布尔值的处理不一样，1=1不会转成1，这时候SUM(1=1)直接就报错了，但COUNT(*)是标准SQL，全数据库通用。

给你个实际的建议：如果是维护现有项目，可以慢慢把这种写法替换成COUNT(*)；如果是写新代码，坚决用标准的COUNT语法，别搞这种花里胡哨的操作，给自己和后续维护者添堵。

内容的提问来源于stack exchange，提问作者Twelfth