子查询字段类型与外层字段不匹配会导致隐式转换，使外层索引失效而全表扫描；需用information_schema.columns核对类型细节，删掉concat等污染函数，显式cast子查询结果，并优先用exists替代in。
子查询字段类型和外层字段不匹配导致全表扫描
外层字段明明有索引，EXPLAIN 却显示 type=ALL 或 key=NULL，大概率是子查询返回类型和外层比较字段不一致。比如 orders.user_id 是 INT，而子查询 SELECT id FROM users 实际返回的是 VARCHAR（因字段定义或中间函数污染），MySQL 就会把整列 orders.user_id 转成字符串再比对——索引彻底失效。
别信“看起来都是数字”：VARCHAR(20) 和 INT 在 MySQL 里就是两类，隐式转换必发生。用 INFORMATION_SCHEMA.COLUMNS 对比两边字段的 DATA_TYPE、CHARACTER_MAXIMUM_LENGTH、COLLATION_NAME、IS_NULLABLE 是否完全一致，缺一不可。
- 子查询里用了
CONCAT()、IFNULL()、COALESCE()包裹主键？立刻删掉，它们会让字段类型不可控 - 外层是
INT，子查询必须写SELECT CAST(id AS SIGNED) FROM users或SELECT CONVERT(id, SIGNED) FROM users - 强制转换必须落在子查询的
SELECT列上，不是外层条件里；在WHERE外层加CAST(orders.user_id AS CHAR)等于主动放弃索引
JOIN 条件字段类型不一致引发隐式转换
ON t1.id = t2.user_id 看似合理，但只要 t1.id 是 BIGINT 而 t2.user_id 是 VARCHAR(32)，就会触发双向隐式转换，B+树索引全部失效。
查字段定义不能只看 SHOW CREATE TABLE，必须执行：SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_SET_NAME, COLLATION_NAME, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME IN ('t1', 't2') AND COLUMN_NAME = 'join_col';
-
CAST(t2.user_id AS BIGINT)或t2.user_id + 0这类写法是临时补丁，函数作用于索引列，EXPLAIN仍显示type: ALL -
ALTER TABLE统一字段类型才是根治方案，但改前要扫脏数据：SELECT COUNT(*) FROM t2 WHERE user_id REGEXP '[^0-9]' - 字符集和排序规则必须同步修改：
MODIFY COLUMN user_id BIGINT NOT NULL CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs
IN 子查询中类型错配触发优化器误判
WHERE status IN (SELECT status FROM audit_log WHERE event_id = 123) 看起来没问题，但如果子查询返回的是 VARCHAR 而外层 status 是 ENUM 或 TINYINT，MySQL 可能直接退化为全表扫描+临时表物化，尤其当子查询结果几百行以上时。
检查子查询是否含 DISTINCT、聚合或窗口函数——这些会让优化器放弃使用外层索引。
- 优先用
EXISTS替代IN：WHERE EXISTS (SELECT 1 FROM audit_log WHERE event_id = 123 AND status = orders.status)，能确保走orders.status索引 - 真要用
IN，且子查询结果确定很小，可加FORCE INDEX强制外层走索引：orders FORCE INDEX (idx_status) -
LIMIT在子查询里无效——优化器不把它当成本约束，只当语法糖
应用层传参引发的隐式转换常被忽略
前端传 "123" 字符串，后端没做类型转换就拼进 SQL，或 ORM 自动绑定时未指定参数类型，也会导致外层字段被函数包装，索引失效。
Java 中用 PreparedStatement.setInt(1, 123) 替代 setString(1, "123")；PHP 中避免 "WHERE id = '$id'" 这种拼接，改用预处理语句。
- MySQL 报
ERROR 1292（如Truncated incorrect DOUBLE value）往往就源于此：字符串字段条件漏了单引号，或数字字段传入了带空格的字符串 - PostgreSQL 更严格，类型不匹配直接报错
operator does not exist，不会隐式转，反而更容易暴露问题 - 跨数据库迁移时，同一套 SQL 在 MySQL 能跑通，在 PostgreSQL 直接失败，根源常在字段类型定义差异
