SQL数据库created on与updated on字段设置规范及最佳实践咨询

做了这么多年后端开发和数据库设计，接触过的大小团队里，插入记录时给updated_on赋和created_on相同初始值的方案一，是绝大多数成熟技术团队的默认选择，所谓的语义误导问题在实际工程中几乎不会造成实质困扰，反而是方案二的可空字段设计，会在长期维护中制造更多不必要的成本。

为什么方案一是事实标准 #

• 非空约束的可靠性价值远高于语义洁癖：数据库层的NOT NULL约束是成本最低、最可靠的数据一致性保障，不需要上层所有业务代码、数据订正脚本、同步任务都额外处理updated_on为null的分支。不管是做时间范围筛选、增量同步、排序，非空的时间字段可以直接写查询逻辑，不用嵌套COALESCE(updated_on, created_on)这类兼容写法，也不会出现漏数的问题。
• 所谓语义误导本质是定义没对齐：updated_on的实际语义从来不是“记录创建后最后一次修改的时间”，而是记录最后一次被写入（包含插入操作本身）的时间。只要团队内部统一这个定义，根本不会产生误解——插入本身就是记录生命周期的第一次写入，对应时间戳完全符合逻辑。要判断记录有没有被更新过，直接写updated_on = created_on即可，判断逻辑零额外成本，根本不需要复杂校验。
• 全行业主流工具链默认就用这套逻辑：不管是Rails Active Record、Django ORM、MyBatis-Plus、Hibernate还是其他主流持久层框架，自带的审计字段自动填充逻辑，全都是插入时同时给两个时间字段赋值，更新时只刷新updated_on，这已经是不需要额外写文档约定的行业共识。我见过不少团队一开始图语义“纯粹”选了方案二，跑了不到半年因为到处兼容null值写得痛苦，最后全表刷数据把null补成created_on的值、改回非空约束，来回折腾的成本非常高。

方案二的隐性成本 #

除了没法加非空约束之外，方案二的实际问题比想象中多：

• 可空时间字段会给所有下游埋隐性坑：做BI报表、数据导出、离线数仓同步的时候，只要有一个使用方忘了处理null值，就会出现时间解析失败、统计范围漏数的问题，这类bug藏得深，排查成本很高。
• 所谓“null直接标识未更新”的优势非常鸡肋：实际业务里几乎没有场景需要单独筛选“从未更新过的记录”，就算有这个需求，判断updated_on = created_on和判断updated_on IS NULL的写法复杂度没有任何区别，前者反而不需要兼容空值分支。

可选补充方案 #

如果你的业务确实有强需求，需要明确区分“创建后从未修改”的记录状态，不建议牺牲updated_on的非空属性：

• 可以额外加一个布尔字段is_updated，默认值为0，记录触发更新逻辑时自动置为1，判断逻辑简单直接，也不会破坏时间字段的一致性。
• 如果需要更细粒度的变更追溯能力，不要在主表的时间字段上抠语义，单独建审计日志表，记录每次更新的操作人、变更字段、新旧值即可，灵活度高很多。
• 不管选哪种设计，绝对不要让业务代码手动给这两个字段赋值，最好在数据库层用触发器、或者在持久层做全局自动填充，从根源上避免漏赋值、赋错值导致的数据不一致。

内容的提问来源于stack exchange，提问作者user2340939