mysql存储过程未走预期索引，主因是优化器基于过期统计、变量传参导致选择率估算失败或函数/隐式转换破坏索引有序性，而非索引失效；应优先analyze table刷新统计或改用prepare+execute。
MySQL 存储过程没走你期待的索引，大概率不是“它不认索引”，而是优化器在当前执行上下文中判定：另一个索引（或全表扫描）代价更低。 这和普通 SQL 一样，但存储过程里更容易藏匿干扰因素——比如参数类型、变量引用、执行计划缓存行为等。
为什么 EXPLAIN 在存储过程外能用上 a 索引，进过程后却选了主键扫描？
典型复现场景：表 Y 有 KEY a(a) 和主键 id，单独查 WHERE a BETWEEN 10000 AND 20000 走 a 索引；但放在存储过程中执行，EXPLAIN 显示 type=ALL，key=NULL。
- 根本原因不是存储过程“禁用索引”，而是该查询在存储过程调用时的执行计划被复用或重生成时，统计信息已过期或不可靠（例如另一会话刚清空并重建了表）
-
innodb_stats_auto_recalc关闭时，InnoDB 不自动更新索引统计，优化器误判a索引选择率差，转而选主键全扫 - 解决办法不是强制索引，而是先刷新统计：
ANALYZE TABLE Y;；长期可设SET GLOBAL innodb_stats_auto_recalc = ON;
WHERE user_id = in_user_id 为什么比 WHERE user_id = ? 更容易丢索引？
这是 MySQL 5.7+ 中变量传参的经典陷阱。优化器对存储过程内变量（如 in_user_id）的值分布缺乏准确估算，常放弃使用索引，退化为全表扫描。
- 现象：
SELECT * FROM orders WHERE user_id = in_user_id;在EXPLAIN中key为NULL，但把语句抽出来写成SELECT * FROM orders WHERE user_id = 123;或通过客户端预编译传参?就能命中索引 - 本质是优化器无法对变量做“常量传播”（constant folding），导致选择率（selectivity）估算失败
- 绕过方式：改用
PREPARE+EXECUTE模拟预编译，或确保字段类型与参数严格一致后加FORCE INDEX（仅临时救急）
存储过程里用 CONCAT()、UPPER() 包裹索引列，索引必然失效
函数作用于索引列，等于告诉 MySQL：“别查 B+ 树了，我得一行行算完再比”。哪怕只是 UPPER(name)，也彻底破坏索引有序性。
- 错误写法：
WHERE UPPER(username) = 'ADMIN'→username索引完全不用 - 正确替代：
WHERE username = 'admin'（配合COLLATE utf8mb4_0900_as_cs实现大小写敏感匹配），或建函数索引（MySQL 8.0+）：CREATE INDEX idx_username_upper ON users ((UPPER(username))); - 隐式风险：
WHERE CONCAT(phone, '') = '13800138000'看似无害，实则同理失效；应直接写WHERE phone = '13800138000'
真正难排查的，从来不是“有没有索引”，而是“为什么此刻不用它”。每次怀疑索引失效，先单独提取那条 SQL，用 EXPLAIN FORMAT=TREE 对照存储过程内外的输出差异——差别往往就藏在 rows 预估、filtered 值、或 key 列是否为 NULL 里。
