MySQL存储过程中索引失效的根源是SQL语句写法不当导致全表扫描，典型场景包括：WHERE条件中对索引列使用函数、隐式类型转换、OR连接非覆盖条件、JOIN关联字段类型或字符集不一致。
MySQL存储过程中索引失效的典型场景
存储过程本身不直接“让索引失效”，但内部 SQL 语句若写法不当，会绕过索引，导致全表扫描——这才是慢的根源。常见触发点包括：WHERE 条件中对索引列使用函数、隐式类型转换、OR 连接多个非覆盖条件、或在 JOIN 中关联字段类型/字符集不一致。
CONCAT()、DATE() 等函数包裹索引列
比如写成 WHERE CONCAT(name, '') = 'Alice' 或 WHERE DATE(create_time) = '2024-01-01'，MySQL 无法使用 name 或 create_time 上的索引。优化方式是改写为范围查询或前置计算：
- 用
WHERE name = 'Alice'替代CONCAT(name, '') = 'Alice' - 用
WHERE create_time >= '2024-01-01' AND create_time 替代 <code>DATE(create_time) - 若必须函数处理，可考虑生成列 + 函数索引（MySQL 8.0+）
存储过程参数未正确绑定导致隐式转换
这是最容易被忽略的坑：声明 IN p_id VARCHAR(20)，但调用时传入数字字面量（如 CALL proc(123)），MySQL 会把索引列 id INT 转成字符串比对，触发全表扫描。验证方法是执行 EXPLAIN 查看 type 是否为 ALL，key 是否为 NULL。
- 参数类型务必与字段类型严格一致（
INT对INT，VARCHAR对VARCHAR） - 调用时避免裸数字，显式转成字符串：
CALL proc('123') - 检查
character_set_client和字段字符集是否匹配，否则也会触发转换
存储过程内多语句混合导致执行计划缓存失效
MySQL 5.7+ 默认启用 query_cache_type=OFF，但存储过程中的 SQL 仍依赖 prepared statement 缓存和 optimizer 的重解析行为。如果过程里动态拼接 SQL（CONCAT + EXECUTE），每次都会重新生成执行计划，且无法复用索引统计信息。
- 避免在循环中反复
PREPARE/EXECUTE/DEALLOCATE - 优先用静态 SQL + 参数占位符（
?）代替字符串拼接 - 确认
innodb_stats_auto_recalc开启，防止统计信息陈旧误导优化器选错索引
真正卡住性能的往往不是“存储过程”这个容器，而是里面那条没走索引的 SELECT —— 它可能在普通查询里也慢，只是被包进过程后更难被发现。建议每次修改存储过程，都单独提取核心查询语句，用 EXPLAIN FORMAT=TREE 看真实访问路径。
