在数据库的世界里，索引就像程序员的贴身保镖，默默守护着查询性能的高地。但这位保镖也不是万能的，稍不留神就会被各种陷阱绊倒，导致查询性能直线坠落。作为一名码农，今天就让我带着大家扒一扒索引失效的七个致命场景，看完这些，保证让你对索引的理解更上一层楼！
函数在列上的时候，索引直接罢工最常见的索引失效场景，就是在查询条件中对字段使用了函数。比如：
SELECT * FROM user WHERE LEFT(username, 2) = '张三';
这时候，索引可不会乖乖工作了。因为MySQL在执行查询的时候，会先计算函数结果，再去和索引比对，这样索引就失去了作用。正确的做法是去掉函数，或者在索引中包含函数结果。
范围查询和排序的组合，索引也只能无奈摇头当查询中同时出现范围查询和ORDER BY时，索引往往只能帮到一半。比如：
SELECT * FROM order WHERE amount > 100 ORDER BY create_time;
这种情况下，虽然amount>100可以用索引，但排序可能还是要走一遍全表。解决方案是尽量分开处理，或者调整索引策略。
OR条件中的低选择性列，索引也只能望洋兴叹当OR条件中包含两个字段，其中一个字段的选择性很低时，索引就容易被忽视。比如：
SELECT * FROM user WHERE age=20 OR gender='男';
如果gender这个字段只有男和女两种可能，索引可能就不会起作用了。这时候可以考虑拆分查询或者调整索引策略。
Like语句的不当使用，索引也只能束手无策LIKE语句在查询中非常常见，但如果使用不当，就会导致索引失效。比如：
SELECT * FROM article WHERE content LIKE '%关键词%';
这种情况下，索引是无法使用的，因为%在开头会导致全表扫描。正确的做法是把关键词放在前面，或者使用全文检索。
全表扫描的时候，索引也只能沦为看客当查询条件的选择性太低时，优化器可能会认为使用索引反而更慢，直接选择全表扫描。比如：
SELECT * FROM user WHERE age=18;
如果年龄为18岁的用户占总数据量的30%，这时候索引可能就不会被使用了。这时候可以考虑调整索引策略，或者优化查询条件。
大数据量下的排序，索引也只能尽力而为当数据量非常大的时候，即使有索引，排序操作也可能导致性能问题。比如：
SELECT * FROM log ORDER BY create_time DESC LIMIT 10;
这时候，虽然create_time有索引，但如果数据量太大，排序操作依然会很慢。可以考虑使用覆盖索引或者调整查询方式。
不合理的联合索引，索引也只能无可奈何联合索引的顺序非常重要，如果查询条件不满足最左前缀原则，索引就无法被使用。比如：
联合索引是(name, age)，但查询条件是age=18，这时候索引就无法被使用。正确的做法是按照查询条件的顺序来建立联合索引。
索引失效就像程序员的隐形杀手，稍不留神就会让你的数据库性能一落千丈。掌握了以上七个致命场景，你就可以在日常开发中避免这些常见的性能坑了。优化是一个持续的过程，只有不断学习和实践，才能写出性能更优的代码。老铁们，码农的修行之路永不止步，让我们一起加油吧！
