说实话，在工作中遇到SQL JOIN性能突然暴跌，十有八九是连接键的数据类型没对齐。这不只是“可能会慢”——当INT碰到VARCHAR，数据库会强制做一个隐式转换，索引直接失效，查询从毫秒级拖到分钟级。这不是危言耸听，而是必然的全表扫描。

MySQL JOIN时INT和VARCHAR字段关联，为什么索引完全失效？

先看一个典型场景：ON a.id = b.user_id，一边是BIGINT，一边是VARCHAR。MySQL会怎么做？它会默默把整列VARCHAR转成数字，然后逐行比对。问题是，B+树索引的查找依赖的是原始数据的有序结构，转成数字之后，这个顺序就不复存在了。优化器也没办法，只能放弃索引，走type=ALL。

• 判断信号很明确：EXPLAIN里对应表的key显示为NULL，rows等于表的总行数。这就是索引失效的标志性症状。
• 别指望MySQL会替你做判断。它不会为了性能而牺牲语义安全性——宁可全表扫描，也不会冒风险走错索引。
• 有人可能想临时加个CAST(b.user_id AS SIGNED)来救急——没用。函数一旦作用在索引列上，索引照样不会被用到。

PostgreSQL或SQL Server报错“operator does not exist”，反而是好事

相比之下，PostgreSQL和SQL Server的做法更干脆：它们不会静默转换，而是直接中断操作，告诉你integer = text不匹配。这虽然暴露了问题，但解决方式同样需要小心——手动加::INTEGER或CONVERT()后，索引依然不可用。因为函数包裹让优化器无法下推索引查找。

• 在PostgreSQL中，可以查pg_attribute.atttypid确认字段类型；SQL Server则看sys.columns.system_type_id。
• 报错不等于更好，它只是把“慢得隐蔽”换成了“错得明显”。根因还是类型没对齐。
• 跨库JOIN时尤其容易踩坑：两个库的默认字符集不同，VARCHAR字段看似一样，但COLLATE不匹配就会触发CONVERT(USING utf8mb4)，索引随之失效。

应用层传参是最后一道防线，也最容易被绕过

就算数据库字段全对齐了，问题也可能出现在上游。比如Ja va代码里用"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的差异，索引都可能安静地躺在那里，永远不被使用。