应直接修改表结构而非在JOIN的ON条件中使用CAST/CONVERT等函数，否则会导致索引失效（EXPLAIN显示type=ALL、key=NULL），根源是字段类型、字符集、校对规则或NULL属性不一致引发隐式转换。
直接改表结构，别在ON里写CAST或CONVERT——这些函数会让索引彻底失效，EXPLAIN里type=ALL、key=NULL就是铁证。
怎么看是不是隐式转换在作怪
执行EXPLAIN，重点盯被驱动表（通常是JOIN右边那张）的两列：type是否为ALL或index，key是否为NULL。只要同时出现，基本就是类型/字符集/COLLATION不一致触发了隐式转换。
进一步验证：查INFORMATION_SCHEMA.COLUMNS比对四要素：
-
DATA_TYPE（比如BIGINTvsVARCHAR） -
CHARACTER_SET_NAME（比如utf8mb4vsutf8） -
COLLATION_NAME（比如utf8mb4_0900_as_csvsutf8mb4_unicode_ci） -
IS_NULLABLE（一边NOT NULL、一边允许NULL，MySQL 8.0 某些版本会因此跳过索引）
为什么CAST/CONVERT/::都是临时止痛药
这些写法看似“对齐了类型”，实则把转换压到每一行运行时做，B+树索引根本没法参与定位。
-
ON u.id = CAST(o.user_id AS SIGNED)→ MySQL 无法用o.user_id上的索引 -
ON u.name = o.name COLLATE utf8mb4_unicode_ci→ 即使走索引也极不稳定，且CPU开销翻倍 -
ON u.id = o.user_id::BIGINT（PostgreSQL）→ 执行计划里必现Filter: ((o.user_id)::bigint = u.id)，说明是逐行过滤，不是索引查找 -
o.user_id + 0（MySQL）→ 遇到' 123 '静默转成123，但'abc123'变成0，关联错乱
真正该做的三件事：改表、扫脏、校验传参
根治必须从物理定义入手，不是SQL层缝缝补补。
- 先扫脏数据：
SELECT COUNT(*) FROM orders WHERE user_id REGEXP '[^0-9]'（MySQL）或SELECT COUNT(*) FROM orders WHERE user_id !~ '^[0-9]+$'（PostgreSQL），确保字符串字段真能全转成目标类型 - 统一字段定义：MySQL用
ALTER TABLE orders MODIFY user_id BIGINT NOT NULL CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs；PostgreSQL用ALTER TABLE orders ALTER COLUMN user_id TYPE BIGINT USING user_id::BIGINT - 外键和主键要特别处理：外键得先
DROP FOREIGN KEY，主键修改会锁表，务必选业务低峰期 - 应用层传参必须干净：Java用
SqlParameter("@id", SqlDbType.BigInt)，Python用cursor.execute("SELECT * FROM t WHERE id = %s", (123,))，绝不能传字符串"123"进整型字段
最容易被忽略的是跨库JOIN和字符集细节——两个库默认字符集不同，或者一张表建于MySQL 5.7、另一张导自CSV且没指定COLLATION，问题不会立刻爆发，但数据量一涨，type=ALL就再也躲不掉了。
