1. 那场“报表口径对不上”的事故，根子出在约束缺失
1.1 事故现场：一个字段里出现了六种状态
干了这么多年数据相关的工作，我最怕听到一句话：“这表的约束条件先不定了，后面再加，先让业务跑起来。”
这话听着耳熟，对吧？可这恰恰是很多项目埋雷的开始。我印象最深的一次事故，是给一家电商公司做订单中心的数据治理。当时业务方过来投诉，说库存和财务两个部门拉出来的“在途订单”金额对不上，一个报三百多万，一个报两百多万，谁都不承认自己错。我当时第一反应是去查查询逻辑，结果查了两天代码，最后发现根子根本不在查询，而在表本身。
那是一个用了将近一年的订单表，按业务规范，状态字段一共就四种：待支付、已支付、已发货、已完成。结果我打开数据库一看，status 字段里躺着整整六种值。除了四个正常值之外，还有带空格的 '已发货 '，以及两个“人工创造”的值：'已出库' 和 '已shipped'。财务那边统计的是“已发货”，仓库那边统计的是“已出库”，实际对应的是同一批订单。两边都对，但口径就是合不上。
这种问题，懂行的人一眼就能看出来：这张表建表的时候，根本没有给 status 字段定义任何约束条件。它就是一个普通的文本字段，谁都能往里写，怎么写都行。
1.2 排查过程：应用层、ETL、手工导入三条写入链路全失控
后来我把写入这条表的所有路径都拉了一遍，发现问题远比想象中严重。这个订单表的写入入口至少有四个：Java 后管系统写订单时会做枚举校验，只允许四个合法值；但另一个老旧的 PHP 接口压根没校验；还有一组 Python 自动拉表脚本，每天从公司 CRM 系统拉数据批量插入，用的是最粗暴的 executemany，直接把接口返回的字符串原样塞进数据库；再加上 DBA 偶尔手工跑 SQL 修复数据，用 UPDATE 直接改字段，改完还不自查。
你看，这四条写入链路，校验逻辑完全是各写各的。Java 那套写得还算规范，PHP 和 Python 那边基本就是裸奔。平时看着没事，一旦某个接口升级、某个字段语义发生变化，脏数据就悄悄混进去了。等发现问题的时候，库里已经有上千条状态异常的数据，靠应用层去修，得一条条查、一条条改，成本远超当初建表时写一条约束的时间。
这个案例让我彻底意识到一件事：约束条件如果不写在数据库里，那它就不是真正的约束，而只是“应用层的约定”。
1.3 根因：约束没有下沉到数据库这一层
很多人觉得，我在代码里做了参数校验，前端也限制了输入框的下拉选项，为什么还要在数据库里再加一层约束？这两者的性质完全不一样。
应用层的校验，本质上默认了一个前提：所有数据都必须经过你这套代码。但真实环境里，数据写入除了走应用接口，还有后台任务、定时同步脚本、数据迁移工具、手动 SQL，甚至某些同事为了方便直接改库。这些路径往往不受应用层校验约束，一旦有人绕过，数据就是裸奔状态。
所以，表的约束条件，是数据入库前的最后一道物理闸门。它跟应用层校验不是二选一的关系，而是互补关系：应用层管“正常流程下不让坏数据进来”，数据库约束管“任何流程下都不允许坏数据存在”。这道闸门一旦缺口，后面所有的报表、统计、数据迁移、跨部门协作，都会在某个时间点莫名其妙地翻车。
那么，数据库里到底有哪些约束条件可用？各自的适用场景和坑又在哪里？我结合这次订单中心重构的实战经验，把六类约束逐个过一遍。
2. 六类约束逐个过：定义、使用场景和最容易踩的坑
2.1 非空约束（NOT NULL）：最基础，也最容易被“绕开”
非空约束是最好理解的一类，它要求字段必须有值。但实际业务里，最容易出问题的恰恰是它。
我见过一个非常典型的场景：订单表里加了一个“渠道来源”字段，用来标记订单来自 App、小程序还是电话销售。开发团队在新增字段时没有加 NOT NULL，理由是“老数据没有这个值，加了非空约束会写入失败”。听起来合理，对吧？但问题是，你也没给默认值。结果就是，新订单来源正常写入，老订单来源全是 NULL。半年后要做渠道转化分析，发现早期订单的来源占比统计全都失真，还得写脚本回补，可历史数据早就丢了上下文信息，根本补不回来。
我的建议非常明确：凡是业务上必然会有值的字段，直接 NOT NULL。如果确实存在历史数据补不了的情况，那就先按业务逻辑回填一个兜底值（比如 “未知”），再收紧为非空，而不是留着 NULL 不管。数据库里 NULL 不是一个普通的值，它在聚合计算、分组统计、条件判断里的表现跟正常值完全不同，稍不留神就是一条错误报表的来源。
2.2 默认值约束（DEFAULT）：变更时的一颗隐形炸弹
默认值约束平时不起眼，但它有一个非常实际的作用：保证插入新记录时，某些字段即使没被显式赋值，也能拿到一个合理值。
默认值真正的坑，出现在“给已有的大表新增字段”这种变更场景里。比如你给一张有七百万行数据的业务表加一个“数据版本”字段，默认 1。如果数据库版本比较老，这个操作会对整张表做全量改写，期间表的写入会被锁住，线上业务直接卡顿。但如果你用的是 MySQL 8.0，ALTER TABLE ADD COLUMN 配合 INSTANT 算法，新增字段就是秒级操作，因为只改了元数据，不碰数据行。这个差异在实际运维中非常致命，我建议在变更前先确认数据库版本和 DDL 算法，不要想当然。
另外，默认值不要用“看起来合理但会过期的值”。比如默认时间用 '2020-01-01'，这类固定值容易让业务方误读为真实业务时间。更推荐的做法是，时间字段默认用数据库当前的日期时间，让工具函数去生成，保持一致。
2.3 唯一约束（UNIQUE）：去重正确性的分水岭
唯一约束保证某一列或某几列的组合值在全表范围内不重复。这是我最看重的一类约束，因为它解决的是“数据的唯一性”问题，而唯一性又是很多业务逻辑的底层前提。
但唯一约束也有三个容易忽略的细节。
第一个，NULL 可以重复多次。在很多数据库里，唯一约束对 NULL 值不生效，也就是说，你建了唯一索引的列，如果允许 NULL，那么这一列可以存在多条 NULL 记录。如果你期望“这一列最多出现一次空值”，那光靠唯一约束是拦不住的。
第二个，组合唯一索引的字段顺序会影响索引利用效率。比如你建了 (user_id, product_id) 的组合唯一索引，查询条件里如果只有 product_id，那这个索引大概率用不上。反过来，如果你的高频查询是按 user_id 维度做的，把 user_id 放前面就更高效。
第三个，业务上有些“有效记录唯一”的需求，不能简单用常规唯一约束实现。比如同一客户同一商品只能有一条有效订单，但历史已关闭的订单可以有无数条。PostgreSQL 可以直接建部分唯一索引，把生效条件写进索引定义；MySQL 8.0 没有部分索引，但可以通过生成列加唯一索引变相实现。我建议在设计阶段就把这类“半唯一”需求想清楚，别等到上线后才发现唯一约束把正常业务也拦住了。
2.4 主键约束（PRIMARY KEY）：表的心跳
主键约束本质上就是唯一约束加非空约束的组合，但它还有一个额外职责：大多数关系型数据库里，主键决定了数据的物理组织方式。MySQL 的 InnoDB 是聚簇索引表，主键顺序就是数据行的物理存储顺序；Oracle 这类堆表虽然存储顺序不由主键决定，但主键依然是索引访问的核心路径。
所以，主键选型不能只考虑“会不会重复”，还要考虑写入性能和存储分布。自增主键写入时追加到索引尾部，对聚簇索引非常友好；UUID 主键因为随机性太强，插入时会频繁触发索引页分裂和碎片化，批量写入性能会明显下降。很多团队在分布式场景下用雪花 ID 或基于业务生成的分布式 ID，这时候要格外注意：如果 ID 不是趋势递增的，你的索引维护成本会比自增主键高出一截。这不是说 UUID 不能用，而是你得知道它的物理代价，并且在索引表空间、批量写入策略上做补偿。
2.5 检查约束（CHECK）：性价比最高，也最被低估
回到开头那个订单状态字段的事故，最直接的解药就是 CHECK 约束。它可以在建表时直接限定字段的合法取值，比如 status 只能取四个枚举值之一，其他值一概拒绝写入。这样哪怕 Python 脚本、PHP 接口全部失控，数据库这层仍然能守住底线。
但这里必须提醒一个历史坑：MySQL 8.0.16 之前，CHECK 约束是“只解析、不执行”的。也就是说，你写了 CHECK 约束，建表不报错，但它实际上什么都不管，脏数据依然能进去。很多老项目说“我加了 CHECK”，实际上形同虚设。如果你还在用老版本的 MySQL，要么尽早升级到 8.0.16 以上，要么把这个约束的“垃圾数据过滤”职责交给唯一约束加应用层合并实现。Oracle、PostgreSQL、SQL Server 的 CHECK 约束都是真正生效的，这一点比老版本 MySQL 省心得多。
CHECK 约束还有一个注意事项：它不能引用别的表的列，也不能包含子查询，只能基于当前行的字段做判断。所以它适合的是枚举值校验、范围校验这类单行逻辑，不适合跨行、跨表的一致性校验。
2.6 外键约束（FOREIGN KEY）：爱与恨的边界
外键约束是在多表场景下保证数据引用一致性的核心手段，也是最容易被性能优化“误伤”的一类约束。
很多做高并发系统的架构师会明确告诉你：分库分表以后别用外键，外键会影响写入性能。这个说法没错，但你不应该因为高并发场景不用外键，就否定外键在所有场景的价值。在权限管理系统、订单明细表、配置关联表这类数据量不大、一致性要求极高的内部系统里，外键约束的价值非常大。它能保证你永远删不掉一个“已经被子表引用”的父记录，不会出现孤儿数据。
用外键要注意三点。第一，父子表删除顺序：删除父表数据前，必须处理完子表引用，否则约束直接报错；如果你想级联删除，可以在外键定义里明确 ON DELETE CASCADE。第二，外键列尽量建索引，InnoDB 在检查外键约束时，需要快速定位子表和父表的匹配行，没有索引的话性能会很难看。第三，约束一定要命名，比如 fk_order_user_uid，否则系统自动生成的随机约束名，后面想 DROP 都找不到对象。
我把这六类约束的特性和适用场景整理成一张表，方便对照：
| 约束类型 | 作用 | 典型误用 | 适合场景 |
|---|---|---|---|
| NOT NULL | 禁止空值 | 对存在历史空值的大表直接添加导致失败 | 业务必然有值的字段 |
| DEFAULT | 未写入时提供默认值 | 用固定日期或过期值当默认值 | 状态、时间、版本等回填字段 |
| UNIQUE | 保证行或组合不重复 | 忽略 NULL 重复、忽略组合顺序 | 手机号、订单号、关联关系 |
| PRIMARY KEY | 唯一标识一行 | 用业务高频变值当主键 | 自增ID、雪花ID |
| CHECK | 限定取值/范围 | 老版本 MySQL 形同虚设 | 枚举状态、范围校验 |
| FOREIGN KEY | 跨表引用一致性 | 高并发分库表盲目使用 | 内部管理、低频关联表 |
3. 几千万行大表加约束，这笔性能账怎么算
3.1 约束检查的隐藏成本
约束不是免费的，每一次 INSERT、UPDATE，数据库都要额外执行校验动作。唯一约束每次写入都要查一遍索引确认没有重复；外键约束每一行都涉及到父表和子表的定位查找；非空约束虽然快，但也是一次额外的判断。这些开销在几千行的小表上完全无感，但到了几千万行的大表，就是实打实的性能账单。
我之前在一个订单归档项目里测过一组数据：同样一批 500 万行的批量写入，表上有主键加一个唯一索引的情况下，写入耗时比无索引状态高出大约 35% 到 50%。这里的差距主要来自唯一索引的查找和页分裂维护。所以大表设计时，索引和约束都要“精”，不能“多”。每加一个唯一约束，就意味着每次写入多一次索引查找，这个成本会随着表行数增长而线性放大。
3.2 大表加唯一约束：先查重复，再建索引，最后加约束
如果一张几千万行的表已经存在，你现在需要给它加一个唯一约束，正确顺序不是直接 ALTER TABLE ADD CONSTRAINT，那个操作极容易在历史数据校验阶段全表锁死，而且一旦发现历史数据有重复，整个变更直接失败回滚。
我的标准三步法是这样的。第一步，先跑一遍重复检查，用 GROUP BY 找出按目标列分组后出现次数大于 1 的候选行，先把重复数据清理掉，否则后面必然失败。第二步，在线创建唯一索引，MySQL 用 ALGORITHM=INPLACE, LOCK=NONE 的方式，Oracle 用 ONLINE 关键字，PostgreSQL 可以直接 CREATE UNIQUE INDEX CONCURRENTLY，这样索引构建期间业务写入不会完全中断。第三步，索引建好后，再用 ALTER TABLE ... ADD CONSTRAINT ... UNIQUE USING INDEX 把约束挂在同名索引上，这一步基本只改元数据，速度快。
这个过程里最容易翻车的不是 SQL 本身，而是业务方对“唯一”的理解。很多时候你以为只有一列需要唯一，实际业务里唯一性是“多列组合”。比如客户表和订单表合并时，真正唯一的是 (customer_id, order_type, order_date)，光给单列建唯一约束根本没意义。所以在动手之前，一定要跟业务确认清楚唯一键的颗粒度。
3.3 锁表与 DDL 的真实代价
“mysql 锁表”这个词在很多团队里是个高频痛点。约束变更本质上是 DDL 操作，而 DDL 操作在多数数据库里都会牵动表的锁定。MySQL 8.0 虽然把 DDL 改成了原子操作，支持在线加索引，但大表上的 ALTER TABLE 仍然可能长时间占用资源，导致后续 DML 排队，看起来和“锁表”没有区别。
更隐蔽的是外键相关表的连锁锁。如果你要给父表加约束或做结构变更，MySQL 会检查所有引用这张表的外键关系，关联的子表也可能被一起锁定。我有一次在订单主表上做在线索引添加，结果关联的订单明细表也出现了写入阻塞，查了大半天才定位到外键元数据锁的传递。所以在大表上做 DDL 之前，我建议把变更窗口放在业务低峰期，并且提前用 information_schema 查一下这张表的依赖关系。
3.4 辅助索引避免回表：约束索引的顺带红利
大表查询性能优化的一个热门话题是“辅助索引如何避免回表”。它的原理很简单：如果查询需要的所有列都包含在一个辅助索引里，数据库就可以只扫索引页，不需要回表访问数据行。这个机制叫覆盖索引。
和约束有什么关系？关系在于，约束自动生成的索引是可以被查询优化器复用的。比如你在 (user_id, order_time) 上建了一个唯一约束，那么这条组合索引天然就能覆盖“按用户查最近订单”这类查询，不需要再额外建一张重复的辅助索引。我见过很多团队在已有唯一索引的情况下，又因为“查询慢”而重复建同样字段的普通索引，白白浪费空间和写入成本。约束索引在设计时可以顺带考虑查询负载，让一个索引同时承担约束和加速双重职责。
3.5 索引表空间：Oracle 场景下的存储细节
“oracle 建立表空间”和“索引表空间”这两个热词放在一起，其实涉及一个实践细节：在 Oracle 里，可以把表数据和索引数据放在不同的表空间。用户表放在数据表空间，索引放在索引表空间，这样可以在物理层面把随机读和顺序写分离，减少 I/O 竞争。
比如新建一个业务表空间和配套索引表空间，然后创建用户并授限，再指定表默认落在业务表空间，索引统一落到索引表空间。对于几千万行的分区大表，这种物理分离是有实际收益的。MySQL 的 InnoDB 则统一用 ibd 表空间，没有这种分离能力，所以 Oracle 场景下尤其值得养成“建表就指定表空间”的习惯，别等数据量上来后再迁移，那又是一次全表搬家的折腾。
4. 建表、迁移和自动拉表过程中的约束一致性隐患
4.1 建表异常：那些你没注意到的约束细节
建表阶段最容易翻车的，不是不了解约束语法，而是细节层面的疏忽。
第一个问题是约束命名。很多开发建表时不指定约束名，数据库就自动生成一串带时间戳的随机字符。表面上看没什么影响，直到你需要删除某个约束时，发现根本不知道它的完整名字，只能去系统表里翻。我建议所有约束都统一命名规范：主键 pk_表名_字段，唯一 uk_表名_字段，外键 fk_表名_列名，检查 ck_表名_字段。
第二个问题是字段类型不一致导致的隐式转换。比如外键关联的两个表，一边是 VARCHAR(32)，另一边是 CHAR(32)，看起来长度一样，但字符语义不同，关联时可能产生隐式转换，索引失效，查询变慢。建表时关联字段的类型、长度、字符集必须保持一致。
第三个问题是默认值写函数。有些数据库允许静态默认值，有些允许表达式，但表达式默认值如果每次插入都执行，会带来不必要的开销。能写静态默认值就别写动态函数，除非业务确实需要。
4.2 重建表的正确姿势：DROP 之前先想清楚
热词里有“oracle 重新建表，如果有删除掉后再重新创建”，这种操作模式看着简单，实则容易出事。直接 DROP TABLE 再 CREATE TABLE，表面上新表结构和原来一样，但原来的权限授权、同义词、依赖视图、外键关系，全都会被连带处理，重建后并不自动恢复。
我在实际项目中更推荐“四步切换法”：先创建一张带完整约束的新表，再通过 INSERT INTO ... SELECT 把旧表数据迁移过去，然后做一次数据校验，确认新表行数和关键字段跟旧表完全一致，最后在维护窗口内切换表名、删掉旧表。整个过程里，新表的约束是建表时就定义好的，不会出现“删了旧约束忘了加新约束”的真空期。
如果你非要走删除重建的老路，至少先查清楚这张表被哪些视图、存储过程、外键依赖，并把这些依赖对象的重建脚本准备好，再动手。
4.3 跨表合并时约束只合了一半
“跨表合并”也是热词。两个系统的客户表合并，或者多个渠道的物料表合并，是最容易暴露约束设计问题的场景。
我见过一个真实案例：A 系统用自增 ID，B 系统也用自增 ID，两边都有 id=10086 的记录，但完全不是同一个客户。合并时有人直接用 INSERT INTO ... SELECT 把数据拼到一起，主键冲突立刻报错；于是又改成去掉主键直接插入，结果冲突倒是没了，但同一客户在两套系统里各存一条，业务上无法区分。这是典型的“约束只合了一半”：只处理了主键冲突，没有设计新的业务唯一约束。
正确的做法是，合并之前先确定统一的业务唯一键，比如 (来源系统, 来源客户号)，并在这个组合上建唯一约束，再执行迁移。这个唯一约束能保证同一批客户不会被重复写入，后续即使有冲突，也能追溯到来源系统。
4.4 Python 自动拉表：应用层写约束会让数据库“裸奔”
热词里有“python 如何连接公司系统实现自动拉表”，这类脚本在数据部门非常普遍。每天定时连接业务系统，把数据拉下来写入数据仓库。但这里有个很大的坑：很多人在用 pandas 的 to_sql 时，根本没意识到自己正在绕过表的约束条件。
to_sql 有一个行为：如果目标表不存在，它会自动建表，但这个自动建表对字段类型、长度、约束的处理非常粗糙，经常把所有字符串都推断成 TEXT，数值推断成 DOUBLE，主键、唯一约束更是全丢。你以为是建了一张新表往里面灌数据，实际上建出来的只是一个没有约束的“存放容器”。
更隐蔽的是，即使目标表存在，导入时如果字段名和表结构对不上，pandas 会行为各异：有些版本报错，有些版本直接忽略不匹配列，导致目标表的某些约束字段被跳过，脏数据照样进去。
我的建议是，固定目标表结构，提前用 DDL 建好带完整约束的表，Python 脚本只负责按列名映射写入，绝不靠自动建表。写入前在脚本里做一次空值和重复检查，把应用层校验当成第一道哨兵，把数据库约束当成最后一道闸门，两条线都守住。
4.5 权限设计那几张表，约束放哪里
“权限设计一般有几张表”是另一个高频热词。标准的 RBAC 模型一般是五张核心表：用户表、角色表、权限表、用户角色关联表、角色权限关联表。
这个场景特别适合用外键和联合唯一约束。用户角色关联表里，user_id 和 role_id 分别设外键引用用户表和角色表，防止关联到不存在的记录；同时这两个字段要加联合唯一约束，保证同一用户不会重复绑定同一个角色。角色权限关联表同理。数据量不大，访问频率集中在登录和授权校验阶段，外键带来的性能开销完全可以忽略，而它换来的数据一致性价值极高。
我做过不少内部管理系统的数据库设计，坦白讲，只要数据量不突破单表百万级别、访问并发不高，大胆用外键没有问题。外键不是洪水猛兽，它只是不适合某些高并发场景，而不是在所有场景都该被禁用。
5. 树表、哈希表、大数据表这些特殊结构的约束设计思路
5.1 树表：parent_id 不是一切
树形结构在业务系统里极其常见，部门层级、商品分类、菜单权限，都是树。实现方式最基础的就是“邻接表”，一张表里用 parent_id 表示父节点。
热词里有“树表”，也有“邻接表 和 CSR 压缩存储 内存空间消耗是同一个量级吗”这样的问题。邻接表在关系型数据库里的优势是实现简单、查询直观，但它的约束设计比普通表更复杂：必须保证不能出现父子循环，不能出现一个节点同时有两个父节点，同一层级的兄弟节点不该重名。这些逻辑里，只有“不能出现一个节点同时有两个父节点”可以通过唯一约束（比如保证 parent_id 加唯一标识）来部分实现，其他逻辑比如环检测，靠数据库约束是做不到的，需要在应用层或定期任务里做校验。
我处理树表时通常这么做：parent_id 允许 NULL，表示根节点；name 字段在同一 parent_id 下加联合唯一约束，防止同层级重名；每次写入节点时在应用层做个简单的祖先链检查，防止把节点挂到自己后代下面。
5.2 哈希表和顺序表：约束的作用位点不同
热词里有“哈希表”“顺序表”“java 顺序表代码”。顺序表在数据结构课上指的是用连续存储空间保存元素，映射到数据库场景里，最接近的概念是聚簇索引表：主键顺序决定物理存储顺序。这时候主键约束的选择非常关键：自增主键追加写入，顺序友好；随机主键引发页分裂，顺序恶化。
哈希表对应的则是哈希索引存储结构，数据库里用 MEMORY 引擎或某些键值存储。它的主键直接决定了哈希桶的分布。唯一约束和主键约束在这种结构下不只是完整性问题，还直接关系到存储均衡性。设计时要把主键的散列特性考虑进去，避免热点键集中在一个桶里。
5.3 Hive、HBase 等大数据表：约束弱化，完整性靠分层
热词里还有“hive 表 ddl 操作”“hbase 表设计和数据操作”。大数据组件和传统关系型数据库在约束上的能力差异非常大。Hive 的 DDL 语法里支持 PRIMARY KEY、UNIQUE 这些关键字，看起来跟 MySQL 很像，但默认并不强制生效，更多是给元数据管理、查询优化器做个提示。HBase 更极致，唯一的“约束”就是行键唯一，其他完整性全靠写入端保证。
所以在大数据链路里，约束条件的思路要从“数据库拦”转向“分层校验”：源端抽取时做一次数据质量规则校验，数仓明细层在写入前做非空、唯一、枚举值检查，异常数据进入异常队列而不是直接污染主表。这是约束思想在数据工程场景下的延伸，理解了这个差异，你就不会对着 Hive 表写一大堆 CHECK 约束，然后发现它根本不干活。
5.4 一张可抄作业的约束设计检查清单
最后把我在多个项目里沉淀下来的约束设计检查点整理成清单，可以直接拿去对照自己的表：
- 明确主键类型，分布式场景优先选趋势递增的雪花 ID，不用业务高频变值
- 业务上必然有值的字段全部 NOT NULL，历史空值先回填再收紧
- 新增字段必须有默认值规划，老版本 MySQL 大表变更加重对锁评估
- 所有“业务上唯一”的字段或组合建立唯一约束，注意 NULL 语义和组合顺序
- 枚举、范围类字段加 CHECK 约束，确认数据库版本真支持
- 内部系统、低并发关联表的外键约束放心用，高并发分库表靠应用层补偿
- 约束命名统一，不用数据库自动生成的随机名
- 大表加约束按“先查重、再建索引、后挂约束”的顺序执行
- DDL 前先查依赖关系，评估父表子表连锁锁
- Python 等脚本导入数据时，禁止依赖自动建表，固定目标表结构
这套清单不是一次性的，每张新表上线前都应该过一遍。我自己带团队时有个习惯：评审表结构不看应用代码，只看数据库 DDL。应用代码可以重构，表结构一旦上线被业务依赖，约束的坑就是长期的运维成本。把约束条件在设计阶段就想清楚，远比事后花几倍精力去补数据、修报表要划算。
