CAST/CONVERT 有时反而让查询更慢，因函数操作导致索引失效、无法下推条件、触发全表扫描及高CPU开销；仅当无法改表结构时才临时兜底使用。
为什么 CAST/CONVERT 有时反而让查询更慢
显式用 CAST 或 CONVERT 看似“主动解决”类型不匹配，但实际常导致索引失效——因为数据库无法将外部 WHERE 条件下推到被转换的列上。比如 PostgreSQL 视图里写 user_id::BIGINT，哪怕基表 user_id 有 B-tree 索引，查询时也只能全表扫描后再转换。
典型信号：EXPLAIN 显示 Filter 出现在 Subquery Scan 层，而非基表扫描层；rows 预估远高于实际数据量；Extra 含 Using temporary 或 Using filesort。
- MySQL 中对字符串列用
CAST(col AS SIGNED)做 JOIN，基本无法走索引（引擎不支持函数索引下推） - SQL Server 的
CONVERT(INT, varchar_col)在 ON 条件中会触发每行解析，CPU 开销陡增 - PostgreSQL 的
::强制转换虽语法简洁，但若右侧无函数索引，优化器大概率放弃使用原列索引
什么时候该用 CAST/CONVERT，而不是改表结构
仅在以下情况才考虑用类型转换函数临时兜底：
- 线上大表（千万级以上）无法停机
ALTER TABLE ... MODIFY COLUMN，且业务方确认短期内不会统一类型 - 跨系统对接（如日志表 VARCHAR 订单号 vs 主库 BIGINT ID），双方 schema 不受你控制
- 临时排查或 AB 测试，需要快速验证“类型一致后性能是否恢复”
此时应把转换写在 ON 条件中较“松”的一侧，例如：左表 id 是 BIGINT，右表 ref_id 是 VARCHAR，则写 ON t1.id = CAST(t2.ref_id AS BIGINT)，而非反过来——避免对主表字段做函数操作。
不同数据库中 CAST/CONVERT 的关键差异
语法相似，但行为和兼容性差别很大：
- MySQL：
CAST(col AS CHAR)和CONVERT(col USING utf8mb4)都可用，但CONVERT(col, SIGNED)对含非数字字符的字符串会静默转成 0，引发逻辑错误 - PostgreSQL：
col::INTEGER比CAST(col AS INTEGER)更快，但遇到非法值直接报错（如'abc'），需配合NULLIF或TRY_CAST（v16+） - SQL Server：
TRY_CONVERT(INT, col)比CONVERT(INT, col)安全，失败返回 NULL 而非中断，适合脏数据场景 - 注意 collation：MySQL 中
VARCHAR列若 collation 不同（如utf8mb4_0900_ai_civsutf8mb4_unicode_ci），即使都用CONVERT也无法消除隐式转换开销
比 CAST 更稳妥的替代方案
真正治本的方式不是加转换，而是减少转换发生的机会：
- 建表时约定：ID 类字段统一用
BIGINT，编码类（订单号、流水号）统一用VARCHAR并加前缀约束（如CHECK (id LIKE 'ORD%')） - 视图定义中禁止对 JOIN 字段做任何类型转换，保留原始类型；上层查询用范围条件代替函数包裹（如用
created_at >= '2024-01-01' AND created_at 替代 <code>DATE(created_at) = '2024-01-01'） - UNION ALL 各分支必须显式
CAST到同一类型，优先选低精度类型（INT优于NUMERIC(15,2)），否则中间结果会膨胀
最易被忽略的一点：类型不匹配往往和 NULL 处理交织。当两边字段允许 NULL 且类型不同，优化器可能误判连接算法（比如放弃哈希连接），这时光靠 CAST 解决不了问题，得结合 COALESCE 或提前过滤 IS NOT NULL。
