组合唯一索引新增含大量Null的日期列会对索引产生什么影响

1. 唯一性约束逻辑变化 #

• 绝大多数主流关系型数据库（MySQL、PostgreSQL等）的唯一索引规则为：NULL值不被视为相等的值。也就是说两条记录的id、name完全相同时，只要date列都是NULL，不会触发唯一约束冲突，这可能和你预期的「id+name+date全局唯一」的业务逻辑不符。
• 原有两列唯一索引要求任意两条记录的id、name不能同时相同，调整为三列后，只要date值不同（或者其中至少一个date为NULL），就可以存在多条id和name相同的记录，相当于放松了原有的约束强度，需要优先确认该逻辑是否符合业务预期。

2. 索引存储与性能影响 #

• 索引体积会明显上升：新增的date列哪怕存储NULL值也会占用固定占位空间，叠加大量NULL值的存在，该索引的整体存储空间会比原有两列索引高30%~60%不等，具体数值取决于使用的数据库存储引擎。
• 查询性能变化：如果查询筛选条件经常携带id+name+date三个条件，查询效率会和原索引持平甚至更高；如果查询只有id+name两个前缀条件，查询性能不会有明显下降，不过索引扫描的IO开销会因为索引体积变大略有上升。
• 写入性能下降：插入、更新数据时需要多校验一列，同时写入索引的内容变多，高并发写入场景下吞吐量会有5%~15%左右的下降，表数据量越大下降幅度越明显。

3. 潜在业务风险 #

• 如果业务逻辑实际要求的是「id+name+非NULL的date唯一」，现有大量NULL的date会导致重复数据可以被正常写入，完全不符合业务预期。这种情况建议先给date列设置默认值（比如'1970-01-01'），把现有NULL值全部替换为默认值之后再创建唯一索引，才能满足约束要求。
• 替换索引的过程中，如果先删除旧的两列唯一索引再创建三列索引，期间会存在没有唯一约束的时间窗口，高并发场景下可能写入脏数据，建议在业务低峰期操作，或者先创建三列唯一索引再删除旧索引，避免约束临时失效。

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