数据库对象设计

• 在数据库设计和优化阶段，常常会碰到一些问题
  • 表设计时是否都应该按照第3范式设计？
  • 表中的字段类型应该设置为什么？
  • 表中的字段长度应该设置成多少？
  • 后续如果表数据嚣大了，当前设计是否能满足需求？
  • 后续查询慢了， 如何建立合适的索引？
  • ……
• 数据库对象的设计优劣直接决定了SQL语句执行性能的上限，如果设计不当会导致很多的性能问题。

字段类型优化

• 字段类型尽量短
  • 在满足业务需求的前提下，尽量选择短一些的字段长度。对于GaussDB(for MySQL)而言，数据库中的表越小，表的查询效率越高；
• 字段类型尽量高效
  • 高效的字段类型能够使得SQL语句在查询时更快地获取到结果；
  • 字段类型的效率排名：整型>浮点型>字符串
• 字段类型的长度需要设计冗余
  • 在满足当前业务需求的情况下，适当设计字段长度冗余，避免后期因业务变更导致需要修改表结构操作；
• 效率一般而言：整型>浮点型>字符串。

表的拆分

• 影响表的查询效率的一个比较大的因素是数据量，在业务早期因数据量较小，查询耗时不大；当业务数据量增多时(超过百万级)，会导致同一条SQL语句因数据量的增大而耗时增加；
• 为了避免因数据量的增多，而导致SQL语句执行缓慢，在表的设计初期会考虑表的拆分操作。一般常见的表拆分分为两种
  • 水平表拆分
    • 分区(Partition)：RANGE、LIST、HASH、KEY等；
  • 垂直表拆分
    • 依据业务逻辑，将一张表中常用列和非常用列拆分出来，使得单条数据行变小，提高查询效率；但查询所有数据需要JOIN操作；
• 分区的性能提升效果不一定就好，OLTP表通常不可能会获取一张大表10%的数据，大部分都是通过索引返回几条记录即可。而根据B+树索引的原理可知，对于一张大表，一般的B+树需要2~3次的磁盘IO。因此B+树可以很好地完成操作，不需要分区的帮助，并且设计不好的分区会带来严重的性能问题。如果分区后B+树的高度是一样的，那没有必要分区。
• 还有基于数据库的拆分：分库操作。

反范式设计

• 数据库表的范式设计能使得表之间的结构清晰，表之间的关系复杂，表之间的JOIN操作频繁，而JOIN操作属于性能较低的操作，会影响查询性能。 因此对于一些表JOIN查询较多的业务场景，需要根据实际情况采用反范式的方式来对数据库表进行设计。
• 增加冗余列
  • 在多个表中具有相同的列
• 增加派生列
  • 增加的列来自其他表数据或有其他表的数据计算生成，避免使用集函数；
• 重新生表
  • 用户经常需要查看多个表的JOIN结果，把这些表重新组成—个表；
• 分割表
  • 表的拆分操作；

中间表设计

• 针对某些特定数据量比较大的表，用户需要先筛选然后做分析操作时， 中间表的设计会使得查询效率变高。
• 中间表需要和源表结构完全相同。
• 一般先将需要统计的表数据转移到中间表中，然后在中间表上做统计或查询。
• 中间表的设计有如下优点
  • 与源表 “隔离”，在中间表上做统计操作不会对源表产生影响；
  • 中间表可以灵活添加索引或新增临时的新字段，从而提高查询效率和辅助统计查询。