在数据库查询优化中，索引是提升查询效率的核心手段，但部分写法会导致索引无法被正常使用，函数和隐式转换就是两类高频的索引失效诱因，理解这些场景能帮助开发者写出更高效的SQL语句。
函数导致的索引失效场景
当查询条件中对索引列使用了函数时，数据库优化器往往无法直接使用该列的索引，因为函数处理会改变列的原始值，索引存储的是原始值的排序结构，无法匹配函数处理后的结果。
常见函数失效示例
假设有一张用户表user_info，其中create_time字段建立了普通索引，需要查询2024年创建的用户，错误写法如下：
-- 对索引列使用DATE函数，索引失效 SELECT * FROM user_info WHERE DATE(create_time) = '2024-01-01';
上述语句中DATE()函数会处理create_time列的每个值，优化器无法利用create_time的索引快速定位，会触发全表扫描。正确的写法应该避免对索引列使用函数：
-- 范围查询替代函数处理，索引生效 SELECT * FROM user_info WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00';
除了日期函数，字符串处理函数如UPPER()、SUBSTRING()，数值处理函数如ABS()等，只要作用在索引列上作为查询条件，都会导致对应索引失效。
隐式转换导致的索引失效场景
隐式转换是指SQL语句中字段类型和传入值的类型不匹配时，数据库自动进行的类型转换，这种转换本质是对索引列做了函数处理，同样会导致索引失效。
常见隐式转换示例
假设user_info表的phone字段是VARCHAR类型且建立了索引，查询手机号时如果传入数值类型的值，就会触发隐式转换：
-- phone是字符串类型，传入数值会触发隐式转换，索引失效 SELECT * FROM user_info WHERE phone = 13800138000;
数据库会自动把phone列的每个值转换成数值类型和传入的13800138000比较，相当于对phone列使用了转换函数，索引无法生效。正确的写法应该保证类型匹配：
-- 传入字符串类型值，类型匹配，索引生效 SELECT * FROM user_info WHERE phone = '13800138000';
还有一种常见场景是关联查询时两张表的关联字段类型不一致，比如一张表关联字段是INT类型，另一张是VARCHAR类型，关联时也会触发隐式转换，导致其中一张表的索引失效。
索引失效的规避方法
- 查询条件中避免对索引列使用任何函数，尽量通过改写查询逻辑实现需求
- 写入和查询时保证字段类型和传入值的类型完全一致，避免隐式转换
- 关联查询时提前统一关联字段的类型，避免跨类型关联
- 可以通过
EXPLAIN语句分析SQL执行计划，确认索引是否被正常使用
通过规避上述两类场景，可以有效减少索引失效的概率，提升SQL查询的整体性能，降低数据库的负担。