全表扫描和缺失索引是最常见瓶颈，表现为EXPLAIN中type=ALL、rows巨大；函数使用、违反最左前缀、JOIN字段无索引、相关子查询、SELECT *、深度分页及统计信息过期均加剧性能问题。
全表扫描和缺失索引是最常见瓶颈
分析型查询（比如统计订单金额、用户留存率）往往要扫大量数据，一旦没走索引，EXPLAIN 里 type 字段就会是 ALL，rows 值动辄几十万甚至上千万——这意味着数据库在硬盘上一行行翻，I/O 和 CPU 都被拉满。
常见错误场景：
- WHERE 条件用了函数，比如
WHERE YEAR(created_at) = 2024→ 索引直接失效 - 复合条件只用了后半部分，比如有索引
(user_id, status, created_at)，但查询只写了WHERE status = 'paid'→ 不满足最左前缀，用不上 - JOIN 的关联字段没索引，导致驱动表每扫一行，被驱动表就得全表扫一遍
子查询和嵌套逻辑拖慢执行计划生成
分析语句里常出现“查每个用户最近一笔订单”这类需求，新手容易写成相关子查询：SELECT u.id, (SELECT amount FROM orders o WHERE o.user_id = u.id ORDER BY o.created_at DESC LIMIT 1) FROM users u。这种写法会让优化器对 users 表的每一行都触发一次子查询，实际执行变成 N 次独立查询。
更高效的做法是用窗口函数或 JOIN + 聚合替代：
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)标记最新记录，再过滤rn = 1 - 或先聚合出每个用户的最大时间，再 JOIN 回原表取完整订单信息
- 避免在 SELECT 列表里放子查询，尤其当外层结果集很大时
SELECT * 和大字段让 I/O 成倍放大
分析任务常连着宽表（比如用户表带 profile_json、avatar_url、bio 等 TEXT/BLOB 字段），如果写 SELECT *，哪怕最终只用其中 2–3 个字段，数据库也得把整行从磁盘读出来、经网络传出去、再在内存里解析——这些操作全是纯浪费。
后果不只是慢，还可能触发额外开销：
- 无法利用覆盖索引：如果只查
id, name, city，而你建了(city, name, id)索引，数据库能直接从索引里拿完所有数据，不用回表 - 缓冲池污染：大字段占满
innodb_buffer_pool，挤掉其他热点数据 - 网络传输瓶颈：千兆网卡下，单次返回 10MB 数据比返回 50KB 多花 200 倍时间
深度分页和排序是隐性杀手
报表导出常要 “第 10000 页，每页 20 条”，对应 LIMIT 199980, 20。MySQL 必须先跳过前 199980 行——哪怕有索引，也要定位、校验、丢弃，成本随偏移量线性增长。
真实生产中更危险的是 ORDER BY 配合无索引字段：
-
ORDER BY RAND()或ORDER BY SUBSTRING(name, 1, 3)→ 强制使用Using filesort，且无法用索引加速 - 没有
WHERE过滤的大表排序，会把整个结果集拉进临时磁盘文件，IO 爆炸 - 解决方案不是加索引，而是换分页方式：用游标（
WHERE id > last_seen_id ORDER BY id LIMIT 20）或预计算汇总表
分析型查询的瓶颈从来不在“SQL 写得不够炫”，而在“有没有让数据库少做一点无谓的事”。最容易被忽略的一点是：统计信息过期会导致执行计划彻底跑偏——明明有索引，优化器却选了全表扫描，ANALYZE TABLE 一跑，性能立刻翻倍。别只盯着 SQL 改，记得定期喂给数据库新鲜的分布数据。
