变量类型必须与字段定义完全一致，否则导致全表扫描；DECLARE时需用SHOW COLUMNS确认字段真实类型并严格对齐，赋值须带引号、禁用SELECT INTO数值变量、动态SQL应使用PREPARE+EXECUTE USING保障类型安全。
变量类型必须和字段定义完全一致，否则存储过程一执行就全表扫描。
DECLARE 变量时怎么选类型才不踩坑
MySQL 存储过程中隐式转换的根源，90% 出在 DECLARE 那一行。不是“写得不够巧”，而是类型声明错了。
- 查表结构：用
SHOW COLUMNS FROM table_name LIKE 'column_name'确认字段真实类型（比如phone是VARCHAR(11)，不是CHAR或TEXT） - 严格对齐：字段是
VARCHAR(11)→ 变量必须声明为DECLARE v_phone VARCHAR(11)；字段是BIGINT→ 变量不能用INT或VARCHAR代替 - 别信“自动适配”：MySQL 不会帮你“聪明地选型”，它只按规则做隐式转换——而这个规则就是把字符串转成数字，导致
CAST(phone AS UNSIGNED)落到索引列上
WHERE 字段 = 变量 为什么还走不了索引
即使变量类型声明正确，只要传值方式不对，照样失效。关键不在“声明”，而在“赋值”和“比较”两个动作是否保持类型纯净。
- 赋值必须带引号：如果
v_phone是VARCHAR(11)，就得写SET v_phone = '13800138000'；写成SET v_phone = 13800138000，MySQL 会先把它当数字解析，再转字符串，中间可能截断或格式错乱 - 禁止 SELECT INTO 数值型变量：比如
SELECT phone INTO v_id FROM users LIMIT 1，其中v_id是INT—— 这强制触发转换，且无法控制精度和溢出行为 - 别用动态拼接绕过类型检查：
CONCAT('WHERE phone = ', v_phone)是高危操作；v_phone若为数值，拼出来就是phone = 13800138000，等价于对字符串字段做数字比较
动态 SQL 场景下怎么保类型安全
用 PREPARE + EXECUTE ... USING 是目前最可靠的方式，类型由 MySQL 预处理层统一管理，不会在拼接阶段丢失。
- 错误示范：
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; - 注意：参数只能是变量，不能是表达式（如
USING CONCAT('0', v_phone)会报错），需要预处理前完成格式化 - 调试技巧：执行完
EXECUTE后立刻SHOW WARNINGS，看到Warning 1739 Type conversion is not allowed就说明某处还在隐式转换
最容易被忽略的一点：存储过程里没法直接 EXPLAIN 动态语句，但你可以把最终生成的 SQL 拿出来单独跑一遍 EXPLAIN，再对比 WHERE phone = '13800138000' 和 WHERE phone = 13800138000 的 key 和 type 字段——差一个单引号，性能可能差两个数量级。
