索引优化的核心策略
索引是SQL查询提速的第一道关卡。很多人以为加了索引就万事大吉，实际上索引用不对反而会成为性能杀手。复合索引的字段顺序直接影响查询效率，通常要把区分度高的字段放在前面。比如用户表里有性别和注册时间两个字段，注册时间的区分度明显更高，应该放在索引左侧。
EXPLAIN命令是检查索引使用情况的必备工具。重点关注type列，如果出现ALL就说明走了全表扫描，需要优化。possible_keys和key列能直观显示哪些索引被实际使用。有时候MySQL优化器会选错索引，这时候可以用FORCE INDEX强制指定。
查询重构的实战技巧
避免SELECT
* 是老生常谈但依然常见的问题。只查询需要的字段不仅能减少网络传输，还能让覆盖索引发挥作用。大表关联查询时，先用WHERE条件过滤再关联能显著减少处理的数据量。比如查最近3个月的订单明细，应该先过滤时间再关联商品表。
子查询优化有个很实用的技巧：把IN子查询改写成JOIN。MySQL对IN子查询的处理效率通常较差，特别是当子查询结果集较大时。改写后执行计划会更优，有时候能有10倍以上的性能提升。
执行计划深度分析
执行计划里藏着很多优化线索。rows列显示预估扫描行数，filtered列显示条件过滤效率，这两个数值越大说明优化空间越大。Extra列里的”Using temporary”和”Using filesort”都是危险信号，意味着产生了临时表或文件排序。
| 执行计划字段 | 优化意义 | 理想值 |
|---|---|---|
| type | 访问类型 | const/ref/range |
| key_len | 索引使用长度 | 越短越好 |
| Extra | 附加信息 | 避免出现filesort |
分区表与物化视图
当单表数据量超过500万行时，分区表就该纳入考虑范围了。按时间范围分区是最常见的做法，比如按月分区。查询时带上分区键条件，引擎就能自动排除无关分区。要注意的是分区键选择不当会导致分区裁剪失效，反而降低性能。
物化视图适合统计类查询场景。预计算好的结果集可以避免每次执行都重新聚合大量数据。MySQL本身不支持物化视图，但可以用定时任务+中间表的方式模拟实现。关键是要控制好刷新频率，在数据实时性和性能之间找到平衡点。
高并发场景优化
连接池参数配置直接影响高并发下的稳定性。max_connections不是越大越好，要根据服务器内存合理设置。wait_timeout设置过大会导致连接堆积，一般 设置在300-600秒之间。使用连接池时要注意验证连接的可用性，避免拿到已经失效的连接。
批量操作能大幅减少网络往返。比如要插入1000条数据，用单条INSERT循环和用批量INSERT性能可能差50倍以上。事务范围也要控制得当，长时间运行的事务会阻塞其他操作，还可能引发锁超时问题。
索引这东西就像双刃剑，用好了能飞起来，用不好反而会拖后腿。每次数据增删改，数据库都得吭哧吭哧更新索引结构，特别是那种频繁更新的热表，索引维护开销可能比查询本身还大。想象一下，你往一个已经建了5-6个索引的表里疯狂插数据，数据库引擎光维护索引就得忙得团团转，这时候查询能快才怪。更坑的是，有些情况下优化器会觉得”算了，走索引还不如全表扫描快”，这种情况在数据量不大或者查询要返回大部分数据时特别常见。
EXPLAIN命令这时候就是救命稻草，一定要学会看。重点关注type列是不是ALL，如果是的话说明根本没走索引。possible_keys和key列对比着看，能发现优化器有没有犯傻。有时候明明有合适的索引，优化器就是不用，这时候可以试试FORCE INDEX硬塞给它。不过要注意，强制走索引也不总是好事，特别是当数据分布发生变化后，原先的强制索引可能反而成了性能瓶颈。最好的办法还是定期用ANALYZE TABLE更新统计信息，让优化器能做出更明智的选择。
常见问题解答
如何判断一个SQL查询是否需要优化？
当查询执行时间超过200ms，或者EXPLAIN结果显示type为ALL、Extra出现”Using temporary”、”Using filesort”等关键字时，就需要考虑优化。监控慢查询日志是发现性能问题的有效方法， 把long_query_time设置为1-2秒。
复合索引应该按照什么顺序创建字段？
复合索引字段顺序应该遵循区分度从高到低排列。可以通过计算字段不同值的数量占总行数的比例来判断区分度，比例越接近1区分度越高。例如日期时间字段通常比状态字段更适合放在索引左侧。
为什么有时候加了索引反而查询更慢了？
索引维护需要额外开销，当表数据频繁增删改时，索引更新会成为负担。 如果查询条件没有使用索引最左前缀，或者优化器判断使用索引不如全表扫描高效时，索引反而会降低性能。这时候需要用EXPLAIN分析执行计划。
大表关联查询有哪些优化技巧？
首先确保关联字段有索引，其次尽量先过滤再关联。对于5-10张表的大关联，可以考虑拆分成多个小查询，或者使用临时表存储中间结果。在MySQL 8.0+版本中，CTE(公共表表达式)也能优化复杂关联查询的可读性和性能。
如何避免MySQL选错索引？
除了使用FORCE INDEX强制指定索引外，还可以通过analyze table更新统计信息，或者调整optimizer_switch参数。有时候增加或删除索引也能改变优化器的选择。在MySQL 8.0+中，索引提示(index hint)语法更加丰富，可以更精确地控制索引使用。
