MySQL JOIN字段类型不一致必然导致索引失效、触发全表扫描，表现为EXPLAIN中type=ALL、key=NULL；字符集/COLLATION不匹配或应用层传参类型不洁同样引发隐式转换，须统一类型、字符集、校对规则并使用参数化查询。
MySQL JOIN时字段类型不一致直接触发全表扫描
只要ON条件两边字段类型不同，MySQL就会强制做隐式转换——不是“可能慢”，而是索引必然失效。比如orders.user_id是BIGINT，而users.id是VARCHAR(20)，MySQL默认把整列users.id转成数字再比对，导致users.id上的索引完全无法使用。
典型信号就是EXPLAIN里对应表的type为ALL、key为NULL，或者Extra出现Using where; Using join buffer。别信“它应该能推断出来”，MySQL不会为性能牺牲语义一致性，它选择的是安全兜底：全扫+逐行转换。
PostgreSQL和SQL Server对类型不一致更“诚实”
PostgreSQL遇到INTEGER = TEXT会直接报错：operator does not exist: integer = text；SQL Server则在执行计划警告栏标出Type conversion in expression ... may affect ‘SeekPlan’。它们不静默转换，反而更容易暴露问题。
但注意：这种“严格”不等于“更好”。PostgreSQL报错后你得改SQL或加::BIGINT，而加了之后依然不能走索引——因为函数作用于索引列，B+树结构就失效了。SQL Server同理，CAST(customers.id AS INT)会让优化器放弃customers.id上的索引，哪怕它明明建了。
字符集和COLLATION不一致也会触发隐式转换
哪怕两列都是VARCHAR(32)，只要Collation不同（比如utf8mb4_0900_as_cs vs utf8mb4_unicode_ci），MySQL仍会悄悄做CONVERT(... USING utf8mb4)，导致索引跳过。
验证方法很简单：
- 用
SHOW FULL COLUMNS FROM table_name LIKE 'field_name'查Type和Collation两列 - 对比
CHARACTER SET和COLLATE是否完全一致 - 临时修复可用
ON a.name = b.name COLLATE utf8mb4_unicode_ci，但这只是CPU开销换来的可运行，不是性能解法
应用层传参类型不干净，数据库改得再好也白搭
字段类型对齐了，但代码里还是把ID当字符串拼进SQL：WHERE user_id = "123"（而字段是INT），MySQL照样隐式转，且参数若含空格或字母（如" 123 "或"123abc"），可能截断或报错。
真正安全的做法是：
- 所有查询必须用参数化方式，如
PreparedStatement并显式指定SqlDbType.Int - MyBatis中
#{userId}要补jdbcType=INTEGER - API入口层做强类型校验，拒绝
"123.0"、"abc"、" 123 "这类输入
最常被忽略的是跨库JOIN：两个库的默认字符集可能不同，单表内字段类型一致，JOIN时照样触发转换。这点在分库场景下几乎必踩。
