子查询字段类型不一致必然导致外层索引失效并全表扫描；须用information_schema.columns比对data_type、character_maximum_length、collation_name、is_nullable是否完全一致，统一类型、显式cast子查询结果、优先用exists替代in，并同步修正应用层参数类型。
子查询字段类型不一致，外层索引直接失效，不是慢，是必然全表扫描。
EXPLAIN看到type=ALL或key=NULL，先查两边字段类型
别猜“应该一样”，用INFORMATION_SCHEMA.COLUMNS比对：两边的DATA_TYPE、CHARACTER_MAXIMUM_LENGTH、COLLATION_NAME、IS_NULLABLE必须完全一致。常见陷阱包括：
-
orders.user_id是INT，子查询SELECT id FROM users却因CONCAT(id, '')或IFNULL(id, '')变成VARCHAR - ORM自动生成SQL时，把整型参数拼成字符串（如
WHERE user_id = '123'），而字段是INT - MySQL 8.0中
JSON_EXTRACT()返回JSON或VARCHAR，和BIGINT比较会触发隐式转换
CAST必须写在子查询SELECT里，不能写在外层WHERE
错误写法：WHERE orders.user_id = CAST((SELECT id FROM users WHERE status='active') AS SIGNED)——这会让优化器放弃索引。正确做法是把类型控制权交给子查询本身：
- 外层字段是
INT→ 子查询写SELECT CAST(id AS SIGNED) FROM users或SELECT CONVERT(id, SIGNED) - 外层是
VARCHAR(32) COLLATE utf8mb4_0900_as_cs→ 子查询写SELECT id COLLATE utf8mb4_0900_as_cs FROM users - PostgreSQL更严格 → 必须写
SELECT id::integer FROM users，::text和::integer混用必报错
IN子查询优先换为EXISTS，尤其当子查询结果不确定大小
IN在类型错配时容易让优化器误判执行计划，几百行以上就可能退化为物化临时表+全表扫描。而EXISTS天然走半连接，能稳定命中外层索引：
- 坏：
WHERE order_id IN (SELECT id FROM orders_log WHERE type = 'refund')（若orders_log.id是VARCHAR） - 好：
WHERE EXISTS (SELECT 1 FROM orders_log l WHERE l.id = orders.order_id AND l.type = 'refund') - 注意：
EXISTS子查询里别写SELECT *，用SELECT 1即可；关联条件必须明确写出，不能依赖隐式列名
应用层传参也要同步修正类型
后端代码里传参是字符串，SQL里又没做转换，等于主动给数据库埋雷。修复点不止在SQL：
- MyBatis中避免
#{userId}直接拼入数值型字段，改用#{userId, jdbcType=INTEGER} - Spring Data JPA用
@Query时，确保参数类型和实体字段类型一致，不要用String接收Long主键 - 前端传
"123"，后端解析后应转为long或Integer再进DAO，而不是原样塞进SQL
最麻烦的不是发现隐式转换，而是它藏在嵌套多层的子查询里，且只在数据量上来后才暴露。每次加新子查询，都要手动核对两边字段定义，而不是相信“看起来都是数字”。
