join字段类型不一致必然导致索引失效，表现为explain中type=all、key=null；需用show full columns和show create table对比type/character set/collation，再通过explain extended+show warnings确认隐式转换，最终必须统一表结构定义并确保应用层参数类型纯净。
JOIN字段类型不一致必然导致索引失效
只要ON条件两边字段类型不同，MySQL就一定会触发隐式转换，索引直接作废——不是“可能慢”，而是EXPLAIN里type=ALL、key=NULL必现。PostgreSQL更干脆：operator does not exist: integer = text直接报错；SQL Server则在执行计划警告栏标出Type conversion in expression may affect ‘SeekPlan’。别指望优化器“聪明推断”，它只按规则兜底。
怎么快速定位是不是类型/字符集/COLLATION惹的祸
别靠猜，用命令直接查：
-
SHOW FULL COLUMNS FROM table_a LIKE 'user_id'和SHOW FULL COLUMNS FROM table_b LIKE 'user_id'，对比Type、Collation两列 -
SHOW CREATE TABLE table_a和SHOW CREATE TABLE table_b，看字段定义末尾是否都带CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 执行
EXPLAIN EXTENDED SELECT ... JOIN ...后立刻跟SHOW WARNINGS，Message里出现Cast to BIGINT或CONVERT(user_id USING utf8mb4)就是铁证
修复必须改表结构，别在SQL里硬绕
在ON里写CAST(o.user_id AS SIGNED)或o.user_id + 0看似能跑通，但等于告诉数据库“每次JOIN都现场算一遍”，o.user_id上的索引依然用不上。真正有效的解法只有统一底层定义：
- MySQL：用
ALTER TABLE table_b MODIFY user_id BIGINT UNSIGNED（注意要同步NOT NULL属性） - PostgreSQL：用
ALTER TABLE table_b ALTER COLUMN user_id TYPE BIGINT USING user_id::BIGINT，但提前用SELECT COUNT(*) FROM table_b WHERE user_id !~ '^[0-9]+$'扫出脏数据，否则会中断 - 改完必须验证：
SHOW CREATE TABLE table_b确认字段类型已更新，再跑EXPLAIN看key是否回归索引名 - 跨库JOIN更要命：两个库默认字符集不同（比如一个utf8mb4_general_ci，一个utf8mb4_0900_as_cs），哪怕字段类型一样，照样触发转换
应用层传参类型不干净，数据库改得再对也白搭
字段全改成BIGINT了，但代码里还是WHERE user_id = "123"拼字符串，MySQL照样隐式转，且" 123 "或"123abc"会导致截断或报错。安全做法只有三条：
- 所有查询走参数化：MyBatis用
#{userId, jdbcType=INTEGER}，JDBC用PreparedStatement.setLong() - API入口层做校验：拒绝
"123.0"、"abc"、" 123 "这类输入，只放行纯数字字符串或数字类型 - ETL或CSV导入时加清洗步骤：
TRIM()+REGEXP '^[0-9]+$'过滤，别让脏数据进库
最常被跳过的环节是外键和UNION：外键字段COLLATION不一致，建表就失败；UNION要求所有列字符集完全一致，否则Illegal mix of collations直接中断。这些地方不一起改，问题只是换个姿势爆发。
