变量类型声明必须严格匹配字段类型，否则引发隐式转换导致索引失效；mysql/sql server执行时按“谁窄谁转”规则动态转换，错误类型会触发全表扫描；需通过show warnings和单独explain验证。
变量类型声明不匹配字段类型，是存储过程中隐式类型转换最常见、最隐蔽的源头——它不会报错，但会让索引在运行时彻底失效。
变量声明必须严格对齐字段类型
MySQL 和 SQL Server 都不会在编译阶段校验变量与表字段的类型兼容性，而是在执行时按“谁窄谁转”规则动态决定转换方向。一旦出错，转换就压到索引列上，直接触发全表扫描。
-
phone字段是VARCHAR(11)→ 变量必须声明为VARCHAR(11)，用CHAR、TEXT或INT都会出问题 -
user_id是BIGINT→ 变量必须是BIGINT；用INT可能溢出，用VARCHAR会强制把整个列转成字符串比较 -
SELECT phone INTO v_id FROM users这类赋值尤其危险：若v_id是数值型而phone是字符串，转换不可控，且EXPLAIN完全无法捕获
动态拼接 SQL 时必须保留字面量格式
拼接生成的 SQL 字符串一旦丢失引号或类型上下文，MySQL 就只能靠猜测解析，极易触发隐式转换。
- ❌ 错误写法：
SET @sql = CONCAT('SELECT * FROM users WHERE phone = ', v_phone)→ 若v_phone值为13800138000（无引号），拼出的是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
存储过程内的 SQL 无法直接 EXPLAIN，且外部 EXPLAIN 看起来走了索引，过程内仍可能因变量类型错位而失效。
- 必须抽取出等价语句单独测试：
EXPLAIN SELECT * FROM users WHERE phone = '13800138000'和EXPLAIN SELECT * FROM users WHERE phone = 13800138000，对比key和type字段 - 执行完任一查询后立刻执行
SHOW WARNINGS，如果出现Warning 1739 Type conversion is not allowed或类似提示，说明已发生隐式转换 - 某些隐式转换不会报错但会静默降级，比如大数字字符串转
DOUBLE后精度丢失，导致查出多条或漏行
别把 CAST 当解决方案
显式加 CAST 能绕过部分隐式行为，但它掩盖了根本问题——类型定义混乱。强行加 CAST(phone AS CHAR) 会让 phone 列失去索引能力，且无法复用执行计划。
-
CAST是补救手段，不是设计原则 - 优先修正变量声明和传参方式，而不是在 WHERE 条件里堆
CONVERT或CAST - 函数作用于索引列（哪怕只是
ISNULL()或CONVERT(VARCHAR, date_col)）会让索引彻底失效，这点在循环内尤其致命
最常被忽略的一点：隐式转换往往不报错、不告警，只悄悄拖慢查询——你得主动去查 SHOW WARNINGS，抽语句单独 EXPLAIN，而不是等用户投诉慢才回头翻日志。
