根本原因是变量声明类型与字段类型不一致，导致MySQL在运行时对索引列执行隐式转换（如CAST(phone AS UNSIGNED)），使函数作用于索引列而失效；解决方法是严格对齐字段类型声明变量、传参时保持字面量格式（如字符串加引号）、优先使用预处理语句参数化，避免动态拼接引发类型丢失。
存储过程中 WHERE 字段 = 变量 为什么会索引失效
根本原因是变量声明类型与字段类型不一致，MySQL 在运行时无法在编译阶段确定转换方向，最终把转换压到字段侧执行。比如 DECLARE v_phone VARCHAR(11)，但你在 WHERE phone = v_phone 中调用时，phone 是 VARCHAR，而传入的 v_phone 实际值是数字（如 13800138000），MySQL 就会逐行执行 CAST(phone AS UNSIGNED) —— 函数作用于索引列，索引直接失效。
存储过程里怎么声明和传参才不触发隐式转换
关键不是“怎么写逻辑”，而是“怎么定义变量”。类型必须严格对齐字段定义：
-
phone字段是VARCHAR(11)→ 变量必须声明为VARCHAR(11)，且调用时传入带引号的字符串，例如SET v_phone = '13800138000' -
user_id是BIGINT→ 变量声明为BIGINT，不要用INT或VARCHAR存储后转，否则可能溢出或触发转换 - 避免用
SELECT ... INTO把字符串字段赋给数值型变量，例如SELECT phone INTO v_id FROM users LIMIT 1（v_id是INT）—— 这会强制转换，且不可控
动态拼接 SQL 时怎么防止类型错乱
存储过程里用 CONCAT 拼 WHERE 条件是最危险的场景，因为类型信息彻底丢失：
- ❌ 错误写法：
SET @sql = CONCAT('SELECT * FROM users WHERE phone = ', v_phone)—— 如果v_phone是数值，拼出来就是phone = 13800138000，全表扫描 - ✅ 正确写法：
SET @sql = CONCAT("SELECT * FROM users WHERE phone = '", v_phone, "'")—— 显式加单引号，确保字面量为字符串 - 更安全的做法：改用预处理语句 + 参数化，例如
SET @sql = "SELECT * FROM users WHERE phone = ?"; PREPARE stmt FROM @sql; EXECUTE stmt USING v_phone;，类型由客户端/驱动层保证
EXPLAIN 看不出问题？那就看 SHOW WARNINGS
存储过程里的 SQL 不像普通查询能直接 EXPLAIN，必须把语句抽出来单独测试。但有一个必查动作：
- 在存储过程里加
SELECT ...语句前，先手动执行等价的EXPLAIN SELECT ... WHERE phone = '13800138000'和EXPLAIN SELECT ... WHERE phone = 13800138000，对比key和type - 执行完任一查询后立刻
SHOW WARNINGS，如果出现Warning 1739 Type conversion is not allowed或类似提示，说明隐式转换已发生 - 特别注意：MySQL 8.0+ 的函数索引（如
CREATE INDEX idx_p ON t ((CAST(phone AS UNSIGNED)))）要求查询中必须写成完全相同的表达式，存储过程里很难稳定复现，不建议依赖
真正难的不是写对一行 SQL，而是让整个调用链——从应用传参、到存储过程变量声明、再到动态拼接或预处理——全部保持类型一致性。一旦中间某环用了数字类型存手机号，后面所有环节都得跟着错。
