首页 > 代码库 > 【数据库优化（持续更新）】--第一弹设计优化
【数据库优化（持续更新）】--第一弹设计优化
前言
数据库是程序的仓库，也是程序中最脆弱的一部分，因为它的脆弱性和重要性，所以需要专门进行管理和优化。在如今的网络化的时代更加需要数据库的灵活和快捷，一个高效的数据库能够使程序运行效率更快，提高程序的运行效率。但往往对数据库的设计达不到我们想要的效果，所以数据库的优化显得尤为重要。该系列文章正是考虑大数据量的当今如何才能让数据库的设计更加灵活，数据检索、操作更加高效展开的讨论，其中涉及到的优化方法是在笔者长期的开发经验以及其它有关数据库优化的文章基础上进行总结的，如果有异议还请指出。
数据库的优化分为很多种，因为SQL对象较多，在对数据库进行优化时需要考虑它们对性能的影响，而且优化的程度没有最优，只有更优，这些优化方案还要根据使用环境的不同进行取舍，不一定都能保持高效率，你比如说开发的系统本身数据量不大，而且又是C/S系统这时候就可以不用考虑那么多的优化问题，把重心可以放到程序的友好程度、稳定性、健壮性、灵活性上。首先从设计阶段开始考虑数据库的优化，大致的内容进行了整理汇总图，如下。
设计阶段的优化需要有相当多的经验才可以，未雨绸缪才是最高境界，所以要预见性的避免很多问题，在设计时就让数据库查询修改效率很高。
一、规范化
1、数据库的规范化
在创建数据库的时候首先要尽量符合三范式的要求，因为三范式是一个指导性的标准，在复杂的表关系中可以考虑使用范式来达到表之间关系的平衡。在设计表结构时三范式已经很充足了，另外可以考虑增加冗余字段，有时候可以增加检索的效率。
一范式：每个字段表示的实体属性唯一，最基础的设计规范，一般的字段都会符合；
二范式：消除部分依赖；
三范式：消除传递依赖。
如果完完全全按照三范式设计表结构的话，有时候会很繁琐，对于简单的实体转换成表结构的时候可以不采用三范式，因为范式会产生较少的列和更多的表，这样更不利于检索修改，所以要根据实际情况而定。
2、非规范化
合理的冗余
在设计表结构时可以适当的考虑适当的冗余，好的冗余能大大提高表的检索效率。在设计时常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中，这时可以考虑添加触发器来保持数据的一致性（不建议这样做，触发器有很多不确定性）；另外如果设计的表关系产生了许多表但是在检索时需要合并关系，这时可以考虑在数据库实体中添加重复列。
表分割
表的冗余字段可以提高表的效率，同样针对大数据量处理的时候需要考虑对表进行垂直和水平的分割。
（1）垂直分割：把一个实体表分割成两个表。这样把频繁访问的数据同较少被访问的数据分割。在进行分割前要求每张表复制首要关键字。这样产生的表有利于并行处理，将产生列数较少的表。
（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）尽可能避免更新聚集索引，因为聚集索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。