必须让查询值类型和字段定义类型完全一致，否则索引大概率失效；VARCHAR字段传数字不加引号、INT字段传字符串带引号、JOIN时字符集不一致、在列上使用CAST()等均会导致隐式转换，使B+树索引无法利用，触发全表扫描甚至全表锁。
必须让查询值类型和字段定义类型完全一致，否则索引大概率失效。这不是“建议”，而是MySQL优化器的硬性限制：只要WHERE条件里出现列值被隐式转换（比如VARCHAR字段跟数字比较），B+树索引的有序性就无法利用，优化器只能退化为全表扫描。
WHERE中VARCHAR字段传数字不加引号
这是线上最常踩的坑。例如phone是VARCHAR(11)，但SQL写成WHERE phone = 13800138000。MySQL会把每一行phone字符串转成数字再比——相当于给索引列套了CAST(phone AS SIGNED)，索引直接作废。
- 典型现象：
EXPLAIN显示type: ALL、key: NULL、rows等于全表行数 - MyBatis里高发：误用
${}拼接（如WHERE phone = ${phone}），引号被吃掉 - 正确写法只有这一种：
WHERE phone = '13800138000'，单引号不可省 - 上线前必须用
EXPLAIN验证，别信“参数看起来一样”
WHERE中INT字段传字符串带引号
反向操作同样危险。id是INT类型，却写成WHERE id = '123'。MySQL会逐行调用CONVERT(id, CHAR)，虽然开销略小，但执行计划仍可能显示type: ALL或type: index，尤其在统计信息不准或旧版本中。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 安全写法只有一种：
WHERE id = 123（字段int，值int） - 如果应用层只能拿到字符串（比如前端传参），应在DAO层或SQL构造前转成数字，而不是拼进SQL
- 别依赖
CAST(id AS CHAR)兜底——函数作用于列，索引照样不可用
JOIN或子查询时字符集/排序规则不一致
两张表关联字段字符集不同（比如一张是utf8mb4_unicode_ci，另一张是utf8mb4_general_ci），MySQL会强制将低优先级字段转成高优先级，等价于在列上加了隐式CONVERT()，索引匹配失败。
- 检查方式：
SHOW CREATE TABLE table_name，对比CHARSET和COLLATE - 验证字段实际属性：
SELECT CHARSET(col), COLLATION(col) FROM t1 LIMIT 1 - 修复动作：统一用
utf8mb4，执行ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 注意：
ALTER TABLE ... CONVERT TO可能锁表，生产环境需评估窗口期
强制转换函数写错位置
很多人想“手动控制”，结果把CAST()或CONVERT()套在列名上，比如WHERE CAST(phone AS UNSIGNED) = 13800138000——这等于主动废掉索引。
- 能走索引的唯一合法写法是转换字面量：
WHERE phone = CAST(13800138000 AS CHAR(11)) -
CAST(... AS CHAR)默认长度是1，不显式指定会截断或补空格，引发新问题 - MySQL 8.0+的函数索引（如
CREATE INDEX idx_phone_num ON t ((CAST(phone AS UNSIGNED)))）要求查询里也用完全相同的表达式，维护成本高，不建议作为首选
最容易被忽略的是：隐式转换不仅让索引失效，还可能触发全表加锁。当WHERE因类型不匹配退化为全表扫描，又带FOR UPDATE或LOCK IN SHARE MODE时，InnoDB会升级为全表记录锁甚至间隙锁——性能问题瞬间变成并发瓶颈。
