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 辅助识别
三、写操作优化：减少锁争用与日志压力
高并发写入场景下，锁和刷盘是主要瓶颈：
- 批量插入优先用 INSERT INTO ... VALUES (...), (...), (...)，而非多条单 INSERT；必要时配合 LOAD DATA INFILE
- UPDATE / DELETE 务必带有效 WHERE 条件，并确认能命中索引；避免 UPDATE table SET col=x WHERE unindexed_col=y 引发全表锁（尤其在 RR 隔离级别）
- 调整 innodb_log_file_size（建议总和 ≥ 4GB）和 innodb_flush_log_at_trx_commit（权衡持久性与性能，生产通常设为 1 或 2）
- 对高频更新但低一致要求的计数器类字段（如浏览量），考虑用缓存+异步落库，或拆出独立小表降低主表锁竞争
四、架构协同：别让数据库扛所有压力
很多“SQL 慢”，本质是架构层没做减法：
- 读多写少场景，用 MySQL 主从 + 应用层读写分离，但注意从库延迟导致的数据不一致问题，关键路径仍走主库
- 大字段（如 content、html）或冷热数据混存时，垂直拆分：把大字段挪到附表，主表只留高频查询字段
- 超大数据量（单表 > 2000 万行或 > 10GB）且查询维度固定，可按时间/业务 ID 做水平分表（如 order_202401、order_202402），配合中间件或应用路由
- 聚合统计类需求（如日报、排行榜），避免实时 COUNT/DISTINCT/SUM，改用定时任务预计算结果存入汇总表
不复杂但容易忽略。优化是持续过程，每次上线新功能前，都该过一遍它的 SQL 是否有隐式转换、是否触发临时表、是否在非主键上 ORDER BY。真正高效的数据库，往往安静得让人忘记它的存在。
