用视图封装统计逻辑可固化口径，避免随意修改；需显式声明字段、添加注释说明语义；复杂逻辑进一步封装为函数，强制复用并提升一致性与可维护性。
用视图封装统计逻辑，避免直接查表
统计口径一旦写死在应用代码或临时 SQL 里，就极容易被后续开发随意改写。最直接的防护是把口径固化在数据库层——用 CREATE VIEW 把计算逻辑（如去重规则、时间过滤条件、状态过滤值）封装成只读视图。业务方查 v_user_active_count 而不是手写 COUNT(DISTINCT user_id) 加一堆 WHERE，改动必须走 DDL 变更流程，天然卡住随意修改。
注意点：
- 视图不带参数，所以时间范围这类动态条件仍需外部传入，但核心过滤逻辑（如
status IN ('active', 'trial')）必须写死在视图定义里 - MySQL 5.7+ 和 PostgreSQL 支持
WITH CHECK OPTION，可防止通过视图意外更新底层数据（虽统计视图通常只读，但加一层保险） - 别在视图里用
SELECT *，字段名变更会导致下游报错，显式列出字段更稳定
给统计字段加注释，让 WHERE 条件“自带说明书”
光有视图还不够。当别人看到一个字段叫 pay_amount，他怎么知道这是含税还是不含税？是否剔除了退款订单？靠口头约定或文档链接？不现实。直接在数据库字段级加注释，让语义随字段走：
COMMENT ON COLUMN order_stats.pay_amount IS '净收款：已支付且未退款的订单金额总和，不含运费和税费，单位为分';
PostgreSQL 和 MySQL 8.0+ 都支持该语法。DBA 或 BI 工具（如 Superset、Tableau）能自动读取并展示这些注释，下次有人想“优化”查询时，一眼就能看到约束条件，降低误改概率。
用函数封装复杂口径，强制复用而非复制粘贴
有些口径逻辑绕，比如“近30天活跃用户”要处理跨月、节假日补签、设备去重等。如果每次都在 SQL 里重复写 DATE_SUB(CURDATE(), INTERVAL 30 DAY) + 子查询嵌套，迟早有人抄错。不如封装成标量函数：
CREATE FUNCTION get_active_user_count(p_date DATE) RETURNS INT READS SQL DATA
BEGIN
RETURN (
SELECT COUNT(DISTINCT user_id)
FROM user_login_log
WHERE login_time >= DATE_SUB(p_date, INTERVAL 30 DAY)
AND login_time < p_date
AND device_type IN ('ios', 'android')
);
END;
这样业务 SQL 只需写 SELECT get_active_user_count('2024-06-01');。函数本身受版本控制（配合 Flyway/Liquibase），调用方无法绕过逻辑，也方便统一打日志或加缓存。
权限隔离：禁止普通账号直接操作基础事实表
再严密的封装也挡不住有 SELECT 权限的人直接查 order_detail 表然后自己写聚合。必须做权限收口：
- 撤销开发/分析师账号对原始明细表（如
event_log、transaction_raw）的SELECT权限 - 只授予其对视图、函数结果、汇总宽表（如
dim_user_daily）的查询权 - DBA 定期用
SHOW GRANTS FOR 'dev'@'%'检查权限是否漂移
权限不是一设永逸的事，尤其当 DBA 换人、新集群上线时，最容易漏掉这步。真正的防护是让“想改口径”这件事，从技术上变得比“走审批流程”还麻烦。
