公司老张上周用索引优化器给客户系统“一键加速”，结果第二天报表查询慢了三倍，连登录都卡顿。不是工具不行，是他没看清几条关键提醒。
别在业务高峰期跑优化
索引重建会锁表、占CPU、读写IO暴增。你下午三点正开销售复盘会，后台却在重建订单表索引？用户刷新页面转圈圈，客服电话直接被打爆。建议选凌晨或周末低峰期，提前跟运维同事对好时间窗口。
先看执行计划，再动手建索引
有些同学一看到“查询慢”，就急着让优化器加索引。但实际可能只是SQL写法有问题。比如：
SELECT * FROM orders WHERE DATE(create_time) = '2024-05-20';这个DATE()函数会让索引失效。改成：
SELECT * FROM orders WHERE create_time >= '2024-05-20 00:00:00' AND create_time < '2024-05-21 00:00:00';不加索引，速度也能翻倍。先用EXPLAIN看执行计划，确认是真缺索引，再动刀。
复合索引顺序不能瞎排
优化器建议建 (status, user_id, create_time)，你照搬完发现查user_id单独条件还是走全表扫描？问题出在字段顺序——MySQL只支持最左前缀匹配。如果常查 WHERE user_id = 123，那user_id得放第一位；如果常查 WHERE status = 'paid' AND create_time > '2024-01-01'，那(status, create_time)更合理。别让优化器推荐什么你就建什么，得结合真实查询习惯调。
删索引比建索引更需谨慎
优化器提示“该索引从未被使用”，很多人立马删。但要注意：有些索引只在月底结账、年中审计这类低频任务里才触发。删之前，至少用performance_schema或slow log盯一周，确认它真没被任何业务逻辑调用过。曾经有团队删掉一个“看似无用”的索引，结果财务导出年报时直接超时失败。
别迷信“自动推荐”，人工得兜底
某款热门索引优化工具曾把text类型字段加进联合索引，还带前缀长度255——结果插入新记录时直接报错“index column size too large”。工具不会告诉你MySQL对索引字段长度有限制（InnoDB单列索引最大767字节）。遇到varchar(2000)或text字段，要么改前缀长度，要么换全文索引，不能全信弹窗提示。