在日常开发中，数据库查询慢是个让人头疼的问题。比如你在一个拥有百万用户数据的系统里查某个账号信息，点一下搜索按钮，转圈十几秒才出结果，用户体验直接拉满负分。这时候，别急着换服务器，先看看是不是索引没用好。
索引优化器是啥？
简单说，它是数据库里的“路线规划师”。当你执行一条 SQL 查询时，优化器会分析表结构、已有索引和查询条件，决定走哪条路径最快拿到数据。它不创建索引，但它决定用不用、怎么用现有的索引。
举个生活化的例子：你在图书馆找一本《Python编程从入门到放弃》。如果没有目录和编号系统（相当于没有索引），你就得一本本翻过去；如果有分类编号，并且管理员（优化器）知道这本书在“计算机类-TN92”架上，直接带你过去，省时省力。
让优化器“看见”你的索引
有时候明明建了索引，查询还是慢，可能是优化器压根没选它。常见原因有：
- 查询条件用了函数包裹字段，比如
WHERE YEAR(create_time) = 2024，这样索引失效。 - 对字段做了隐式类型转换，比如字符串字段却传了数字，导致索引无法命中。
- 选择性太差的列建了索引，比如“性别”这种只有男/女的字段，建了也白搭。
实战调优技巧
假设你有一张订单表 orders，经常按用户 ID 和创建时间查记录：
SELECT * FROM orders WHERE user_id = 123 AND create_time > '2024-01-01';这时候你应该建立一个联合索引：
CREATE INDEX idx_user_time ON orders(user_id, create_time);注意顺序：等值查询字段放前面（user_id），范围查询放后面（create_time）。如果反过来，效果大打折扣。
再比如模糊查询，很多人写 LIKE '%手机%'，这种前后都带百分号的，索引直接废掉。如果你非得搜中间内容，考虑用全文索引或者 Elasticsearch 这类工具替代。
查看执行计划
用 EXPLAIN 命令看看优化器到底怎么走的：
EXPLAIN SELECT * FROM orders WHERE user_id = 123;重点关注 key 字段有没有显示你期望的索引，type 是否为 ref 或更好，避免出现 ALL（全表扫描）。
别迷信自动优化
有些开发者觉得“我加了索引，剩下的交给数据库就行”，其实不然。MySQL 的统计信息可能过期，导致优化器做出错误判断。可以手动更新：
ANALYZE TABLE orders;这会让优化器重新采集表的数据分布情况，有助于选出更优的执行路径。
另外，复合索引别建太多，维护成本高，还可能让优化器陷入选择困难。定期检查哪些索引长期没被使用，果断删掉。