VARCHAR字段传数字不加引号会导致索引失效，因MySQL需逐行将字符串转为数字，破坏B+树有序性，触发全表扫描；INT字段传字符串带引号虽常能走索引，但存在截断、溢出等风险，类型必须严格一致。
WHERE里字符串字段配数字，索引直接作废
当字段是 VARCHAR 类型（比如 phone、traceid），但你在 WHERE 里写成 WHERE phone = 13800138000（没加引号），MySQL 就会把每一行的 phone 值都转成浮点数再比较。这个转换发生在存储引擎读取每行时，B+ 树索引无法跳过无效分支，只能全表扫描。
常见错误现象：EXPLAIN 显示 type: ALL、key: NULL，哪怕表只有几十行也一样——逻辑上仍是全表扫。
容易被忽略的细节：
-
'123abc'转成数字是123.0，'abc'是0.0，结果可能误匹配 -
SHOW WARNINGS通常会报Truncated incorrect DOUBLE value，这是关键线索 - 联合索引最左列若发生这种转换（如
KEY idx_code_age (code, age)中code = 101），整个前缀失效，age也无法受益
INT字段传字符串，多数情况仍走索引但有陷阱
反过来，字段是 INT 或 BIGINT（比如 id），条件写成 WHERE id = '123'，MySQL 通常会把字符串字面量转成整数，这个转换在优化器阶段完成，不破坏索引查找路径。
但前提是字符串能无损解析为整数：
-
'123'、' 123 '（自动 trim）可以 -
'123abc'会被截断为123，查得到但语义可疑 -
'99999999999999999999'可能溢出变0或科学计数法表示，结果错且难排查
验证方式：看 EXPLAIN 的 key 是否非空、rows 是否显著小于总行数。别只信“没报错”。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
IN 和 JOIN 场景下隐式转换更隐蔽
IN 列表或 JOIN 条件中类型不一致，一样触发全表扫描。例如：
-
WHERE status IN (1, 2)，而status是VARCHAR→ 每个值都要对status做一次字符串→数字转换 -
JOIN users u ON u.id = o.user_id，若u.id是BIGINT、o.user_id是VARCHAR→ 连接字段类型不统一，索引大概率失效 - ORM 如 MyBatis 的
#{userId}若 Java 类型是Long，但数据库字段是VARCHAR，JDBC 不报错，SQL 执行时已悄悄转换
这类问题在慢查询日志里才暴露真实 SQL，必须拿它去跑 EXPLAIN SELECT *（不能直接 EXPLAIN UPDATE，5.6.2+ 虽支持但常不准）。
CONVERT/CAST 不是解药，反而坐实问题
有人想绕过隐式转换，手动写 WHERE CAST(phone AS CHAR) = '13800138000' 或 WHERE CONVERT(id, CHAR) = '123'。这只会让问题更确定地发生——显式函数包裹索引列，MySQL 明确放弃索引下推。
本质没变：只要 WHERE 条件里对索引列做了任何形式的转换（隐式或显式），B+ 树的有序性前提就被破坏。优化器唯一安全的选择就是全表扫描。
真正有效的做法只有一个：让参数类型和字段定义严格一致。字符串字段就传带引号的字符串，数字字段就传原生数字，JOIN 字段两边类型必须完全相同。连空格、前导零、大小写都得对齐——类型匹配不是“差不多”，而是字节级一致。
