前言
数据库是程序的仓库。也是程序中最脆弱的一部分，由于它的脆弱性和重要性。所以须要专门进行管理和优化。在现在的网络化的时代更加须要数据库的灵活和快捷，一个高效的数据库可以使程序执行效率更快，提高程序的执行效率。但往往对数据库的设计达不到我们想要的效果，所以数据库的优化显得尤为重要。该系列文章正是考虑大数据量的当今怎样才干让数据库的设计更加灵活，数据检索、操作更加高效展开的讨论。当中涉及到的优化方法是在笔者长期的开发经验以及其他有关数据库优化的文章基础上进行总结的，假设有异议还请指出。
数据库的优化分为非常多种，由于SQL对象较多，在对数据库进行优化时须要考虑它们对性能的影响，并且优化的程度没有最优，仅仅有更优，这些优化方案还要依据使用环境的不同进行取舍，不一定都能保持高效率，你比方说开发的系统本身数据量不大，并且又是C/S系统这时候就能够不用考虑那么多的优化问题，把重心能够放到程序的友好程度、稳定性、健壮性、灵活性上。首先从设计阶段開始考虑数据库的优化，大致的内容进行了整理汇总图，例如以下。
设计阶段的优化须要有相当多的经验才干够，未雨绸缪才是最高境地。所以要预见性的避免非常多问题，在设计时就让数据库查询改动效率非常高。
一、规范化
1、数据库的规范化
在创建数据库的时候首先要尽量符合三范式的要求，由于三范式是一个指导性的标准，在复杂的表关系中能够考虑使用范式来达到表之间关系的平衡。在设计表结构时三范式已经非常充足了。另外能够考虑添加冗余字段，有时候能够添加检索的效率。
一范式：每一个字段表示的实体属性唯一，最基础的设计规范，一般的字段都会符合；
二范式：消除部分依赖；
三范式：消除传递依赖。
假设完全然全依照三范式设计表结构的话，有时候会非常繁琐。对于简单的实体转换成表结构的时候能够不採用三范式，由于范式会产生较少的列和很多其它的表。这样更不利于检索改动，所以要依据实际情况而定。
2、非规范化
合理的冗余
在设计表结构时能够适当的考虑适当的冗余。好的冗余能大大提高表的检索效率。
在设计时经常使用的计算字段(如总计、最大值等)能够考虑存储到数据库实体中，这时能够考虑加入触发器来保持数据的一致性（不建议这样做。触发器有非常多不确定性）。另外假设设计的表关系产生了很多表可是在检索时须要合并关系，这时能够考虑在数据库实体中加入反复列。
表切割
表的冗余字段能够提高表的效率，相同针对大数据量处理的时候须要考虑对表进行垂直和水平的切割。
（1）垂直切割：把一个实体表切割成两个表。这样把频繁訪问的数据同较少被訪问的数据切割。在进行切割前要求每张表复制首要keyword。这样产生的表有利于并行处理。将产生列数较少的表。
（2）水平切割：把一个实体表分成多组（把全部的行分成多组）。这样的方法适用于那些包括大量数据的实体表。在应用中常要保留历史记录。可是历史记录非常少用到，这时额能够把频繁被訪问的数据同较少訪问的历史数据切割。或者也能够考虑数据备份清空的方式来保证数据的安全性。
二、生成物理
在将生成物理模型时相同须要考虑数据库的优化。本着没有最优仅仅有更优的原则考虑数据库的设计。以下针对数据库中字段和索引优化来展开讨论。
1、 字段
（1）尽量使用数字类型。数字类型查询和操作效率比字符串效率高（2）字段类型在满足增量需求情况下要选择同种存储类型中最小的。如：能使用smallint类型的字段，不要使用integer，这样索引字段能够被更快地读取。并且能够在1个数据页上放置很多其它的数据行，因而也就降低了I/O操作。
（3）字段不同意null值，可用Not Null+Default取代
（4）使用text、image类型。或者尽量不用。由于二进制的读写比較慢。并且读取的方法单一
（5）慎用自增字段，不利于数据迁移
2、主键
（1）选用组合字段数最小的候选键，这样在查询的字段较少，提高查询效率（2）非要使用组合主键的话，将但字段查询中反复率低的放在组合的前方
3、索引
使用索引时也注意一些误区，不是索引越多越好，索引也不等同于主键。在使用时应注意下面原则：（1）依据数据量决定哪些表须要添加索引，数据量小的能够仅仅有主键；
（2）依据使用频率决定哪些字段须要建立索引。选择常常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。
（3）把经常一起出现的字段组合在一起。组成组合索引。组合索引的字段顺序与主键一样。也须要把最经常使用的字段放在前面，把反复率低的字段放在前面；
（4）一个表不要加太多索引，由于索引影响插入和更新的速度。
（5）尽可能避免更新聚集索引，由于聚集索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。