子查询字段类型不一致会导致外层索引静默失效，表现为EXPLAIN中type=ALL或key=NULL；必须在子查询SELECT列显式CAST为匹配类型，而非在外层WHERE转换，且优先用EXISTS替代IN。
子查询字段类型不一致会直接让外层索引失效，不是报错而是静默变慢——查 EXPLAIN 里出现 type=ALL 或 key=NULL 就是典型信号。
为什么子查询类型错配比 JOIN 更隐蔽
JOIN 字段类型不对，执行计划里 key 为空一眼能看出来；子查询却常被当成“只是查点数据”，其实只要子查询 SELECT 列的类型和外层 WHERE 比较字段不一致，MySQL 就会把整个外层字段做隐式转换。比如 orders.user_id INT 对上子查询返回的 VARCHAR，优化器就放弃走 user_id 索引，改全表扫描。
- 别信“值看起来一样”——
VARCHAR(20)和INT在 MySQL 里就是两类，隐式转换必发生 - 子查询里用了
CONCAT()、IFNULL()、COALESCE()包裹主键？这些函数会让字段类型不可控，立刻删掉 - 聚合或
DISTINCT后的字段类型可能被推导为DECIMAL或TEXT，哪怕原始是INT，也得重新 CAST
显式 CAST 必须落在子查询的 SELECT 列上
不是在外层 WHERE 加 CAST(orders.user_id AS CHAR)，那是主动放弃索引；必须让子查询自己输出正确类型，外层才能对齐匹配。
- 外层字段是
INT：子查询写SELECT CAST(id AS SIGNED) FROM users（MySQL）或SELECT id::integer FROM users（PostgreSQL） - 外层是
VARCHAR(32)且带特定校对规则：子查询写SELECT id COLLATE utf8mb4_0900_as_cs FROM users - 涉及空值时别依赖上下文推导：
SELECT CAST(NULL AS INTEGER)明确意图，避免 PostgreSQL 因类型推导失败中断
IN 子查询不如 EXISTS 稳定，尤其类型错配时
IN (SELECT ...) 在子查询结果稍大（几百行以上）或类型不一致时，优化器容易误判，退化为全表扫描 + 临时表物化；EXISTS 能确保走外层字段索引。
- 优先改写为：
WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id AND u.status = 'active') - 真要用
IN，且子查询结果确定很小，可加FORCE INDEX强制外层走索引：orders FORCE INDEX (idx_user_id) -
LIMIT放在子查询里无效——优化器不把它当成本约束，只当语法糖
应用层传参也得一起修
前端传 "123" 字符串，后端没做类型转换就拼进 SQL，或 ORM 自动绑定字符串参数到数字字段，同样触发隐式转换。这类问题不会出现在 SQL 本身，但执行计划一样崩。
- Java 用
PreparedStatement.setInt(1, 123)替代setString(1, "123") - Python SQLAlchemy 显式指定类型：
where(table.c.user_id == bindparam('uid', type_=Integer)) - Node.js mysql2 避免字符串插值，用参数占位符：
WHERE user_id = ?并传入数字类型值
最常被忽略的是子查询嵌套层级——上层视图用了子查询，下层又套一层，类型污染会逐层放大；修复时得从最内层开始逐个 pg_typeof() 或 INFORMATION_SCHEMA.COLUMNS 核对，不能只看最终结果字段名。
