mysql索引在where中对索引列使用date()、upper()等函数会失效，因b+树仅存储原始值而非函数结果，导致优化器无法直接比对而转为全表扫描；应改用范围查询或冗余字段+索引替代。
WHERE里对索引列调用DATE()、UPPER()等函数就失效
索引树里存的是字段原始值，不是函数计算后的结果。当你写WHERE DATE(create_time) = '2025-04-18'，MySQL没法拿索引节点直接比对——因为索引里是'2025-04-18 14:22:03'这种完整时间戳，而DATE()把它变成字符串'2025-04-18'，相当于在索引列上做了运算，破坏了B+树的有序结构。
常见错误写法包括：UPPER(name) = 'ALICE'、SUBSTR(phone, 1, 3) = '138'、age + 1 > 20'。这些都会让优化器放弃索引，转为type: ALL。
- 验证方式：EXPLAIN看
key是否为NULL，type是否为ALL，Extra是否出现Using where但没Using index - 改写原则：把函数从索引列“挪到条件值一侧”，比如用
create_time >= '2025-04-18' AND create_time 替代<code>DATE() - 特殊情况：MySQL 8.0+支持函数索引，可建
CREATE INDEX idx_create_date ON orders ((DATE(create_time)))，但需确认版本和字符集兼容性
WHERE phone = 13800138000这种隐式转换等于在索引列加CAST()
如果phone字段是VARCHAR类型，而你传入数字13800138000，MySQL会自动执行CAST(phone AS SIGNED)来对齐类型。这和显式调用函数效果一样：索引列被包装了一层转换逻辑，原始值无法直接匹配。
同理，id是INT却写WHERE id = '123'，也会触发隐式转换。这类问题极隐蔽，日志或监控里看不到报错，只表现为查询变慢、rows暴增。
- 排查方法：用
SHOW CREATE TABLE确认字段类型，再比对SQL中字面量类型 - 强制类型一致：字符串字段必须加单引号，数值字段别加引号
- 注意连接层影响：JDBC URL里
useServerPrepStmts=true可能加剧隐式转换风险，建议设为false并统一用预编译参数
联合索引中对后置字段用函数，前面字段也白搭
比如有联合索引idx_user_status_ctime (user_id, status, create_time)，写WHERE user_id = 123 AND UPPER(status) = 'PAID'，整个索引都失效。不是只有status列失效，而是优化器根本不会用这个索引——因为UPPER()破坏了status的有序性，导致无法继续按create_time下推查找。
更隐蔽的是范围查询后接函数：如WHERE user_id = 123 AND status > 'a' AND UPPER(create_time) = ...，此时create_time列完全无法走索引，且status > 'a'之后的索引层级也中断。
- 关键信号：
key_len明显小于预期（比如索引总长200，实际只用到8），说明只走了前几列 - 修复思路：优先避免在索引列上做任何运算；若必须处理大小写，可建生成列+索引：
ALTER TABLE t ADD status_lower VARCHAR(20) STORED AS (LOWER(status))，再对status_lower建索引 - 不要依赖
FORCE INDEX硬扛——它不能解决函数导致的匹配失败，只会让执行计划更不稳定
EXPLAIN里type不是ALL也不代表真高效
有时候EXPLAIN显示type: range或ref，但rows接近总行数，比如表有500万行，rows=4823100。这说明索引虽然“被用了”，但过滤效果极差，实际仍接近全表扫描的I/O开销。
尤其当索引选择性低（如gender只有'M'/'F'）、或统计信息过期时，优化器会误判成本。这时即使没type=ALL，性能也崩得厉害。
- 必查项：
SHOW INDEX FROM t看Cardinality是否严重偏离真实唯一值数量 - 更新统计：
ANALYZE TABLE t，高写入表建议开启innodb_stats_persistent = ON - 警惕
SELECT *：如果索引不覆盖所有查询字段，每行都要回表，rows越大，回表I/O越爆炸
