MySQL中字符串字段在WHERE条件中未加引号会导致隐式类型转换，使VARCHAR列逐行转为数字比对，破坏B+树索引有序性，造成全表扫描（EXPLAIN显示key为NULL、type=ALL），必须使用单引号确保类型一致。
WHERE条件中字符串值没加引号导致隐式转换
MySQL遇到WHERE phone = 13800138000这类写法时，会把phone列（VARCHAR）逐行转成数字再比对，B+树索引基于原始字符串构建，转换后无法定位。现象是EXPLAIN里key为NULL，type变成ALL。
必须显式加单引号：WHERE phone = '13800138000'。这不是“习惯问题”，而是类型强制对齐的硬性要求。哪怕列定义是CHAR或TEXT，只要类型是字符串，值就必须用字符串字面量。
表字符集、列字符集、连接字符集三者不一致
常见组合陷阱：
- 表默认字符集是
utf8mb4，但某VARCHAR列被单独设为utf8（已弃用），查询时可能触发隐式转换 - 客户端连接用
SET NAMES latin1，而字段是utf8mb4，MySQL内部会做转换，索引失效概率陡增 - 复制链路中主从表字符集不同，从库执行同样SQL却走不了索引
查清当前实际生效的字符集：
SHOW CREATE TABLE users; SELECT DEFAULT_CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'your_db'; SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
修复动作优先级：先统一connection层（应用连接池配置characterEncoding=utf8mb4），再校准表和列（ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci）。
联合索引中字符串列位置不当 + 模糊查询混用
比如有复合索引idx_status_name（status, name），但写成WHERE name LIKE '%abc' AND status = 'active'——不仅LIKE '%abc'让name部分失效，还因跳过左前缀（先查name再查status），整个索引都作废。
真正能走索引的写法只有两种：
-
WHERE status = 'active' AND name LIKE 'abc%'（等值+右模糊，用上全部索引） -
WHERE status = 'active' AND name = 'abc'（全值匹配）
如果业务真要LIKE '%abc%'，别指望B+树索引，要么上FULLTEXT，要么加GENERATED COLUMN + STORED反向索引，或者改用Elasticsearch。
COLLATE不一致引发的隐式转换
即使字符集都是utf8mb4，若排序规则不同（如utf8mb4_0900_ai_ci vs utf8mb4_unicode_ci），比较时仍可能触发转换。典型报错：Illegal mix of collations，但更隐蔽的是没报错却走全表扫描。
检查方式：
SHOW FULL COLUMNS FROM users LIKE 'name';
修复原则：所有相关列、连接、数据库默认collation保持一致。批量修改命令：
ALTER TABLE users MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
注意：ALTER TABLE ... CONVERT TO会重写整张表，大表务必在低峰期操作；而MODIFY只改元数据，更快但需确认字段定义无其他变更。
EXPLAIN看不出明显异常，但key_len变小、rows暴增，才是最该盯住的信号。 
