MySQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT；优化需预判执行路径，优先确保WHERE索引有效、JOIN驱动表合理、分页避免深翻。
MySQL执行流程决定了SQL写法的底层逻辑
写SQL不是拼语法，而是预判MySQL怎么执行它。优化本质是让语句匹配MySQL的执行路径，而不是强行“改写”。关键在理解FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT这个实际执行顺序（注意：SELECT字段列表虽写在最前，但执行时排在WHERE之后、ORDER BY之前）。
常见错误是把业务思维直接套进SQL：比如先想“我要查用户昵称”，就写SELECT nickname FROM user，再补条件——这容易忽略WHERE是否能走索引、JOIN会不会放大中间结果集。
- WHERE条件必须优先考虑索引覆盖性，尤其是组合索引的最左匹配；
- 避免在WHERE中对字段做函数操作，如
WHERE YEAR(create_time) = 2023会失效索引； - GROUP BY和ORDER BY尽量复用同一索引，否则可能触发
Using filesort或Using temporary； - SELECT * 在多表JOIN时极易引发冗余IO，应明确只取需要字段。
EXPLAIN不是看有没有type=ALL，而是看key_len和rows是否合理
EXPLAIN输出里最常被误读的是type列。其实type=range不一定比ref快，关键要看key_len用了索引多少字节、rows预估扫描行数是否接近真实量级。
例如一张订单表有联合索引(status, user_id, create_time)，执行WHERE status = 'paid' AND user_id = 123，key_len应为状态字段长度 + user_id长度；若只显示状态字段长度，说明user_id没用上索引。
- 当
rows远大于实际返回行数（比如查10条却扫10万行），大概率是索引没生效或统计信息过期； -
Extra里出现Using index condition是好的，说明用了ICP（索引下推），但Using where; Using index才表示完全覆盖索引； -
filtered值过低（如
JOIN顺序不等于书写顺序，但驱动表选择直接影响性能
MySQL的JOIN执行器默认采用嵌套循环（Nested Loop），先选一个表作为驱动表（outer table），再用它的每行去匹配被驱动表（inner table）。优化器通常选小结果集作驱动表，但有时会选错——尤其当WHERE条件分散在不同表时。
例如：
SELECT u.name, o.amount FROM user u JOIN order o ON u.id = o.user_id WHERE u.status = 'active' AND o.create_time > '2024-01-01';如果
user表有100万行、order表有50万行，但WHERE u.status = 'active'只筛出1000人，而o.create_time > ...筛出40万单，则应强制让user作驱动表。可用STRAIGHT_JOIN干预：SELECT STRAIGHT_JOIN u.name, o.amount FROM user u JOIN order o ON u.id = o.user_id WHERE u.status = 'active' AND o.create_time > '2024-01-01';
- 小表驱动大表是原则，但“小”指过滤后的结果集大小，不是物理行数；
- LEFT JOIN的左表固定为驱动表，无法优化器重排，务必确保左表WHERE条件足够强；
- 多表JOIN时，避免在ON条件里混写非关联字段（如
ON u.id = o.user_id AND u.type = 'vip'），这会让被驱动表失去索引下推机会。
分页深翻（LIMIT M,N）的本质是“跳过M行”，不是“取第M+1行”
LIMIT 1000000, 20不是从索引里直接定位第1000020条，而是让MySQL先扫描并丢弃前1000000行——即使走了索引，也是白白遍历B+树叶子节点。
真正有效的深分页只有两种思路：用游标（cursor-based）或延迟关联（deferred join）。前者依赖排序字段唯一且单调（如id或create_time），后者通过子查询先拿到主键再回表：
SELECT o.*
FROM order o
INNER JOIN (
SELECT id FROM order
WHERE status = 'shipped'
ORDER BY id
LIMIT 1000000, 20
) AS tmp ON o.id = tmp.id;- 游标方案示例：
WHERE create_time > '2024-01-01 10:00:00' ORDER BY create_time LIMIT 20，每次用上一页最后一条的create_time继续查； - 如果排序字段不唯一（如多个订单同秒创建），需补上
id做二级排序，否则可能漏/重数据； - 绝对避免在高并发场景用
LIMIT深翻做后台导出，应改用WHERE id > ?分段拉取。
复杂点在于执行计划受统计信息、参数配置（如join_buffer_size）、甚至临时表引擎（tmp_table_size）影响很大。同一SQL在测试库和生产库表现可能完全不同——别只信本地EXPLAIN，上线前必须用SHOW PROFILE或慢日志里的Rows_examined验证真实扫描量。
