mysql控制单表数据存储及单实例表创建

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

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

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

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

3. 单表列数目不要过多

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

实际应用中的灵活性

例外场景

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

替代方案

• 可以使用json存储数据，减少列数，但要考虑查询服从
  
• 按周期归档汗青数据。控制单表数据量
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。