直接JOIN多张审核表易出错，因多级审核存在跳过、未触发等中间态，且需将原始status映射为统一业务语义；应通过视图用CASE按层级优先级判断有效状态，并显式处理skipped和not_started。
为什么直接 JOIN 多张审核表查状态容易出错
因为多级审核通常对应多张状态表（如 approval_level1、approval_level2、approval_final），每张表都有自己的 status 字段（可能是 'pending'/'approved'/'rejected'/'skipped'），且逻辑依赖顺序：只有上一级通过，下一级才生效。硬写 JOIN 容易漏掉「跳过」或「未触发」场景，导致状态误判为 NULL 或默认值。
更麻烦的是，业务方要的不是原始字段值，而是统一语义的状态，比如把 'pending' + 'skipped' + 'skipped' 映射成 'waiting_final'，这种转义逻辑散落在每个查询里，维护成本高。
用视图封装状态优先级和转义规则
核心思路是：在视图里用 CASE WHEN 按审核层级从高到低判断有效状态，并内置映射表。不是简单拼字段，而是模拟“状态机”流转。
- 先用
COALESCE或嵌套CASE找出「当前实际生效的最高级状态」——例如 level2 存在且不为'skipped'，就忽略 level1 - 再用外层
CASE把原始状态值转成业务语义，比如WHEN 'approved' THEN 'passed' - 必须显式处理
NULL（代表该级未启动）和'skipped'（代表被规则跳过），否则会漏掉中间态
示例片段：
CREATE VIEW document_approval_status AS
SELECT
d.id,
d.title,
CASE
WHEN f.status = 'approved' THEN 'final_passed'
WHEN f.status = 'rejected' THEN 'final_rejected'
WHEN l2.status = 'approved' THEN 'waiting_final'
WHEN l2.status = 'rejected' THEN 'level2_rejected'
WHEN l1.status = 'pending' THEN 'waiting_level1'
ELSE 'draft'
END AS overall_status
FROM documents d
LEFT JOIN approval_level1 l1 ON d.id = l1.doc_id
LEFT JOIN approval_level2 l2 ON d.id = l2.doc_id
LEFT JOIN approval_final f ON d.id = f.doc_id;
视图里怎么安全处理「跳过」和「未触发」状态
关键不是存不存在记录，而是「该级是否被有意跳过」。很多实现错误地把 LEFT JOIN 后的 l2.status IS NULL 当作「未触发」，但其实可能是数据缺失。正确做法是：审核表必须有明确的 skip_reason 字段或 is_skipped 标志位。
- 在视图中，优先检查
l2.is_skipped = true，再看l2.status，避免把跳过误判为 pending - 对「未触发」状态，统一用
'not_started'而非NULL，方便应用层判断 - 如果某级允许自动跳过（如金额
性能和兼容性要注意什么
视图本身不提升性能，反而可能让执行计划变差——特别是当底层表没建好索引，或视图里用了标量函数时。
- 确保每张审核表的
doc_id字段都有索引，否则LEFT JOIN会全表扫描 - 避免在视图里调用自定义函数（如
get_display_status()），MySQL/PostgreSQL 对这类函数的优化很弱 - PostgreSQL 可以用
MATERIALIZED VIEW缓存结果，但需定期刷新；MySQL 没原生支持，得用定时任务+临时表模拟 - 如果应用需要按
overall_status查询，别在视图上直接WHERE overall_status = 'waiting_final'，先在物化列或冗余字段里存好
最常被忽略的一点：视图里的状态映射一旦上线，就不能随意删改枚举值。下游报表、BI 工具甚至前端代码可能已硬编码了 'waiting_final'，改名等于接口变更。
