写代码这些年，见过不少新手在数据库设计时对default这个关键字的态度，要么完全无视，要么胡乱用。说实话，default这词儿看着简单，不就是“默认值”嘛，可真要用对了地方，里面门道不少。今天咱就掰开揉碎了聊聊，数据库里这个default到底该怎么玩，玩不好会出什么幺蛾子。
先说说default最基础也最常用的场景：给新插入的行填充值。比如用户表里有个“注册来源”字段，这样insert语句里不写这个字段，数据库自动给填上'web'。省事是真省事，代码里少写一堆判断逻辑。但这里有个坑，很多人没意识到：default只在insert语句里“没提到”这个字段时才生效。你要是写了，那source就是null，不是'web'。这俩的区别，新手特别容易搞混，以为是数据库“智能”帮你填，其实它没那么聪明，它只认“你没写”还是“你写了null”。
再说说default和not null的搭配。这俩经常一起出现，但逻辑上要捋清楚。一个字段设了，意思是“你不能给我null，但你不写我就给你0”。反过来，如果只设没设not null，那插入时显式给null是允许的，结果就是null。很多人以为设了default就等于自动拒绝null，这是误解。我见过一个生产事故，报表统计时sum函数遇到null直接返回null，导致整张报表挂了，查了半天发现就是某个字段只设了default没设not null，脏数据从接口传了个null进来。所以设计表结构时，default和not null得一起考虑，别指望default能帮你兜住null。
再往深了说，default还有个容易被忽略的用法：跟时间戳配合。比如，这个在MySQL里很常见，插入时自动记录当前时间。但注意，这个只在插入时生效，更新时不会变。你要是想“插入时记时间，更新时也自动改时间”，那得用，这跟default是两码事。很多人把这两个混为一谈，结果做审计日志时发现更新时间不对，查半天才发现是default的锅。还有，不同数据库对currenttimestamp的支持不一样，Oracle里得用sysdate，SQL Server里是getdate()，PostgreSQL倒是跟MySQL一样。换数据库时，default这块儿最容易踩坑。
说到换数据库，default还有一个跟迁移相关的坑：字符集和排序规则。比如你设了个，但表本身是latin1字符集，那插入时可能直接报错或者存成乱码。这个问题在团队协作时特别常见，A同事在本地用utf8设了中文默认值，推到生产环境是latin1，跑迁移脚本直接挂。所以default值本身也得跟着表字符集走，设计时要统一规划，别只顾着写default，忘了看表结构。
还有一种情况，default跟业务逻辑耦合太紧，反而成了包袱。比如状态字段，你一开始设表示“待审核”，后来业务改了，新增了个“草稿”状态，你想把默认值改成。这时候你会发现，改default本身很简单，一执行就完事。但坑在于，之前已经插入的数据，那些用default 0填的旧行，不会自动变成-1。你得另外写update语句去批量改。这还不算最麻烦的，最麻烦的是那些在应用层已经写了“不传就按默认来”的逻辑，你数据库改了default，应用层没同步改，新老数据就打架了。所以default这东西，改起来容易，但牵一发动全身。
再聊一个进阶用法，default跟序列或自增id配合。比如MySQL里，这个其实是隐式的default，你插入时不写id，数据库自动生成。但如果你显式写了id，那autoincrement就不生效了。有些人喜欢在insert时故意传id，比如从旧库导数据，这时候得小心，因为一旦传了id，后续的autoincrement计数器可能不会自动更新，导致下次插入时主键冲突。这个跟default的语义是一样的：你写了，它就不管了。所以数据迁移时，导完数据得手动重置auto_increment的起始值，不然早晚出事儿。
还有一点，default在ORM框架里的表现也值得说说。比如用MyBatis或Hibernate，插入时如果实体类里某个字段是null，框架可能会把null也拼进insert语句里，导致default不生效。你得在实体类上设默认值，或者配置ORM的insert策略，让它忽略null字段。这个问题特别隐蔽，因为本地测试时数据库可能没有严格的not null约束，生产环境一收紧就炸。我见过一个案例，开发环境一切正常，上线后新注册的用户全部没有
