1、逻辑设计的规范化
所谓逻辑设计的规范化就是使得数据库的逻辑更加合理。说白了就是我们平时所说的三范式。具体内容可以参考笔者之前的文章。
现在总结如下：
第一范式：原子不可再分
第二范式：只能依赖主键
第三范式：不能依赖其他
其实三范式说到底就是方便查找、防止冗余，比如第一范式中原子性，就是把信息单元化，方便用户的查询，试想如果数据不容易查询还要数据库干什么？第二范式和第三范式是从不同的方面来描述其他非主键的字段，第二和第三范式保证了数据库的不冗余。这使得数据库在新增和更新的时候效率大大提高。
数据库范式中一共有五个，这里就只介绍三个。因为在实际项目中会发现真正能遵守三范式的项目很少，有很多项目为了提高查找效率不得不让数据库存在冗余，下面将详细介绍。
2、合理的冗余
任何事物都有两面性，三范式也不例外，达到一个平衡就好。就像前面文章中提到的系统性能的瓶颈都是相对的，原则就一条：谁影响整个系统的性能就解决谁。上面已经提到了三范式在一定程度上提高了数据库的查询效率，同时减少不必要的冗余，但是如果数据量大需要大量联合查询的时候那么影响查询效率的就是三范式了。
例如User表中的name字段，如果按照三范式的要求name字段就应该放在User表中其他地方只存User的ID。但是如果在另一张表订单表（Order）中需要User表的name字段这时就不得不将两个表进行关联，在数据量小的时候采用联合查询的方式是没有问题的。一旦数据量超过百万千万甚至更大的时候联合查询对性能的影响就显现出来了，这时完全就可以将name字段冗余的放在Order表中。需要注意的时候再在户修改姓名（一般很少有人修改）的时候需要修改两个地方Order表和User表，适当的冗余提高了效率。
“放弃”三范式导致一定的数据冗余，减少了联合查询，但最终目的还是提高效率。
3、索引的设计
在设计阶段，可以根据功能和性能的需求进行初步的索引设计，这里需要根据预计的数据量和查询来设计索引，可能与将来实际使用的时候会有所区别。
关于索引的选择，应改主意：
A、根据数据量决定哪些表需要增加索引，数据量小的可以只有主键。
B、根据使用频率决定哪些字段需要建立索引，选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。
C、把经常一起出现的字段组合在一起，组成组合索引，组合索引的字段顺序与主键一样，也需要把最常用的字段放在前面，把重复率低的字段放在前面。
D、一个表不要加太多索引，因为索引影响插入和更新的速度
索引不单单是需要在设计数据库时候需要考虑，在系统维护解决性能瓶颈的时候同样是一把屡试不爽的绝招。关于索引在系统后期维护中的优化后面文章将详细叙述。
总结：
系统性能的提高是为了提高系统的执行速度和准确的处理数据。往往系统性能的调优是等到遇到系统瓶颈的时候再去做，这无可厚非谁也不是先知，但是我们可以根据自己或者他人已有的经验把调优的的过程放在开始设计的阶段。在得到需求的时候要考虑系统将会遇到哪些瓶颈，（当然不要过分设计，过分设计的后果就是增大系统的开销）然后根据预估的瓶颈进行有效的预防（比如合理的索引、高效的主键设计等等）。总之性能的优化绝不是遇到瓶颈才开始做的，从设计阶段就考虑性能问题才是明智之举。