血泪教训MySQL索引我踩过的5个坑附生产级解决方案写在前面本文包含完整的踩坑经历、原因分析、解决方案和代码示例建议先收藏再阅读前言大家好我是小柚。。说出来你们可能不信我第一次在生产环境遇到索引失效问题时硬是排查了整整3天。那是一个看似简单的查询SELECT*FROMorderWHEREstatuspendingANDDATE(create_time)2024-01-01;明明给status和create_time都建了索引为什么查询还是跑了3秒DBA同事瞄了一眼淡定地说“你用函数包裹了索引列索引当然失效了。”那一刻我意识到MySQL索引失效的坑远比我想象的深。今天就把我踩过的5个致命坑全部分享出来每个坑都附带完整的复现场景、原因分析和可运行的代码示例。建议先收藏总有一天你会用上。坑1使用函数操作索引列踩坑现场这是一个典型的我以为没问题场景。业务需要查询某一天创建的所有订单-- 业务代码中的查询SELECT*FROMordersWHEREDATE(create_time)2024-01-01ANDstatuspending;我自信满满地建了索引CREATEINDEXidx_create_timeONorders(create_time);CREATEINDEXidx_statusONorders(status);结果EXPLAIN一看索引根本没用到查询跑了2.3秒。原因分析MySQL的索引是B树结构索引列参与计算时会导致索引失效。DATE(create_time)对索引列使用了函数MySQL无法使用B树的有序性只能走全表扫描。解决方案方案一使用日期范围查询-- 正确写法利用索引的范围扫描能力SELECT*FROMordersWHEREcreate_time2024-01-01 00:00:00ANDcreate_time2024-01-02 00:00:00ANDstatuspending;方案二使用前缀索引适用于字符串日期如果日期是字符串格式可以创建前缀索引-- 假设 create_time 存储为 2024-01-01 格式CREATEINDEXidx_dateONorders(create_time(10));-- 这样就可以直接用等值查询SELECT*FROMordersWHEREcreate_time2024-01-01ANDstatuspending;注意事项永远不要在WHERE子句中对索引列使用函数如果必须使用函数考虑新增计算后的列并建立索引可以使用SHOW INDEX查看索引的实际使用情况坑2隐式类型转换踩坑现场这是一个让我半夜修BUG的经典场景。订单表的用户ID是整数类型但前端传来的查询条件是字符串-- 前端传参user_id 12345 (字符串)SELECT*FROMordersWHEREuser_id12345;看起来完全正常对吧但EXPLAIN显示type: ALL (全表扫描) rows: 1000000原因分析MySQL发现user_id是整数类型而查询条件是字符串会自动将字符串转换为整数。这个转换过程相当于对索引列做了隐式函数处理-- MySQL 内部实际执行的是SELECT*FROMordersWHEREuser_idCAST(12345ASUNSIGNED);和坑1一样索引列参与计算 索引失效。解决方案方案一确保类型一致// Java 代码中确保参数类型一致LonguserIdLong.parseLong(request.getParameter(user_id));// 或者在MyBatis中使用 #{userId, jdbcTypeBIGINT}方案二使用 CAST 明确转换在某些情况下可以触发索引-- 将列转为字符串不推荐仅作为应急方案SELECT*FROMordersWHERECAST(user_idASCHAR)12345;最佳实践建表时统一类型-- 确保查询条件和列类型完全一致CREATETABLEorders(idBIGINTPRIMARYKEY,user_idBIGINTNOTNULL,-- 不要用VARCHAR存数字statusVARCHAR(20),create_timeDATETIME,INDEXidx_user_id(user_id));注意事项永远保持列类型和查询类型一致特别警惕前端传字符串、后端存数字的场景可以开启慢查询日志捕获这类问题坑3索引列参与运算运算符错误踩坑现场业务需要查询价格大于100的订单我习惯性地这样写SELECT*FROMordersWHEREprice*0.9100;等等我为什么要乘以0.9假设这是折扣价要查折后价大于100的商品…原因分析索引列参与任何运算都会导致索引失效。无论是数学运算、字符串拼接还是其他计算MySQL都无法使用索引。-- 错误写法索引失效SELECT*FROMordersWHEREprice*0.9100;-- 正确写法使用索引SELECT*FROMordersWHEREprice100/0.9;-- 或者SELECT*FROMordersWHEREprice111.12;解决方案核心原则把运算移到常量一侧-- ❌ 错误索引列参与运算SELECT*FROMproductsWHEREprice*0.9100;-- ✅ 正确常量参与运算SELECT*FROMproductsWHEREprice111.12;如果业务确实需要计算后查询-- 新增一个计算列并建立索引ALTERTABLEordersADDCOLUMNdiscounted_priceDECIMAL(10,2)GENERATED ALWAYSAS(price*0.9)STORED;CREATEINDEXidx_discounted_priceONorders(discounted_price);-- 查询时使用新列SELECT*FROMordersWHEREdiscounted_price100;注意事项常见错误场景YEAR(create_time) 2024、LEFT(name, 3) Tom如果经常需要按表达式查询考虑使用 Generated Column可以用EXPLAIN确认索引是否生效坑4LIKE 模糊查询的索引陷阱踩坑现场我需要搜索订单备注中包含紧急的订单SELECT*FROMordersWHEREremarkLIKE%紧急%;这个查询就是不用索引全表扫描。原因分析B树的索引是有序的可以快速定位前缀。但是%紧急%是中间匹配MySQL无法利用索引的有序性只能全表扫描。索引结构: [阿民, 小刘, 小李, 小陈, 小黄, ...] 查询 %紧急% : 不知道从哪里开始只能遍历所有解决方案方案一使用前缀匹配-- ✅ 使用前缀匹配可以利用索引SELECT*FROMordersWHEREremarkLIKE紧急%;方案二全文索引针对中文-- 创建全文索引ALTERTABLEordersADDFULLTEXTINDEXft_remark(remark);-- 使用 MATCH AGAINST 查询SELECT*FROMordersWHEREMATCH(remark)AGAINST(紧急INNATURALLANGUAGEMODE);方案三第三方搜索方案大规模数据如果数据量亿级别建议使用 Elasticsearch// Elasticsearch 查询示例{query:{match:{remark:紧急}}}方案四反转索引巧办法-- 新增反转后的列ALTERTABLEordersADDCOLUMNremark_revVARCHAR(1000);-- 更新数据时写入反转字符串UPDATEordersSETremark_revREVERSE(remark);-- 创建反转索引CREATEINDEXidx_remark_revONorders(remark_rev);-- 查询时匹配后缀SELECT*FROMordersWHEREremark_revLIKE%急紧;注意事项%开头的LIKE查询一定会全表扫描全文索引有最小词长度限制默认4个字符考虑业务是否真的需要模糊搜索精确查询更高效坑5OR 条件导致索引失效踩坑现场查询条件中有OR我自信地认为两个索引都能用上SELECT*FROMordersWHEREuser_id12345ORorder_noORD20240101001;EXPLAIN结果让我傻眼type: ALL possible_keys: idx_user_id, idx_order_no key: NULL -- 根本没用到索引原因分析OR 条件两边必须都有索引且索引类型相同才能使用索引合并Index Merge。如果一边有索引另一边没有或者索引类型不兼容MySQL会选择全表扫描。更关键的是即使两边都有索引OR 也可能导致索引失效的场景-- ❌ OR 导致全表扫描user_id 和 order_no 是不同类型SELECT*FROMordersWHEREuser_id12345ORorder_noORD001;-- ✅ 改为 UNIONSELECT*FROMordersWHEREuser_id12345UNIONALLSELECT*FROMordersWHEREorder_noORD001ANDuser_id!12345;解决方案方案一使用 UNION 替代 OR-- 拆分成两个查询用 UNION 合并SELECT*FROMordersWHEREuser_id12345UNIONALLSELECT*FROMordersWHEREorder_noORD20240101001ANDuser_id!12345;方案二确保 OR 两边的列都有索引-- 两个列都必须有索引CREATEINDEXidx_user_idONorders(user_id);CREATEINDEXidx_order_noONorders(order_no);方案三使用 IN 替代 OR部分场景-- IN 可以使用索引SELECT*FROMordersWHEREuser_idIN(12345,12346,12347);-- 但如果 IN 范围太大也会失效SELECT*FROMordersWHEREuser_idIN(1,2,3,...,100000);-- 可能全表扫描方案四复合索引多条件查询-- 如果经常按 user_id 和 status 查询创建复合索引CREATEINDEXidx_user_statusONorders(user_id,status);-- 查询时使用索引的最左前缀SELECT*FROMordersWHEREuser_id12345ANDstatuspending;-- ✅ 用到索引SELECT*FROMordersWHEREuser_id12345;-- ✅ 用到索引SELECT*FROMordersWHEREstatuspending;-- ❌ 没用索引注意事项OR 是索引失效的重灾区尽量避免优先使用 UNION 或 IN 替代 OR多条件查询时考虑使用复合索引并遵循最左前缀原则总结与避坑指南5个坑的快速回顾坑号场景原因解决方案1DATE(create_time)索引列使用函数改为范围查询2user_id 12345隐式类型转换确保类型一致3price * 0.9 100索引列参与运算运算移到常量侧4LIKE %keyword%中间匹配无法用索引全文索引/ES5user_id1 OR order_noAOR 导致索引失效UNION 替代实战建议永远用 EXPLAIN 分析查询养成习惯重要查询上线前必看执行计划遵循索引列干净原则不在WHERE中对索引列做任何操作类型必须一致字符串就是字符串数字就是数字不要混用优先使用复合索引多条件查询时一个好的复合索引顶多个单列索引大查询考虑方案模糊搜索、OR条件、函数运算这些场景提前规划扩展思考索引优化是无止境的。除了本文提到的5个坑还有索引选择性Cardinality过低导致MySQL选择全表扫描范围查询、、BETWEEN阻断后续列使用索引JOIN 查询中驱动表选择不当你们还踩过哪些MySQL索引的坑欢迎在评论区分享大家一起避坑 本文字数约2800字 代码示例7个⏰ 写作时间血泪3天的经验总结 建议收藏备用总有用到的时候