不能只用count()加limit，因为分页需同时返回当前页数据和总行数，两次独立查询在大数据量下性能翻倍；sql_calc_found_rows已被移除且不准确，推荐显式执行一致where条件的count()与主查询，或改用游标分页、缓存总数、覆盖索引优化count性能。
为什么不能只用 COUNT(*) 加 LIMIT 就完事？
因为分页时既要返回当前页数据（比如第3页，每页20条），又要告诉前端“总共多少页”，就得知道满足 WHERE 条件的总行数。但直接执行两次查询（一次 COUNT(*)，一次带 LIMIT 的主查询）在高并发或大数据量下会明显拖慢响应——尤其当 WHERE 条件复杂、没走好索引时，两次全表扫描代价翻倍。
推荐做法：用 SQL_CALC_FOUND_ROWS 还是子查询？
SQL_CALC_FOUND_ROWS 在 MySQL 8.0.17 已被移除，且即使在旧版本中，它也不保证准确（比如遇到 UNION、GROUP BY 或某些优化器重写场景会失效），性能也不比显式 COUNT 好。所以现在应避免使用。
更可靠的做法是：**显式执行一次 COUNT(*) 查询，和一次带 LIMIT 的主查询，但通过应用层控制并发或复用条件逻辑**。例如：
SELECT COUNT(*) FROM users WHERE status = 1 AND created_at > '2024-01-01';
SELECT id, name FROM users WHERE status = 1 AND created_at > '2024-01-01' ORDER BY id LIMIT 20 OFFSET 40;
- 两个查询的
WHERE条件必须完全一致，建议封装成可复用的条件字符串或参数化函数 - 如果表有上亿行且
COUNT(*)太慢，考虑用近似值方案（如查information_schema.TABLES的TABLE_ROWS，但仅适用于 MyISAM 或 InnoDB 估算值，不精确） - 对高频分页接口，可把总数缓存几秒（比如 Redis 存
page_count:users:status1_20240101），但需注意缓存穿透和数据一致性
怎样让 COUNT(*) 尽可能快？
InnoDB 的 COUNT(*) 不像 MyISAM 那样直接读元数据，而是要遍历索引。所以优化重点在索引选择：
- 确保
WHERE条件中的字段有联合索引，且顺序匹配过滤强度（高区分度字段放前面） - 如果只统计行数、不关心具体数据，用覆盖索引能减少回表——例如
CREATE INDEX idx_status_created ON users(status, created_at)，这样COUNT(*)可直接走该索引 - 避免在
COUNT(*)中加JOIN或子查询，否则优化器容易放弃索引扫描 - 确认是否真的需要精确总数：有些业务场景（如“下一页还有内容”提示）只需判断是否存在第 N+1 条，可用
LIMIT 21查 21 条，取前 20 条展示，第 21 条存在即表示“有下一页”
ORM 框架里怎么安全拿到总数和分页数据？
Django 的 .count() 和 .all()[offset:limit] 是分开执行的，没问题；Laravel 的 paginate() 默认就是先 COUNT 再 LIMIT，但要注意它生成的 SQL 是否包含 GROUP BY 或 HAVING——这些会让 COUNT(*) 变慢甚至出错。
关键点：
- 不要依赖 ORM 自动拼接的“智能计数”，检查生成的 SQL 是否和主查询的
WHERE完全一致 - 若用原生查询（如 PDO 或 JDBC），务必复用同一份参数绑定，防止因字符串拼接导致条件不一致
- 某些 ORM（如 SQLAlchemy）支持
select_from(func.count()).select_from(...)构造子查询计数，但需确认是否触发了EXPLAIN显示的全表扫描
最易被忽略的是：WHERE 条件里用了函数（如 DATE(created_at) = '2024-01-01'）或隐式类型转换（如字符串字段跟数字比较），会导致索引失效，COUNT 和主查询都变慢——这种问题在线上查慢日志时才暴露，但开发阶段很难意识到。
