SQL优化核心是理解访问模式、识别瓶颈、针对性调整，聚焦“查得快、写得稳、扩得平”；需从慢查询日志入手，结合EXPLAIN分析执行计划，科学设计索引，采用游标分页、读写分离、分表及预计算等策略持续优化。
SQL MySQL 实战优化不是堆配置或加索引就能解决的，核心在于理解数据访问模式、识别瓶颈点、针对性调整。重点是“查得快、写得稳、扩得平”。
一、从慢查询日志入手，定位真实瓶颈
不看日志就调优，等于蒙眼修车。先确保慢查询日志开启并合理设置阈值（如 long_query_time = 1）：
- 用 mysqldumpslow 或 pt-query-digest 分析日志，聚焦执行次数多、平均耗时高、全表扫描多的 SQL
- 注意区分“单次慢”和“高频轻量但累积耗时高”的语句——后者常被忽略，却可能拖垮整体响应
- 在测试环境复现时，用 EXPLAIN FORMAT=JSON 查看执行计划，重点关注 type（是否用到索引）、key（实际命中索引）、rows（预估扫描行数）、filtered（过滤率）
二、索引设计要匹配查询条件与排序分页逻辑
索引不是越多越好，而是要让 WHERE、ORDER BY、GROUP BY、JOIN 条件尽可能落在同一个联合索引上：
- 遵循最左前缀原则，但别机械套用：例如查询 WHERE status=1 AND create_time > ‘2024-01-01’ ORDER BY update_time DESC，(status, create_time, update_time) 可能不如 (status, update_time, create_time) 高效——因为排序字段应尽量靠前以避免 filesort
- 分页深度大时（如 LIMIT 10000,20），避免 offset 跳跃扫描；改用“游标分页”：记录上一页最后一条的 update_time 和 id，下一页查 WHERE update_time
- 删除长期不用、重复冗余的索引（如已有 (a,b)，又建了 (a)），用 sys.schema_unused_indexes 辅助识别
三、写操作优化：减少锁争用与日志压力
高并发写入场景下，锁和刷盘是主要瓶颈：
