MySQL JOIN时INT和VARCHAR关联导致索引必然失效，因隐式转换使B+树索引无法复用，EXPLAIN显示type=ALL、key=NULL；需统一类型、字符集、COLLATE及应用层传参类型。
因为类型不一致会强制数据库做隐式转换，索引直接失效，查询从毫秒级拖到分钟级——这不是“可能慢”，而是必然全表扫描。
MySQL JOIN时INT和VARCHAR字段关联，为什么索引完全失效？
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，索引就安静地躺在那里，却永远不被使用。
