良好的逻辑设计和物理设计是高性能的基石，在进行设计的时候应该根据系统将要执行的查询语句来设计表，这往往需要权衡各种因素，那么这些因素有哪些呢？我们应该重点关注什么呢？这常常苦恼着我们，良好的设计原则是普遍适用的，下面文章将介绍一些常规的思考维度提供参考
- 尽量避免过度设计，例如会导致极其复杂查询的表设计，或者有很多列的表设计（很多的意思是介于有点多和非常多之间）
- 适用小而简单的合适数据类型，除非真实数据模型中有确切的需要，否则应该尽可能地避免使用NULL值（详细见 为什么Mysql 尽量使用NULL值？）。
- 尽量适用相同的数据类型存储相似或者相关的值，尤其是要在关联条件中适用的列(不然会涉及到类型转换，消耗性能)
- 注意可变长字符串，其在临时表和排序时可能导致悲观的按最大长度分配内存。
- 尽量适用整型定义标识列。
- 避免适用Mysql 已经遗弃的特性，例如指定浮点数的精度，或者整数的显示宽度。
- 小心适用ENUM和SET。虽然他们用起来比较方便，但是不要滥用，否则有时候会变成陷阱。最好避免适用BIT。
- 范式是好的，但是反范式(大多数情况下意味着重复数据)有时也是必须的，并且带来好处（查询获取数据等更优秀，但是同样带来维护成本复杂度成本等的提升）。
附加：范式和反范式的优缺点？如果考量？
范式是什么？范式是数据库设计的一些规则，反范式就是不遵循那些规则。这里像数据库范式中的字段冗余就是反范式，也是我们工作中常用的（详细的可以查找相关的文件进行了解）。
范式化好处
- 范式化的更新操作通常比反范式化更快
- 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
- 范式化的表通常更小，可以更好地放在内存里，所以执行操作更快。
- 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。
范式坏处
- 范式化设计查询常常需要关联表，在一些复杂的查询中，关联的代价不仅昂贵，也可能使一些索引失效。
反范式好处
- 反范式所有数据都在一张表，可以很好地避免关联。
- 不需要关联表，则对大部分查询最差的情况—–即使表没有使用索引—是全表扫描。当数据比内存大时这可能比关联要快的多。因为这样避免了随机I/O(全表扫描基本上是顺序I/O，但也不是100%的，跟引擎的实现有关)。
- 单独的表也能适用更有效的索引策略。
- 能更有效的执行这个查询
反范式坏处
- 表中冗余了数据，那么就需要更多的空间，典型的空间换时间策略
- 多份重复数据，那么在进行数据一致性维护上需要更多的操作，成本提升
因此在设计表的时候，注意空间和时间 你更需要哪一个。