不可行。触发器无法跨行聚合统计null率，仅能访问当前行数据，查全表易致死锁或超时；应改用物化视图+定时刷新、存储过程封装或异步pipeline实现字段完整度评估。
用触发器实时统计字段 NULL 率可行吗？
不可行。触发器本身不支持跨行聚合（如 COUNT(*)、COUNT(column)），也无法在插入/更新时直接算出「当前全表该字段的 NULL 比例」——它只能访问刚操作的那行数据，看不到历史。强行在触发器里查全表还可能引发死锁或性能雪崩，尤其在高并发写入场景下。
常见错误现象：ERROR: cannot execute SELECT in a trigger function（当使用 BEFORE 触发器并尝试查询同表时）；或触发器执行超时、阻塞后续写入。
- 触发器适合做单行校验（如非空约束、格式检查），不适合做统计类评分
- 若硬要用，必须改用
AFTER触发器 + 异步队列（如 pg_notify + 外部监听），但已脱离“纯 SQL 自动化”范畴 - 字段完整度本质是批处理指标，应与 ETL 或调度任务绑定，而非强耦合到 DML 流程
用物化视图+定时刷新模拟“自动评分”
PostgreSQL 9.3+ 支持 MATERIALIZED VIEW，可固化字段完整度快照，再配合 REFRESH MATERIALIZED VIEW CONCURRENTLY 实现低干扰更新。这是目前最贴近“SQL 原生自动化”的方案。
示例：对 users 表的 email 字段计算完整度
CREATE MATERIALIZED VIEW users_email_completeness AS SELECT COUNT(*)::float AS total, COUNT(email)::float AS non_null, ROUND(COUNT(email)::float / NULLIF(COUNT(*), 0), 4) AS completeness_score FROM users;
- 刷新命令：
REFRESH MATERIALIZED VIEW CONCURRENTLY users_email_completeness（需主键或唯一索引） - 用
pg_cron扩展可设定时任务，例如每天凌晨 2 点执行刷新：SELECT cron.schedule('0 2 * * *', 'REFRESH MATERIALIZED VIEW CONCURRENTLY users_email_completeness'); - 注意
CONCURRENTLY不支持无索引的物化视图，且无法在刷新期间做 DML，需权衡窗口期
用存储过程封装评分逻辑并支持多字段批量扫描
把字段完整度计算抽象成可复用的函数，避免重复写 SQL。核心是动态拼接查询，遍历 information_schema.columns 获取目标表字段列表。
示例函数（PostgreSQL）：
CREATE OR REPLACE FUNCTION calc_column_completeness(table_name TEXT)
RETURNS TABLE(col_name TEXT, completeness_score NUMERIC) AS $$
BEGIN
RETURN QUERY EXECUTE format(
'SELECT column_name::text,
ROUND(COUNT(%I)::float / NULLIF(COUNT(*), 0), 4)
FROM %I
GROUP BY 1',
table_name, table_name
);
END;
$$ LANGUAGE plpgsql;
- 调用：
SELECT * FROM calc_column_completeness('orders'); - 实际使用中需替换为更健壮版本：过滤掉系统字段（
WHERE table_schema = ''public''）、跳过数组/JSON 类型（易报错）、加异常捕获 - 该函数返回的是每字段独立得分，不是整表综合分；如需加权汇总（如 email 权重 0.4、phone 权重 0.3），得在外层再包一层聚合逻辑
为什么不能只看 NULL 率？真实场景要叠加语义规则
字段值不为 NULL，不代表质量合格。比如 phone 字段填了 '123' 或 'N/A'，NULL 率是 0%，但实际是脏数据。
- 建议组合判断：先筛出非空值，再用正则校验格式（
phone ~ '^1[3-9]\d{9}$'）、用长度限制（LENGTH(email) > 5）、排除枚举外值（status NOT IN (''active'', ''inactive'')） - 把这类规则存进配置表（如
data_quality_rules），用 JOIN 动态加载，比硬编码在 SQL 里更可持续 - 触发器连单字段基础 NULL 判断都吃力，更别说嵌套正则和多条件组合——这进一步说明：数据质量评分必须脱离 DML 实时链路，走异步、可配置、可追溯的 pipeline
真正难的不是算出一个数字，而是让这个数字能被业务信任：谁定义的规则、什么时候跑的、哪些样本被排除、异常是否告警。这些超出 SQL 能力边界，得靠元数据管理+调度日志+可观测性补全。
