字符串字段查询不加引号会触发隐式类型转换，导致索引失效、全表扫描；mysql将varchar字段强制转为数字比较，破坏b+树有序性，explain显示key=null、type=all。
字符串字段查询不加引号会触发隐式类型转换
MySQL 在执行 WHERE phone = 13800138000 这类语句时，发现 phone 是 VARCHAR 类型，而右边是数字字面量，就会自动调用 CAST(phone AS UNSIGNED) 做隐式转换。索引 B+ 树里存的是原始字符串字节序（比如 '13800138000'），但转换后比较的是数值，无法利用树的有序结构做快速定位，只能全表扫描。
加引号和不加引号的执行计划差异一目了然
用 EXPLAIN 对比就能确认是否失效：
-
EXPLAIN SELECT * FROM user WHERE phone = '13800138000';→key列显示索引名，type通常是ref或const -
EXPLAIN SELECT * FROM user WHERE phone = 13800138000;→key为NULL，type是ALL，代表全表扫描
注意：这个现象在 MySQL 5.7 和 8.0 中都稳定复现，不是版本 bug，而是优化器行为设计使然。
不只是单引号，双引号或参数化也得保持类型一致
隐式转换的本质是“两边类型不匹配”，所以以下情况同样危险：
- 用双引号但字段是
VARCHAR：虽然语法合法，但某些驱动或 ORM 可能处理不一致 - 预编译参数传入整数而非字符串：比如 JDBC 里
stmt.setInt(1, 13800138000)查询VARCHAR字段 - JSON 字段提取后未显式转字符串：
WHERE JSON_UNQUOTE(data->'$.phone') = 13800138000同样触发转换
真正安全的做法是：确保查询值的类型与字段定义完全一致，字符串就传字符串，哪怕它看起来像数字。
联合索引中字符串字段不加引号，可能连带废掉整个索引链
假设你有联合索引 idx_name_status_phone，其中 name 和 phone 都是 VARCHAR。如果写成：
WHERE name = '小米科技' AND status = 1 AND phone = 13800138000
那么即使 name 匹配成功，phone 的隐式转换也会让优化器放弃使用该联合索引——因为索引最右列已不可靠，中间列 status 的匹配也无法被信任。这种连锁失效比单字段更隐蔽，也更难排查。
最容易被忽略的点是：开发时用测试数据查得快，上线后数据量一大，慢查询日志里突然冒出一堆 ALL 扫描，回溯才发现是某处漏了引号，而那条 SQL 在本地小表上居然“碰巧”走索引了——那是优化器基于统计信息做的错误估算，不是真的生效。
