1. 单表数据存储不要过大

• 主流建议
  • 保守建议。100万以内保持最佳性能
  • 其他。不超过2000万
• 理论依据。
  • B+树层级可能变多。从3增加到4。导致索引查询路径边长，增加IO开销
• 优化
  • 加索引。对高频查询字段增加索引。避免全表扫描
  • 低频历史数据通过分区表或归档隔离。
  • 足够的内存 + 高速磁盘
  • 分库分表
    • 当查询延迟显著增加
    • 高并发导致锁竞争激烈（热点更新）
    • 业务拓展。预计数据量快速增长。预先规划可拓展架构

2. 单实例中表数目不要过多

• 应小于500.
  • 过多的表增加元数据管理开销。影响查询性能
  • 增加了维护成本。表数量过多提升了备份、监控、DDL操作的复杂度
  • 业务解耦。通过分库分表垂直拆分控制单实例表数量。符合高内聚低耦合的设计。

3. 单表列数目不要过多

• 存储效率。
  • 单表列数过多会导致单条数据体积增大，降低内存缓存效率。
• 查询性能。
  • 增加了I/O压力索引维护成本高。
• 拓展性。
  • 列超30通过垂直拆分避免业务调整使表结构臃肿

实际应用中的灵活性

例外场景

• 若确实需要宽表。在数据仓库中可以接受，但需配合列式存储引擎（如ClickHouse）
• 若有特殊需求。则控制主表的列数。保留高频的访问字段。低频字段通过关联表存储。

替代方案

• 可以使用json存储数据，减少列数，但要考虑查询效率
• 按周期归档历史数据。控制单表数据量