为什么数据库设计时普遍不倾向于构建一个庞大的单一表结构？

在数据库设计时很多人会想：为什么不能直接用一个大表来存放所有数据？这其实是个误区，大表比如往往隐藏着性能瓶颈，还有维护成本，再有数据冗余和安全风险。

再看痛点一，查询效率直线下降

当业务增长到百万级甚至千万级记录时单一大表的扫描成本会显著上升。索引也会变得庞大且低效，导致每一次查询都要走更多磁盘 I/O。

典型场景

电商网站的订单表如果把使用者信息、商品信息、支付状态全部塞进同一张表。一旦订单量激增，查询“今天的支付成功订单”就需要扫描数十亿行。

说到痛点二。维护与升级成本高

任何一次结构变更都会触发全表重建，导致服务中断。怎么说呢，多业务模块共用同一张表。更容易因为字段冲突或约束不一致而让整个程序失效。

典型案例

某金融程序在对单个大表新增“交易类型”字段时需要停机 12 小时完成 ALTER TABLE，影响业务连续性。

从痛点三来看。数据冗余与一致性难以保证

将不同实体的数据混合在一起，会出现同一属性多次存储。更新时必须同步修改多行，错误率暴涨。

常见问题

使用者信息与订单信息放在同一张“交易”表中，当使用者改名后需要遍历整张表更新所有相关记录；若操作不彻底，则造成不一致。

至于痛点四。安全与权限管理困难

所有数据集中在一个地方，一旦出现泄露风险，将同时暴露所有敏感信息。细粒度权限控制难以实现，话说回来，

解决思路

把敏感字段拆分到专门的“安全”表。并通过外键关联，对非敏感业务使用公共表即可。

说到常用方法。垂直切割与分区策略

垂直切割

• 将相同业务领域的数据拆成多个小表，例如使用者基础信息、使用者偏好、订单详情等。