隐式类型转换会导致索引失效、全表扫描、错序结果和性能雪崩；应严格保持字段与字面量类型一致，用EXPLAIN和SHOW WARNINGS及时发现，并通过CAST或显式转换规避。
WHERE 条件里字符串和数字混用会出事
当 WHERE 子句中写成 id = '123'（字段是 INT，但值用了字符串），数据库大概率会隐式把字符串转成数字。看起来结果对，但可能触发全表扫描——因为索引失效了。
- MySQL 8.0+ 对
INT字段比较字符串时，会先将字符串转为数字再比，但如果字符串含非数字字符（如'123abc'），会被截断为123，且不报错 - PostgreSQL 更严格：直接报错
operator does not exist: integer = text，除非显式加::integer - SQL Server 会尝试转换，但遇到
'abc123'这类会抛出Conversion failed错误
JOIN 两边字段类型不一致导致性能雪崩
两个表 JOIN 时，如果一边是 VARCHAR(50)，另一边是 CHAR(50) 或 TEXT，数据库可能放弃使用索引，改走嵌套循环或哈希连接，执行时间从毫秒级跳到秒级甚至分钟级。
-
VARCHAR和CHAR比较时，CHAR会右补空格，而VARCHAR不补，可能导致本该匹配的行被漏掉 - MySQL 中
VARCHAR与TINYINT关联，即使值都是1，也可能因字符集/排序规则差异触发隐式转换，让EXPLAIN显示type: ALL - 用
SHOW WARNINGS可查到 MySQL 是否做了隐式转换，例如提示Warning | 1292 | Truncated incorrect DOUBLE value
ORDER BY + LIMIT 遇上隐式转换会返回错序结果
比如字段是 status VARCHAR(10)，存着 '1', '10', '2'，若写成 ORDER BY status LIMIT 3，实际按字符串排序，结果是 '1', '10', '2'，而不是数值顺序。
- 更隐蔽的是带前导零的字符串，如
'001','02','3'，字符串排序和数值排序完全不一致 - 如果字段本意是数值状态码（如 HTTP 状态），却定义为字符串类型，又没加
::INTEGER或CAST(status AS SIGNED)，ORDER BY就不可信 - 在分页场景下（
OFFSET+LIMIT），错序会导致同一条记录在不同页重复出现或丢失
怎么快速发现和规避这类问题
别等线上慢查询报警才查——很多隐式转换根本不会报错，只悄悄变慢或返回错数据。
- 用
EXPLAIN FORMAT=JSON查看key和used_key_parts是否为空，再看filtered值是否异常低（如10.00） - 在 WHERE / JOIN / ORDER BY 中，所有字面量必须和字段类型严格一致：数字用无引号数字，字符串用引号，且长度、字符集、排序规则要对齐
- 上线前跑一遍
SELECT ... FROM t1 JOIN t2 ON t1.id = t2.id，再改成t1.id = CAST(t2.id AS CHAR)，观察执行计划是否突变 - 对已上线表，可用
INFORMATION_SCHEMA.COLUMNS扫描类型不一致的关联字段，例如查data_type为varchar但常被拿来和int关联的列
最麻烦的不是转换本身，而是它藏在看似无害的等号后面，既不报错，也不警告，只在数据量变大或并发升高时突然暴露。
