存储过程调用NOW()或CURDATE()导致索引失效，根本原因是优化器无法为非确定性函数生成稳定执行计划，首次缓存的计划无法适配后续不同时间值，致使范围估算失败、回退全表扫描。
存储过程里调用NOW()或CURDATE()时索引不走
不是函数本身“导致”失效，而是MySQL在准备执行存储过程时，无法提前确定这些函数的返回值，进而无法生成稳定的执行计划。优化器看到NOW()这种非确定性函数，会放弃对索引列做范围估算，转而按最坏情况（比如全表扫描）预估成本。
常见现象：WHERE create_time > NOW() - INTERVAL 1 DAY 在存储过程中执行慢，但把NOW()换成具体时间字符串后立刻变快；EXPLAIN 显示 type=ALL、key=NULL。
- 根本原因是：存储过程的执行计划在第一次调用时就缓存了，而
NOW()每次值都不同，但优化器不会为每个调用重新计算索引选择 - 对比普通SQL：客户端每次发过去的是带具体时间的语句，优化器能基于真实值做精确估算
- 临时表或派生表中嵌套使用
NOW()也会触发同样问题，原理一致
CONCAT()、UPPER()等函数在存储过程参数拼接中绕过索引
很多人在存储过程中拼接查询条件，比如：SET @sql = CONCAT('SELECT * FROM users WHERE name = ''', p_name, '''');，再用PREPARE执行。一旦p_name被UPPER()或TRIM()处理过，哪怕只是写在SET语句里，最终生成的SQL也可能含函数包裹索引列。
典型错误写法：WHERE UPPER(name) = UPPER(p_name) —— 看似两边都加函数，但name字段上的索引是原始值，B+树里没存大写形式，自然无法匹配。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 解决办法不是“两边都加函数”，而是确保索引列本身不参与任何计算：改用
WHERE name = LOWER(p_name)（前提是索引建在LOWER(name)上，或字段本身已规范大小写） - 若必须大小写不敏感，优先建函数索引：
CREATE INDEX idx_name_lower ON users (LOWER(name));（MySQL 8.0.13+ 支持） - 避免在拼SQL时动态加函数，尤其别在
WHERE子句左侧操作索引列
存储过程里用IN传入列表却触发隐式类型转换
当存储过程接收一个TEXT或VARCHAR类型的参数（比如逗号分隔的ID串），再用FIND_IN_SET()或IN配合CONVERT()解析时，极易引发隐式转换。例如：id是INT索引列，但传入'1,2,3'后拆成SET @ids = '1,2,3'; SELECT ... WHERE id IN (@ids);，MySQL会把整个字符串当做一个值去比，或尝试转成数字导致索引列被强制转成字符串。
- 真正有效的做法是：用临时表或JSON_TABLE（MySQL 8.0.4+）展开参数，再JOIN；或者业务层拆好传多个
IN参数（如IN (?, ?, ?)） -
FIND_IN_SET(id, p_id_list)永远不走索引，因为它是对整列做字符串查找，不是索引匹配 - 哪怕用了
CAST或CONVERT显式转类型，只要右侧是变量而非字面量，优化器仍可能放弃索引估算
为什么EXPLAIN在存储过程里看不到真实执行计划
直接对存储过程EXPLAIN PROCEDURE xxx是无效的；你看到的往往是创建语句的语法检查结果，不是运行时计划。真正要查，得在过程内部加SELECT ... FROM t WHERE ...;前手动加EXPLAIN FORMAT=TRADITIONAL，或从information_schema.PROCESSLIST抓正在执行的SQL再单独EXPLAIN。
更关键的是：存储过程里所有SQL的执行计划，都受制于“prepared statement 缓存”和“参数化绑定”的行为。同一个PREPARE语句，第一次用1执行生成的计划，第二次用1000000可能还是复用旧计划——哪怕后者本该走索引，前者本该全表扫。
- 规避方式：对关键查询禁用预编译缓存，用
DEALLOCATE PREPARE+ 重新PREPARE，或干脆不用动态SQL - 复杂逻辑尽量拆到应用层，数据库只做确定性操作；存储过程适合做事务控制、批量DML，不适合承载高度可变的查询逻辑
- 最容易被忽略的一点：存储过程里的变量默认无类型推断，
DECLARE v_time DATETIME DEFAULT NOW();这种写法，v_time在后续WHERE中仍可能被当作字符串参与比较
