不能直接union多张日志表，因字段数不等、类型不兼容、缺失列多而报错；需通过视图统一映射event_time、source_type、event_type、payload四标准列，并用coalesce/case处理缺失与歧义，避免视图中过滤导致性能下降。
为什么不能直接 UNION 多张日志表
因为字段名不一致、类型不兼容、缺失列太多，UNION 会直接报错，比如 ERROR: each UNION query must have the same number of columns 或 cannot cast type text to timestamp without time zone。视图不是“魔法”，它只是封装了转换逻辑——你得先手动对齐字段语义和类型。
建视图前必须统一的 4 个字段维度
日志表再异构，业务上通常都逃不开时间、来源、事件、上下文这四类信息。视图要强制映射到这四个标准列，其他字段可选挂载为 JSON：
-
event_time：全部转成TIMESTAMP WITH TIME ZONE，用TO_TIMESTAMP()或CAST(... AS TIMESTAMPTZ)，注意时区（如原始是 UTC+8 字符串，得补'+08'） -
source_type：硬编码字符串，如'nginx_access'、'app_error_log'，别依赖原表字段名 -
event_type：从原表提取关键动作，比如从nginx_log.status推断'http_5xx'，或从app_log.level映射为'error'、'warn' -
payload：把所有无法标准化的字段打包成JSONB，用TO_JSONB(ROW(...))或显式构造键值对，避免后续查字段时又掉坑里
用 COALESCE 和 CASE 处理字段缺失与歧义
某张表没有 user_id，另一张只有 uid，第三张存的是 session_id —— 这时候不能靠猜，得按优先级兜底：
COALESCE( nginx_log.remote_user, app_log.user_id, NULLIF(app_log.session_id, '') ) AS user_id
更关键的是语义歧义：比如 status 在 Nginx 表里是 HTTP 状态码，在数据库慢查日志里却是执行状态（'success'/'timeout'）。必须用 CASE WHEN source_type = 'nginx_access' THEN ... ELSE ... END 分开处理，否则视图一查就错。
性能陷阱：别在视图里做模糊匹配或函数索引失效操作
视图定义里如果写了 WHERE log_line ILIKE '%ERROR%' 或 EXTRACT(YEAR FROM event_time) = 2024，PostgreSQL 无法下推过滤，每次查询都会全表扫原表。正确做法是：
- 只在视图里做字段映射和类型转换，不加 WHERE
- 需要按时间范围查？让上层 SQL 写
SELECT * FROM unified_logs WHERE event_time >= '2024-01-01'，确保能走原表上的event_time索引 - 真要文本搜索，原表先建
GIN(log_line gin_trgm_ops)，视图里保留原始字段，别提前LOWER()或REPLACE()
视图不是优化器，它只是语法糖；真正影响性能的是底层表结构、索引和查询写法。最容易被忽略的是：你以为视图能复用计算结果，其实每次 SELECT 都重算一遍 CAST 和 JSONB 构造 —— 如果日志量大，这个开销比你想象中高得多。
