varchar字段传数字不加引号会导致索引失效，因隐式转换破坏b+树有序性；int字段传字符串带引号同样危险；join时字符集或排序规则不一致、cast()作用于列而非值，均引发索引失效。
WHERE里VARCHAR字段传数字不加引号，索引直接失效
这是最常见也最致命的写法：字段是VARCHAR，SQL却写成WHERE phone = 13800138000。MySQL必须逐行把字符串转成数字再比对，等价于给phone列套了CAST(phone AS SIGNED)——B+树索引的有序性被破坏，优化器只能选type: ALL。
典型现象：EXPLAIN显示key: NULL、rows接近全表行数；加引号毫秒返回，不加引号几秒甚至超时。
- MyBatis中误用
${}拼接（如WHERE user_id = ${user_id}），引号被吃掉 - Java后端把手机号当
Long传入，没转成字符串就拼SQL - 前端未校验类型，后端直接拼进SQL
正确做法：一律用WHERE phone = '13800138000'，单引号不可省；上线前必须用EXPLAIN验证关键路径。
INT字段传字符串带引号，同样触发隐式转换
反向操作一样危险：id是INT类型，却写成WHERE id = '123'。MySQL会调用CONVERT(id, CHAR)逐行转换，虽然开销略小，但在旧版本或统计信息不准时，仍可能退化为type: ALL或type: index。
常见于Node.js/PHP弱类型驱动自动字符串化ID、日志脚本硬编码WHERE status = '1'（而status是TINYINT）。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 字段类型与查询值类型必须严格一致：INT就传数字，VARCHAR就传带引号字符串
- 应用层拿到字符串ID时，应在DAO层转成数字再传入，而不是拼进SQL
- 别依赖
CAST(id AS CHAR)兜底——函数作用于列，索引照样不可用
JOIN时关联字段字符集或排序规则不一致
两张表JOIN，一边是utf8mb4_unicode_ci，另一边是utf8mb4_general_ci，或一张是utf8mb4、另一张是utf8，MySQL无法直接用索引匹配，会降级为嵌套循环+逐行转换。
现象：EXPLAIN显示key: NULL，且Extra出现Using where; Using join buffer。
- 检查方法：
SHOW CREATE TABLE t1看CHARSET和COLLATE；或执行SELECT CHARSET(col), COLLATION(col) FROM t - 修复动作：统一字符集与排序规则，例如
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 注意：修改字符集可能锁表，生产环境需评估窗口期
CAST()和CONVERT()用错位置，反而加重索引失效
很多人想“手动控制转换”，结果把CAST()套在列名上，比如WHERE CAST(phone AS UNSIGNED) = 13800138000——这等于主动废掉索引。
真正能走索引的强制转换，只发生在「转换不作用在列上」时：
- ✅ 正确（索引可用）：
WHERE phone = CAST(13800138000 AS CHAR(11))或WHERE phone = CONVERT(13800138000, CHAR) - ❌ 错误（索引失效）：
WHERE CAST(phone AS CHAR) = '13800138000' -
CAST( AS CHAR)默认长度是1，必须显式指定，否则可能截断或补空格引发新问题
函数索引（如CREATE INDEX idx_phone_num ON t ((CAST(phone AS UNSIGNED)))）在MySQL 8.0+理论上可行，但要求查询表达式完全一致，且维护成本高，不建议作为首选方案。
