子查询字段类型必须与外层完全一致，否则索引失效导致全表扫描；需用INFORMATION_SCHEMA.COLUMNS比对五项属性，避免隐式转换，优先用EXISTS替代IN，强制转换须置于子查询SELECT中，并统一应用层参数类型。
子查询字段类型和外层字段不一致，索引基本就废了——不是慢一点，是直接退化成全表扫描。
查清楚两边字段到底是不是同一类型
别凭肉眼判断“都是数字”“看着像”，MySQL 里 VARCHAR(20) 和 INT 就是两类，隐式转换必发生。得用系统视图硬核比对：
-
INFORMATION_SCHEMA.COLUMNS查COLUMN_NAME、DATA_TYPE、CHARACTER_MAXIMUM_LENGTH、COLLATION_NAME、IS_NULLABLE五项必须完全一致 - 子查询里有没有
CONCAT()、IFNULL()、COALESCE()包裹主键？有就得删——它们会让字段类型不可控 - 用
EXPLAIN看执行计划：type=ALL或key=NULL是典型信号；SHOW WARNINGS可能报Cannot use ref access on index due to type conversion
强制转换必须落在子查询的 SELECT 列上
转换位置错了，等于白干。外层字段是 INT，子查询就得写 SELECT CAST(id AS SIGNED) FROM users，而不是在外层 WHERE orders.user_id = CAST(sub.id AS SIGNED) —— 后者会让 orders.user_id 被函数包装，索引照样失效。
- MySQL：用
CAST(id AS SIGNED)或CONVERT(id, SIGNED) - PostgreSQL：用
id::integer，别用text和integer混着来 - 如果外层是
VARCHAR(32)且带特定 collation，子查询写SELECT id COLLATE utf8mb4_0900_as_cs FROM users
IN 子查询不如 EXISTS 稳定
IN (SELECT ...) 在类型错配时优化器容易误判，尤其子查询结果几百行以上，可能直接物化临时表+全表扫描。而 EXISTS 能确保走外层字段索引：
- 把
WHERE user_id IN (SELECT id FROM users WHERE status = 'active')改成WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id AND u.status = 'active') - 子查询含
GROUP BY、DISTINCT或窗口函数？优化器大概率放弃使用外层索引，优先换EXISTS -
LIMIT在子查询里无效——优化器不把它当成本约束，只当语法糖
应用层传参也得一起修
前端传 "123" 字符串，后端没做类型转换就拼进 SQL，或 ORM 自动绑定时没指定字段类型，都会触发外层字段被函数包装。这和 SQL 层错配是同一类问题：
- Java 用
PreparedStatement.setInt(1, 123)，别用setString(1, "123") - Python 的
psycopg2或SQLAlchemy要显式声明参数类型，避免自动推导为TEXT - Node.js 的
mysql2配置supportBigNumbers: true和bigNumberStrings: false，防止BIGINT被当成字符串
最麻烦的点往往不在 SQL 本身，而在子查询结果集来源不可控——比如它来自另一个视图或中间表，字段类型早已被层层 CAST 污染过。这种情况下，光改当前语句没用，得顺藤摸瓜一路查到源头定义。
