隐式类型转换必然导致JOIN全表扫描，因MySQL对类型不一致字段逐行隐式转换，破坏B+树索引有序性，使EXPLAIN显示key=NULL、type=ALL；需统一字段类型、字符集、COLLATE及应用层参数类型。
隐式类型转换会让JOIN慢如蜗牛，不是“可能慢”，而是必然触发全表扫描——只要ON两边字段类型不一致，索引就彻底失效，查询从毫秒级掉到分钟级。
MySQL里INT和VARCHAR JOIN时为什么索引直接消失？
MySQL在ON a.id = b.user_id中发现一边是BIGINT、一边是VARCHAR，就会把整列VARCHAR逐行转成数字比对。B+树索引依赖原始值的有序结构，而转换后的值无法复用索引顺序，优化器只能放弃索引，走type=ALL。
-
EXPLAIN里对应表的key为NULL、rows等于表总行数，就是最明确的信号 - 别信“它能自动选对”——MySQL宁可全扫也不冒险走错索引
- 临时加
CAST(b.user_id AS SIGNED)没用：函数作用于索引列，照样跳过索引
PostgreSQL或SQL Server报错反而是好事
它们不静默转换，而是直接中断并提示operator does not exist（比如integer = text不匹配）。这暴露了问题，但解决方式一样危险：::INTEGER或CONVERT()后，索引依然不可用——因为函数包裹让优化器无法下推索引查找。
- PostgreSQL查
pg_attribute.atttypid确认类型，SQL Server看sys.columns.system_type_id - 报错≠ 更好，只是把“慢得隐蔽”换成“错得明显”，根因仍是类型不对齐
- 跨库JOIN时尤其要小心：
VARCHAR字段看着一样，COLLATE一不一样就触发CONVERT(USING utf8mb4)
应用层传参才是最后一道防线，也最容易被绕过
就算数据库字段全对齐了，Java里用"WHERE id = '" + userId + "'"拼SQL，或者MyBatis写WHERE id = #{userId}却不声明jdbcType=INTEGER，MySQL照样把"123"当字符串处理，触发隐式转换。
- 脏数据会放大问题：
" 123 "、"123abc"、"123.0"都可能被截断或转成123.0再比对 - 验证方法：
SELECT COUNT(*) FROM t WHERE id REGEXP '[^0-9]'（MySQL）或SELECT COUNT(*) FROM t WHERE id !~ '^[0-9]+$'（PostgreSQL）快速扫出非纯数字 - 真正靠谱的做法：API入口层校验类型，DAO层用
PreparedStatement显式绑定SqlDbType.Int，拒绝任何字符串ID入参
最常被忽略的是：类型对齐不是改一个字段就行。字符集、排序规则、是否NOT NULL、统计信息准确性，四者缺一不可。哪怕只差一个COLLATE utf8mb4_0900_as_cs和utf8mb4_unicode_ci，索引就安静地躺在那里，却永远不被使用。
