加索引后COUNT(*)仍全表扫描，因优化器认为二级索引成本高于主键扫描，尤其当索引选择性差、含大量NULL或统计信息过期时；需确保字段NOT NULL、更新统计信息或改用覆盖索引/汇总表/估算值。
为什么加了索引，COUNT(*) 还是全表扫描
因为 MySQL 优化器判断走二级索引不如扫主键便宜——尤其当索引选择性差（比如 status 只有 2–3 个值）、或索引字段含大量 NULL、或统计信息过期时。它宁可顺序读主键，也不愿随机跳转二级索引页。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，哪怕你建了 INDEX idx_status (status)；Handler_read_next 值飙升，说明引擎在遍历大量索引项甚至回表。
- 先跑
ANALYZE TABLE orders更新统计信息，让优化器重新评估成本 - 确认该列是否定义为
NOT NULL：只有NOT NULL的二级索引才可能被COUNT(*)选中 - 如果必须用带条件的
COUNT(*)，优先建联合索引，把WHERE字段放前面，末尾补一个窄的非空列（如id），例如：ALTER TABLE orders ADD INDEX idx_status_id (status, id) - 别给低基数字段（如
is_deleted TINYINT）单独建索引指望加速COUNT(*) WHERE is_deleted = 0，优化器大概率弃用
COUNT(*) 能不能走覆盖索引
能，但只在满足两个硬条件时生效：索引所有字段均为 NOT NULL，且查询不含需要判空的列（即不能是 COUNT(col) 且 col 允许为 NULL）。
本质区别在于行可见性判断：COUNT(*) 只需确认“这一行存在”，而 COUNT(col) 必须读取 col 值并检查是否为 NULL。所以即使你建了 INDEX idx_created_at (created_at)，若 created_at 是 NULLABLE，MySQL 仍可能放弃它去扫主键。
-
COUNT(*)→ 可走任意NOT NULL单列索引（如status），只要它比主键窄 -
COUNT(id)→ 若id是主键且NOT NULL，优化器通常直接用主键索引；若id是普通列，则必须有INDEX idx_id (id)且id定义为NOT NULL - 验证是否真走覆盖：执行
EXPLAIN SELECT COUNT(*) FROM orders WHERE status = 'paid'，看Extra是否含Using index
什么时候该放弃精确 COUNT(*)，改用汇总表
当单次 COUNT(*) 耗时超过 500ms、且业务允许秒级延迟（比如后台管理页显示“约 12.4 万订单”），就该切到异步更新模式。这不是妥协，而是把一致性锁代价从每次查询转移到写入端。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见错误做法：用 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE 更新计数器——高并发下容易丢更新，因为这两个语句不是原子自增。
- 建极简计数表：
CREATE TABLE order_count (total BIGINT NOT NULL DEFAULT 0) - 所有写操作必须包在事务里：
START TRANSACTION; INSERT INTO orders (...) VALUES (...); UPDATE order_count SET total = total + 1; COMMIT; - 批量导入时，别循环单条
INSERT + UPDATE，改用：UPDATE order_count SET total = total + (SELECT COUNT(*) FROM temp_import) - 避免触发器自动更新——它会拖慢所有写入，且异常时难排查
近似值够用时，别碰 COUNT(*)
INFORMATION_SCHEMA.TABLES.table_rows 是唯一毫秒级返回的方案，但它来自 InnoDB 的采样估算，误差常达 ±10%，且不包含未提交事务的数据。适合容量预估、冷热数据划分、分库分表路由决策等场景。
性能影响：从秒级降到亚毫秒，但你得接受它和真实值对不上。很多团队卡在这里，反复调优索引只为凑准一个数字，其实前端展示根本不需要精确到个位。
- 查估算值：
SELECT table_rows FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = 'mydb' AND table_name = 'orders' - 手动刷新采样：
ANALYZE TABLE orders（别频繁跑，建议低峰期每日一次） - 注意：该值不会实时反映
TRUNCATE后的变化，TRUNCATE会重置为 0，但DELETE不会
真正难的不是选哪种技术，而是敢不敢在需求评审时问一句：“这个总数，到底要多准？”——多数时候，答案是“大概就行”。
