存储过程变量声明必须与字段类型完全对齐，否则WHERE字段=变量会触发隐式转换导致索引失效；需严格匹配类型、长度、字符集及排序规则，并确保赋值和传参格式一致。
存储过程里变量声明类型必须和字段完全对齐
隐式转换最常发生在 WHERE 字段 = 变量 这种写法里，根本原因不是逻辑错，而是变量类型和字段类型不一致。比如字段 phone 是 VARCHAR(11)，你却声明成 DECLARE v_phone BIGINT，MySQL 就会在运行时对每一行的 phone 执行 CAST(phone AS UNSIGNED)——函数作用于索引列，索引直接失效。
- 查表结构：用
DESCRIBE table_name或SHOW COLUMNS FROM table_name确认字段真实类型（包括长度、是否允许 NULL） - 变量声明严格复刻：字段是
VARCHAR(11)→ 变量写DECLARE v_phone VARCHAR(11)；字段是BIGINT→ 变量写DECLARE v_id BIGINT，别用INT代替 - 避免 SELECT INTO 赋值陷阱：
SELECT phone INTO v_id FROM users LIMIT 1（v_id是INT）会强制转换且不可控，应改用SELECT CAST(phone AS CHAR) INTO v_phone
传参和赋值时保持字面量格式一致
类型对齐只是第一步，赋值方式不对照样触发转换。关键在于：字符串字段必须用带引号的字符串赋值，数字字段必须用纯数字赋值，不能靠 MySQL 去“猜”。
- 正确赋值：
SET v_phone = '13800138000'（字段是VARCHAR），SET v_user_id = 123456789012345（字段是BIGINT） - 错误写法：
SET v_phone = 13800138000（数值字面量赋给字符串变量）、SET v_user_id = '123456789012345'（字符串赋给数值变量） - 调用存储过程时同理：外部传参也要匹配，例如
CALL sp_query_user('13800138000')，而不是CALL sp_query_user(13800138000)
动态 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, "'")—— 强制字面量为字符串，但要注意 SQL 注入风险 - ✅ 更安全方案：
SET @sql = "SELECT * FROM users WHERE phone = ?"; PREPARE stmt FROM @sql; EXECUTE stmt USING v_phone;—— 类型由 MySQL 预处理机制保障，不依赖拼接
字符集与排序规则不一致也会让索引失效
即使类型完全匹配，如果字段用的是 utf8_unicode_ci，而你在存储过程中传入的字符串被 MySQL 自动赋予了 utf8mb4_unicode_ci（比如通过 NAME_CONST() 或某些客户端驱动），就会因 collation 不兼容拒绝使用索引。
- 检查字段实际 collation：
SHOW FULL COLUMNS FROM users LIKE 'ref_id'，确认是utf8mb4_unicode_ci还是utf8_unicode_ci - 避免在条件中显式指定冲突 collation：
WHERE ref_id = 'abc' COLLATE utf8mb4_unicode_ci（而字段是utf8）会导致转换 - 建表/改表统一字符集：
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，比在 SQL 层打补丁更可靠
真正难的不是记住这些点，而是每次写变量声明前，下意识去查一遍字段定义；每次拼 SQL 前，先问一句“这个值最终会以什么类型参与比较”。类型一致性不是编码规范，是索引能否生效的开关。
