良好的逻辑设计和物理设计是高性能的基石，在进行设计的时候应该根据系统将要执行的查询语句来设计表，这往往需要权衡各种因素，那么这些因素有哪些呢？我们应该重点关注什么呢？这常常苦恼着我们，良好的设计原则是普遍适用的，下面文章将介绍一些常规的思考维度提供参考

  • 尽量避免过度设计，例如会导致极其复杂查询的表设计，或者有很多列的表设计（很多的意思是介于有点多和非常多之间）
  • 适用小而简单的合适数据类型，除非真实数据模型中有确切的需要，否则应该尽可能地避免使用NULL值（详细见 为什么Mysql 尽量使用NULL值？）。
  • 尽量适用相同的数据类型存储相似或者相关的值，尤其是要在关联条件中适用的列(不然会涉及到类型转换，消耗性能)
  • 注意可变长字符串，其在临时表和排序时可能导致悲观的按最大长度分配内存。
  • 尽量适用整型定义标识列。
  • 避免适用Mysql 已经遗弃的特性，例如指定浮点数的精度，或者整数的显示宽度。
  • 小心适用ENUM和SET。虽然他们用起来比较方便，但是不要滥用，否则有时候会变成陷阱。最好避免适用BIT。
  • 范式是好的，但是反范式(大多数情况下意味着重复数据)有时也是必须的，并且带来好处（查询获取数据等更优秀，但是同样带来维护成本复杂度成本等的提升）。

附加：范式和反范式的优缺点？如果考量？

范式是什么？范式是数据库设计的一些规则，反范式就是不遵循那些规则。这里像数据库范式中的字段冗余就是反范式，也是我们工作中常用的（详细的可以查找相关的文件进行了解）。

范式化好处

  • 范式化的更新操作通常比反范式化更快
  • 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
  • 范式化的表通常更小，可以更好地放在内存里，所以执行操作更快。
  • 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。

范式坏处

  • 范式化设计查询常常需要关联表，在一些复杂的查询中，关联的代价不仅昂贵，也可能使一些索引失效。

反范式好处

  • 反范式所有数据都在一张表，可以很好地避免关联。
  • 不需要关联表，则对大部分查询最差的情况—–即使表没有使用索引—是全表扫描。当数据比内存大时这可能比关联要快的多。因为这样避免了随机I/O(全表扫描基本上是顺序I/O，但也不是100%的，跟引擎的实现有关)。
  • 单独的表也能适用更有效的索引策略。
  • 能更有效的执行这个查询

反范式坏处

  • 表中冗余了数据，那么就需要更多的空间，典型的空间换时间策略
  • 多份重复数据，那么在进行数据一致性维护上需要更多的操作，成本提升

因此在设计表的时候，注意空间和时间 你更需要哪一个。