1. 为什么数据库字段默认值设为NULL是个糟糕主意
我第一次在线上系统遇到NULL值引发的生产事故，是在一个用户积分结算的场景。凌晨3点被报警电话吵醒，发现积分批量结算任务卡死，排查两小时才发现是某个允许NULL的积分变动字段在汇总计算时引发了类型转换异常。这个惨痛教训让我彻底重新审视了数据库设计中关于NULL值的使用规范。
NULL在数据库领域中是个特殊存在，它表示"未知"或"不存在"的值，与空字符串、0等有本质区别。问题在于，NULL的传播特性会像病毒一样影响所有与之交互的操作：
- 在比较运算中：
NULL = NULL的结果不是TRUE而是NULL - 在逻辑运算中：
NULL AND TRUE的结果是NULL而非TRUE - 在聚合函数中：
COUNT(字段)会忽略NULL值，但SUM(NULL+1)却返回NULL
更危险的是，这种特性会导致业务逻辑出现二义性。比如用户未设置手机号时，用NULL表示和用空字符串表示，在业务语义上是完全不同的。前者意味着"尚未获取"，后者可能表示"用户明确没有"。
2. NULL值引发的四大典型问题场景
2.1 查询条件中的意外行为
假设有用户表包含last_login_time字段，部分记录该字段为NULL。当执行以下查询时：
SELECT * FROM users WHERE last_login_time < '2023-01-01'NULL值的记录不会出现在结果中，因为它们不满足任何比较条件。这经常导致报表数据缺失，需要额外增加OR field IS NULL条件。
2.2 聚合计算时的异常中断
考虑订单表中有可NULL的discount_amount字段，计算总优惠金额时：
SELECT SUM(discount_amount) FROM orders如果任何一条记录的该字段为NULL，整个SUM结果就会变成NULL。必须改用：
SELECT SUM(COALESCE(discount_amount, 0)) FROM orders2.3 唯一约束的漏洞
在字段上设置UNIQUE约束时，NULL值会被特殊对待。多个NULL值不违反唯一性约束，这可能导致业务上的重复数据。例如用户表的备用邮箱字段：
ALTER TABLE users ADD CONSTRAINT uni_backup_email UNIQUE (backup_email)仍然可以插入无数条backup_email为NULL的记录。
2.4 索引失效风险
B树索引不会存储NULL值，因此像WHERE field IS NULL这样的条件无法使用索引。在大型表中，这会导致全表扫描。
3. 更优的字段默认值策略
3.1 字符串类型处理
替代方案：
- 空字符串
''：表示"有值但为空" - 特定占位符：如
'N/A'表示不适用 - 业务默认值：如
'unknown'表示未知
-- 创建表示例 CREATE TABLE users ( phone_number VARCHAR(20) NOT NULL DEFAULT '', backup_email VARCHAR(100) NOT NULL DEFAULT 'unset' );3.2 数值类型处理
- 整型：用0表示未设置
- 浮点型：用0.0或业务默认值（如-1表示异常状态）
CREATE TABLE products ( discount_rate DECIMAL(5,2) NOT NULL DEFAULT 0.00, stock_quantity INT NOT NULL DEFAULT 0 );3.3 时间类型处理
- 用'1970-01-01'等特殊日期表示未设置
- 或用'0000-00-00'（MySQL支持）
- 业务默认值如'9999-12-31'表示永久有效
CREATE TABLE contracts ( expire_date DATE NOT NULL DEFAULT '9999-12-31', start_date DATE NOT NULL DEFAULT CURRENT_DATE );4. 处理遗留系统中的NULL字段
对于已有系统，可以通过分阶段改造安全地消除NULL：
4.1 迁移方案
先修改字段定义不允许NULL，但仍保持旧默认值：
ALTER TABLE orders MODIFY COLUMN coupon_code VARCHAR(20) NOT NULL DEFAULT '';分批更新现有NULL值：
UPDATE orders SET coupon_code = '' WHERE coupon_code IS NULL LIMIT 1000;最后移除默认值（如需要）：
ALTER TABLE orders ALTER COLUMN coupon_code DROP DEFAULT;
4.2 兼容性处理
在应用层增加NULL值转换逻辑，例如使用ORM的TypeHandler：
// MyBatis类型处理器示例 public class EmptyStringToNullHandler implements TypeHandler<String> { @Override public void setParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) { ps.setString(i, StringUtils.isEmpty(parameter) ? null : parameter); } //...其他方法实现 }5. 特殊场景下的NULL值合理使用
虽然大多数情况下应避免NULL，但某些场景下NULL确实是正确选择：
5.1 稀疏数据存储
当字段在大多数记录中确实没有值时，使用NULL可以节省存储空间。例如电商系统中的商品定制选项字段。
5.2 三值逻辑需求
当业务确实需要区分"未知"、"无"和"有值"三种状态时，如医疗系统中的患者过敏史记录。
5.3 外键关联关系
可选的外键关联应该允许NULL，表示无关联。例如订单表中的推荐人ID字段。
CREATE TABLE orders ( referrer_id INT NULL, FOREIGN KEY (referrer_id) REFERENCES users(id) );6. 各数据库对NULL处理的差异
不同数据库对NULL的实现有细微差别，需要特别注意：
| 行为 | MySQL | PostgreSQL | Oracle | SQL Server |
|---|---|---|---|---|
| NULL排序位置 | 最先 | 最后 | 最后 | 最先 |
| 空字符串=NULL | 否 | 否 | 是 | 否 |
| 唯一约束允许多NULL | 是 | 是 | 是 | 是 |
| COUNT(NULL) | 0 | 0 | 0 | 0 |
在编写跨数据库应用时，建议使用COALESCE或ISNULL函数统一处理：
-- 跨数据库兼容写法 SELECT COALESCE(field, fallback_value) FROM table -- 或 SELECT ISNULL(field, fallback_value) FROM table -- SQL Server语法7. 实战中的经验教训
在我参与过的一个电商平台项目中，曾因NULL值处理不当导致重大损失：
优惠券计算错误：由于discount_amount字段允许NULL，部分订单的优惠金额被错误计算为NULL，导致实际收款金额大于应收款。直到财务对账时才被发现，涉及订单金额达23万元。
用户画像偏差：用户兴趣标签字段使用NULL表示未设置，但统计时错误过滤了这些记录，导致推荐系统覆盖度不足，CTR下降37%。
库存预警失效：库存预占字段NULL值与0值混用，使得库存预警SQL漏报，最终引发超卖事故。
这些问题的解决方案是建立统一的字段规范：
关键规范：所有业务表字段必须显式定义NOT NULL，并选择合适的默认值。只有经架构师评审的特殊场景才允许使用NULL。
在最近的数据仓库项目中，我们通过以下检查脚本确保规范落地：
-- 检查所有允许NULL的字段 SELECT table_name, column_name, is_nullable, column_default FROM information_schema.columns WHERE table_schema = 'public' AND is_nullable = 'YES' AND column_name NOT IN ('approved_exception_columns');经过半年的规范治理，系统异常事件减少了68%，BI报表准确度提升至99.9%。这让我深刻认识到：良好的NULL值策略是数据质量的基石。
