根本原因是数据库被迫做大量重复计算、全表扫描或无效回表；优化方向是让数据库少读、少算、少传，聚焦索引覆盖、避免回表、先聚合后JOIN、禁用循环调用。
大表上 COUNT 和 SUM 导致 CPU 飙高，根本原因不是函数本身慢，而是数据库被迫做大量重复计算、全表扫描或无效回表——优化方向必须聚焦“让数据库少读、少算、少传”。
为什么 COUNT(*) 也会吃满 CPU？
很多人以为 COUNT(*) 是查元数据，实际在 InnoDB 中：只有无 WHERE、无虚拟列、无全文索引且未被 DML 频繁修改时，才可能走 TABLE_ROWS 缓存；否则仍要遍历聚簇索引。一旦加上过滤条件（比如 WHERE status = 'paid' AND created_at > '2026-09-01'），就必须逐行判断，CPU 就会飙升。
- 检查是否命中索引：用
EXPLAIN看type是range还是ALL，key是否显示用了索引 - 确认索引是否覆盖：如果只建了
(status)，但created_at没包含进去，优化器可能弃用该索引，退化为全表扫描 - 避免隐式转换：比如
WHERE status = 1而 status 是VARCHAR，会导致索引失效，强制全扫
SUM(amount) 在有索引时还慢？可能是回表惹的祸
SUM 必须读取实际数值字段，哪怕 WHERE 条件走了索引，只要 amount 不在索引中，就得根据主键回表取值——每行一次随机 I/O，在 SSD 上也扛不住万级并发。
- 建覆盖索引：例如
CREATE INDEX idx_orders_status_amount ON orders (status, amount)，这样整个聚合可在索引页内完成 - 别在
SUM里套表达式：SUM(price * qty)无法利用索引，且计算开销翻倍；考虑新增持久化列line_total并为其建索引 - 确认
amount是否允许 NULL：虽然SUM自动忽略，但如果字段定义为NULL且无 NOT NULL 约束，优化器有时会放弃某些索引优化路径
先 JOIN 后 GROUP BY 是 CPU 灾难现场
多表关联后直接 GROUP BY，中间结果集极易爆炸。比如订单表 100 万行 × 订单明细平均 5 行 = 500 万行中间集，再 SUM、COUNT，CPU 不飙才怪。
- 改成先聚合再 JOIN：
SELECT u.name, t.total FROM users u JOIN (SELECT order_id, user_id, SUM(amount) AS total FROM order_items GROUP BY order_id, user_id) t ON u.id = t.user_id - 聚合子查询必须带高选择性
WHERE下推，比如只算近 7 天数据，否则子查询本身又变成大表扫描 - 子查询里别写
SELECT *，只选分组键和聚合值，减少内存和网络压力
别让应用层补刀：循环里调 COUNT 或 SUM 是最危险操作
这是 PL/SQL 和 MySQL 应用层都高频踩的坑：先查出 1 万个 ID，再对每个 ID 执行 SELECT COUNT(*) FROM logs WHERE event_id = ? —— 1 万次硬解析 + 1 万次索引查找 + 1 万次上下文切换，CPU 直接拉满。
- 改用批量聚合：
SELECT event_id, COUNT(*) FROM logs WHERE event_id IN (1,2,3,...) GROUP BY event_id - 若 ID 列表来自外部且超 1000 个，IN 会失效，改用临时表或
VALUES ROW构造派生表 - 确认目标列是否有直方图统计信息，否则优化器可能误判返回行数，选错执行计划（尤其 Oracle）
真正卡 CPU 的从来不是 COUNT 或 SUM 这几个字，而是它们背后暴露的索引缺失、JOIN 方式错误、应用逻辑冗余这些结构性问题。每次看到 CPU 飙高，先看 EXPLAIN 输出里的 rows 和 type，再盯住“有没有回表”“有没有中间膨胀”“有没有循环调用”，比调优函数本身重要十倍。
