视图定义中避免使用cast或类型转换——会导致索引失效、join变慢、group by错乱；因阻断查询下推，where条件无法下推至基表，致使性能骤降。
别在视图定义里用 CAST 强制转类型——它不会报错，但会让索引失效、JOIN 变慢、GROUP BY 结果错乱。
视图字段用 :: 或 CAST() 转日期/数字，为什么反而更慢？
PostgreSQL 写 created_at::DATE、SQL Server 写 CONVERT(DATE, created_at)，看似“类型明确”，实则阻断查询下推。数据库无法把外部 WHERE created_date = '2024-01-01' 下推到基表，只能先物化整个视图再过滤。
- 验证方法：对视图执行
EXPLAIN，如果Filter出现在Subquery Scan层而非基表扫描层，说明已失能 - 真实代价：千万级表上，
WHERE条件从毫秒级涨到秒级，内存占用翻倍 - 替代做法：视图保留原始类型（如
TIMESTAMP），上层查询用范围条件，例如WHERE created_at >= '2024-01-01' AND created_at
UNION ALL 各分支列类型不一致，CAST 会悄悄放大中间结果
一个分支返回 INT，另一个返回 NUMERIC(10,2)，数据库会统一升格为 NUMERIC(15,2)。这不只是精度变化——它让原本可下推的聚合、排序、JOIN 全部失效，还可能因隐式 NULL 导致行数膨胀。
- 典型信号：
EXPLAIN显示Rows比预估高几倍，且出现Using temporary - 检查方式：PostgreSQL 中运行
SELECT pg_typeof(col) FROM (your_union_query) t；MySQL 查INFORMATION_SCHEMA.COLUMNS - 修复动作：所有分支显式转成同一类型，优先选精度低、存储小的类型（如都转
INT而非NUMERIC）
视图里 JOIN 字段类型不匹配，CAST 在 ON 条件中也救不了索引
视图封装了多层逻辑，ON t1.id = t2.user_id 看似正常，但若 t1.id 是 BIGINT、t2.user_id 是 VARCHAR，数据库会在每次调用视图时对右表每行做字符串解析——而你根本看不到这个开销，只看到查询越来越慢。
- 错误现象：
EXPLAIN中type是ALL或range，key为空，Extra含Using where; Using join buffer - 临时缓解：PostgreSQL 可写
ON t2.user_id::BIGINT = t1.id；SQL Server 用ON CAST(t2.user_id AS BIGINT) = t1.id - 但注意：这种写法在 MySQL 中大概率仍无法走索引，因为
CAST作用于字符串列，优化器无法利用索引
最常被忽略的点是：视图不是“数据容器”，而是“查询模板”。一旦你在定义里加了类型转换，就等于提前锁死了执行路径——后续所有调用都得按这个路径走，哪怕只是查一行。
