字符串查数字字段慢是因为数据库隐式转换导致索引失效，如WHERE user_id = '123'使INT列转字符串，触发全表扫描；修复需保持类型一致，优先用数字字面量而非CAST。
WHERE 条件里用字符串查数字字段，为什么慢得离谱
因为数据库会悄悄把整数列转成字符串再比对，导致索引失效。比如 user_id 是 INT 类型，但你写 WHERE user_id = '123'，MySQL 或 PostgreSQL 都可能放弃走 user_id 索引，改用全表扫描。
- 典型错误现象：
EXPLAIN显示type=ALL或rows高得异常，哪怕只查一条 - 常见场景：前端传参没校验类型、ORM 自动生成 SQL 时把数字当字符串拼接、视图定义里混用类型
- 修复核心：让两边类型严格一致——要么都用数字字面量，要么显式转换（但优先前者）
- 示例：
WHERE user_id = 123✅；WHERE CAST(user_id AS TEXT) = '123'❌（强制转反而更糟）
视图定义中 CAST 和 :: 的性能陷阱
在视图里用类型转换看似“安全”，实则可能把底层可下推的过滤条件堵死。比如源表有 created_at TIMESTAMP，视图里写成 created_at::DATE，外部查询 WHERE created_date = '2024-01-01' 就无法下推到基表索引。
- 关键影响：视图层类型转换 = 放弃基表索引 + 增加中间结果集体积
- 替代方案：视图尽量保持原始类型；需要日期维度时，用计算字段（如
created_date AS (created_at::DATE)）并确保上层查询仍能命中基表索引 - PostgreSQL 注意：
::是隐式绑定，和CAST()行为一致；SQL Server 用CONVERT()同样有这问题 - 验证方法：对视图执行
EXPLAIN，看Filter出现在哪一层（基表？还是视图物化后？）
JOIN 时字段类型不匹配导致临时表膨胀
两个表 JOIN，一边是 BIGINT，一边是 VARCHAR(20)，数据库大概率会把整张右表转成数字再比——这意味着每行都要做一次字符串解析，还可能因格式不合法产生隐式 NULL，最终触发临时表 + 文件排序。
- 错误信号：
EXPLAIN出现Using temporary; Using filesort，且rows比预估大几倍 - 真实案例：用户表
id BIGINT和日志表user_id VARCHAR关联，日志表千万级，JOIN 耗时从 200ms 涨到 12s - 根治方式：统一字段类型（推荐改
VARCHAR列为BIGINT并清理脏数据），而非在 SQL 里加CAST - 临时缓解：若无法改表结构，至少在 JOIN 条件里把字符串侧转成数字：
ON logs.user_id::BIGINT = users.id（PostgreSQL），但仍是权宜之计
视图里 UNION ALL 各分支返回类型不一致的隐式开销
UNION ALL 要求所有分支对应列类型一致，否则数据库会选一个“公共超类型”做隐式提升。比如一个分支返回 INT，另一个返回 NUMERIC(10,2)，结果列就会变成 NUMERIC(15,2) —— 看似无害，但在大结果集上会多占内存、拖慢网络传输，且后续 WHERE 过滤也无法利用原字段索引。
- 排查手段：查视图定义，对每个
SELECT分支的列执行\d+ view_name（PostgreSQL）或sp_help 'view_name'（SQL Server），看实际列类型 - 修复动作：显式用
CAST统一为最简类型（如都转INT而非NUMERIC），宁可提前报错也不留隐式转换 - 特别注意：JSON 字段参与
UNION时，不同数据库对JSONvsTEXT的隐式规则差异极大，容易踩坑
最麻烦的不是发现隐式转换，而是它藏在视图嵌套三层之后，而 EXPLAIN 只显示最终执行计划。调的时候得一层层剥开视图定义，盯着每一列的源头类型看。
