隐式类型转换必然导致索引失效和全表扫描；只要where条件中字段类型与值类型不一致（如int字段传字符串'123'），数据库就必须逐行转换，b+树索引彻底失效，explain显示type=all或key=null。
直接结论：隐式类型转换不是“可能”让查询变慢，而是“必然”导致索引失效、触发全表扫描。只要 WHERE 条件中字段类型和值类型不一致，数据库就得逐行做类型转换——B+树索引就彻底作废。
WHERE 字段是 INT，却传了 '123' 字符串
这是最常见也最容易被忽略的坑。比如 user_id 是 INT 类型，但 SQL 写成 WHERE user_id = '123'，MySQL 或 PostgreSQL 就会把整列 user_id 转成字符串再比对。
- EXPLAIN 里会看到
type=ALL或key=NULL，哪怕该字段明明有索引 - PostgreSQL 的
EXPLAIN (VERBOSE)可能显示Filter: (id)::text = '123'::text - 应用层来源（如 URL 参数
req.query.id）几乎全是字符串，必须手动parseInt()或int()转换后再传入查询 - JDBC 用
ps.setString(1, "123")查 INT 字段 → 错；得用ps.setInt(1, 123)
子查询返回 VARCHAR，外层字段却是 INT
嵌套查询里类型错配更隐蔽。例如 orders.user_id 是 INT，子查询却写 SELECT id FROM users，而 users.id 实际是 VARCHAR（或被 CONCAT()/IFNULL() 包裹过），外层就会对每条 orders.user_id 做 CAST，索引失效。
- 用
INFORMATION_SCHEMA.COLUMNS对比两边字段：DATA_TYPE、CHARACTER_MAXIMUM_LENGTH、COLLATION_NAME都得一致 - 别信“看起来都是数字”，
VARCHAR(20)和INT在 MySQL 里就是两类 - 修复方式：在子查询里显式转换，如
SELECT CAST(id AS SIGNED) FROM users，而不是在外层写CAST(orders.user_id AS CHAR) - 真要用
IN，且子查询结果确定很小，优先改用EXISTS：WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id)
JOIN 两边字段类型不匹配
比如左表 users.id 是 BIGINT，右表 logs.user_id 是 VARCHAR(20)，数据库大概率把整张右表转成数字再比对——每行都要解析字符串，还可能因格式非法产生隐式 NULL，最终触发临时表 + 文件排序。
- EXPLAIN 中出现
Using temporary; Using filesort，且rows远高于预估，就是典型信号 - 根治方式是统一字段类型：把
VARCHAR列改成BIGINT并清理脏数据，而不是在 ON 条件里加logs.user_id::BIGINT = users.id - 视图里用
::DATE或CAST(created_at AS DATE)也会堵死下推，外部查询无法命中基表索引 - UNION ALL 各分支对应列类型不一致时，数据库会选“公共超类型”，比如
INT和NUMERIC(10,2)混用，结果列自动升为NUMERIC(15,2)，带来额外开销
真正难的不是写 CAST，而是发现它在哪——很多隐式转换藏在 ORM 自动生成的 SQL、视图定义、甚至前端传参链路里。上线前花 30 秒确认字段类型、参数类型、子查询返回类型是否严格一致，比事后调优省十倍力气。
