COUNT(*)是获取查询结果总行数最直接可靠的方式，因其无需客户端遍历、避免OOM、减少网络开销，且数据库引擎深度优化；COUNT(1)与之相近，而COUNT(id)因需判空更慢；带WHERE或JOIN时需注意逻辑一致性，分页应避免SQL_CALC_FOUND_ROWS或缓存，优先两次查询或物化统计。
COUNT(*) 是获取查询结果总行数最直接、最可靠的方式，无需额外逻辑或客户端遍历。
为什么不用 rows.Next() 或 len(results) 来数行？
在应用层手动遍历结果集（比如 Go 的 rows.Next()、Python 的 cursor.fetchall()）再计数，看似直观，但有明显问题：
- 必须把全部数据拉到内存，对大结果集极易 OOM 或拖慢响应
- 无法提前知道是否“有数据”，导致分页、空状态判断延迟
- 网络传输和反序列化开销被重复计算，而
COUNT(*)只返回一个整数
数据库引擎对 COUNT(*) 有深度优化——尤其是当表有聚集索引（SQL Server 默认）时，可能直接从元数据或索引叶节点快速得出结果，不扫全表。
COUNT(*) 和 COUNT(1)、COUNT(id) 的实际差异
在 SQL Server 中，三者语义不同，性能表现也并非完全一致：
-
COUNT(*)：统计所有行，包括所有列含NULL的行；优化器可跳过列检查，走最小 IO 路径 -
COUNT(1)：现代版本中与COUNT(*)几乎无差别，但属“历史惯用写法”，无实质优势 -
COUNT(id)：强制检查id列是否为NULL，哪怕该列是NOT NULL主键，优化器仍可能多一步验证
实测中，对千万级表，COUNT(*) 比 COUNT(id) 快 10%–25%，尤其当 id 是非聚集索引时更明显。
带 WHERE 或 JOIN 的查询如何准确计数？
直接在原查询上套 SELECT COUNT(*) 即可，但要注意结构匹配：
- 保留原
WHERE条件：SELECT COUNT(*) FROM orders WHERE status = 'shipped' - 带
JOIN时，务必确认连接逻辑是否引入重复行——COUNT(*)统计的是结果集行数，不是左表主键数 - 若需去重计数（如“有多少客户下过单”），改用
COUNT(DISTINCT customer_id)，但注意它无法利用普通索引的统计优化，可能变慢
避免在 WHERE 中对字段用函数（如 WHERE YEAR(orderdate) = 2024），否则索引失效，COUNT(*) 也会退化为全表扫描。
分页场景下，别信 SQL_CALC_FOUND_ROWS 或客户端缓存
MySQL 的 SQL_CALC_FOUND_ROWS 已被官方弃用，且实测比单独跑一次 COUNT(*) 慢数倍；而缓存总行数在高并发写入场景下极易过期，导致分页错乱或漏数据。
- 推荐做法：对稳定读多写少的表，用物化视图或定时更新的统计表；对实时性要求高的，接受两次查询（
SELECT ... LIMIT 20+SELECT COUNT(*) ...） - SQL Server 可考虑
sys.dm_db_partition_stats获取近似行数（快但不准），仅用于预估，不可用于分页总数
真正难的不是写对 COUNT(*)，而是判断什么时候不该用它——比如用户只看前 10 条，却要先算出 100 万总条数，这种设计本身就需要重构。
