mysql中where条件混用字符串和数字（如id='123'）会导致隐式类型转换，使int字段全列转字符串而无法使用索引，引发全表扫描；函数操作、错误参数绑定及日志验证缺失亦加剧该问题。
WHERE 条件里混用字符串和数字，id = '123' 会丢索引
MySQL 在比较时自动做隐式类型转换，如果字段是 INT 类型，但查询写成 WHERE id = '123'，MySQL 会把整列 id 都转成字符串再比——这意味着无法走索引，全表扫描就来了。
实操建议：
- 查
INT字段，参数必须是数字：用123，别用'123' - 查
VARCHAR字段且带前导零（如'00123'），别靠 MySQL 去“理解”，显式用LIKE '00123'或确保应用层传参格式一致 - 用
EXPLAIN看执行计划，重点盯type是否为ALL或index，key列是否为空
CONCAT()、UPPER() 这类函数套在 WHERE 字段上，索引直接作废
只要在索引字段上套任何函数，MySQL 就没法用 B+ 树的有序结构快速定位，只能扫全量数据。比如 WHERE UPPER(name) = 'TOM'，哪怕 name 有索引也没用。
实操建议：
- 避免在索引字段上使用函数；想大小写不敏感，建索引时用
utf8mb4_0900_as_cs这类大小写敏感排序规则，或直接用COLLATE utf8mb4_unicode_ci建字段 - 真要模糊前缀匹配，用
name LIKE 'Tom%'（可走索引），别用LEFT(name, 3) = 'Tom' - 日期字段别写
DATE(create_time) = '2024-01-01'，改用create_time >= '2024-01-01' AND create_time
JOIN 两边字段类型不一致，关联字段索引可能白建
比如左表 user.id 是 BIGINT UNSIGNED，右表 order.user_id 是 INT，MySQL JOIN 时会统一转成更宽类型，导致右表的 user_id 索引失效——即使你明明给它建了索引。
实操建议：
- JOIN 字段必须严格同类型同符号：都是
BIGINT，或都带UNSIGNED；用SHOW CREATE TABLE对比确认 - 字符集也要一致，
utf8mb4和utf8混用也会触发隐式转换 - 用
EXPLAIN FORMAT=TRADITIONAL查看filtered和rows，若rows异常高，大概率是类型不匹配拖了后腿
预处理语句参数绑定不规范，照样引发隐式转换
用 PDO 或 MySQLi 写预处理时，如果没指定参数类型，比如 $stmt->bind_param('s', $id) 把数字当字符串传，MySQL 收到的仍是 '123'，跟手写 SQL 的问题一模一样。
实操建议：
- PDO 中用
PDO::PARAM_INT显式声明：$stmt->bindValue(':id', $id, PDO::PARAM_INT) - MySQLi 中用
i（int）、d（double）等类型标识符，别偷懒全用s - 日志里打出来看实际执行的 SQL（开启
general_log或用代理抓包），确认传入值没被引号包住
最麻烦的不是发现不了，而是线上跑着跑着慢了，EXPLAIN 看起来一切正常——因为开发库数据少，隐式转换代价不明显；等数据量上来，那个被忽略的单引号、那个没声明的 PARAM_INT，就成了压垮性能的最后一根稻草。
