最近研究索引数据库，稍微总结一下，以后继续补充：
1、逻辑计划的规范化
所谓逻辑计划的规范化就是使得数据库的逻辑更加合理。说白了就是我们平常所说的三范式。具体内容可以参考笔者之前的文章。
当初总结如下：
第一范式：原子弗成再分
第二范式：只能依赖主键
第三范式：不能依赖其他
其实三范式说到底就是便利查找、防止冗余，比如第一范式中原子性，就是把信息单元化，便利用户的查询，试想如果数据不容易查询还要数据库干什么？第二范式和第三范式是从不同的方面来描述其他非主键的字段，第二和第三范式保障了数据库的不冗余。这使得数据库在新增和更新的时候效率大大进步。
数据库范式中一共有五个，这里就只分析三个。因为在现实项目中会发明真正能遵守三范式的项目很少，有很多项目为了进步查找效率不得不让数据库存在冗余，上面将具体分析。
2、合理的冗余
任何事物都有两面性，三范式也不例外，到达一个平衡就好。就像前面文章中提到的系统性能的瓶颈都是绝对的，准则就一条：谁影响整个系统的性能就解决谁。上面已提到了三范式在必定程度上进步了数据库的查询效率，同时减少不必要的冗余，但是如果数据量大需要大批联合查询的时候那么影响查询效率的就是三范式了。
例如User表中的name字段，如果按照三范式的要求name字段就应该放在User表中其他地方只存User的ID。但是如果在另外一张表订单表（Order）中需要User表的name字段这时就不得不将两个表进行关联，在数据量小的时候采取联合查询的方式是没有问题的。一旦数据量超过百万千万甚至更大的时候联合查询对性能的影响就显现出来了，这时完全就能够将name字段冗余的放在Order表中。需要注意的时候再在户修改姓名（一般很少有人修改）的时候需要修改两个地方Order表和User表，适当的冗余进步了效率。
“废弃”三范式致使必定的数据冗余，减少了联合查询，但终究目的还是进步效率。
3、索引的计划
在计划阶段，可以根据功能和性能的需求进行初步的索引计划，这里需要根据预计的数据量和查询来计划索引，可能与将来现实使用的时候会有所区别。
关于索引的选择，应改主意：
A、根据数据量决定哪些表需要增长索引，数据量小的可以只有主键。
B、根据使用频率决定哪些字段需要建立索引，选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。
C、把经常一起涌现的字段组合在一起，组成组合索引，组合索引的字段顺序与主键一样，也需要把最常用的字段放在前面，把重复率低的字段放在前面。
D、一个表不要加太多索引，因为索引影响插入和更新的速度
索引不单单是需要在计划数据库时候需要斟酌，在系统维护解决性能瓶颈的时候同样是一把屡试不爽的绝招。关于索引在系统后期维护中的优化前面文章将具体叙说。
总结：
系统性能的进步是为了进步系统的执行速度和准确的处理数据。往往系统性能的调优是等到碰到系统瓶颈的时候再去做，这无可非议谁也不是先知，但是我们可以根据自己或者他人已有的经验把调优的的进程放在开始计划的阶段。在失掉需求的时候要斟酌系统将会碰到哪些瓶颈，（当然不要过分计划，过分计划的后果就是增大系统的开销）然后根据预估的瓶颈进行有效的预防（比如合理的索引、高效的主键计划等等）。总之性能的优化绝不是碰到瓶颈才开始做的，从计划阶段就斟酌性能问题才是明智之举。
文章结束给大家分享下程序员的一些笑话语录：
程序员打油诗
写字楼里写字间，写字间里程序员;
程序人员写程序，又拿程序换酒钱。
酒醒只在网上坐，酒醉还来网下眠;
酒醉酒醒日复日，网上网下年复年。
但愿老死电脑间，不愿鞠躬老板前;
奔驰宝马贵者趣，公交自行程序员。
别人笑我忒疯癫，我笑自己命太贱;
不见满街漂亮妹，哪个归得程序员。
---------------------------------
原创文章 By
索引和数据库
---------------------------------