1、使你的数据库结构规范化,但是不要求一定达到第三范式,为了显示和打印目的可以有
数据冗余
2、评估你的系统中对性能影响的关键处,减少被频繁访问的核心表的数量,并在这些核心
表上重点优化索引,表结构(尽量紧凑)。典型的核心表是代码表。
3、对于统计类应用,如果可能应写成触发器和存储过程,这样就有可能把一个消耗大量时
间的统计运算分布到每INSERT,DELETE,或者UPDATE来处理,从而极大提高查询类操作
的速度。
4、明智地选择把什么字段包含进群聚索引,或者非群居索引。对于数据按群居键值分布的
查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系
统资源和时间,所以过多的索引对性能是损害甚至是毫无效果的。
5、如果可能,可以利用大数据库对SQL的一些特殊规定来进一步优化,比如查询暗示。
6、适当选择硬件,综合考虑CPU,内存,I/O系统的性能,以当前的CPU,内存配置来看,
很多数据库系统的瓶颈出在I/O系统上。所以如果有可能,最好使用RAID。
当然如果你有足够的财力,可以买更好的服务器,或者搞服务器集群就更利害啦。
7、可能的话,尽量使用存储过程,因为存储过程的执行计划可以重复使用,而且不需要
象普通由CLIENT提交的SQL那样进行处理和编译。
8、检查你的应用程序设计,如果有可能,尽量减少查询次数和在网络上往返的数据。为了
获取少量字段而写SELECT * 对性能的损害也比较利害。
9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量
业务是允许脏读的,在不关键事务中使用脏读,或者读提交,可以大大降低DEADLOCK和
进程之间彼此等待的机会,从而把由于互相锁定资源引起的等待降低到最小。
不要在事务执行中进行大量计算或者与用户交互的操作,因为事务的执行在要求上是
不允许被打断的原子操作(回滚是失败的),所以事务应该多而短小。长事务会锁住
很多资源比较长的时间,因此也比较容易导致其他进程对资源的等待和死锁的机会。
10、评估你开发系统的关键业务,在很多数据库系统对性能的要求是彼此矛盾的,比如OLTP
应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度,而大量的索引对OLTP则是
负担。
11、不要在应用程序中写怪异的SQL 查询,比如 WHERE money!>40000,这样的语句,这种
SQL查询,数据库的SQL优化器是无法进行优化的。
12、定期维护和管理你的数据库系统,压缩掉那些“垃圾”空间,很多数据库系统执行类似
删除,事务等操作的时候,并不回收无用的物理空间。所以,制定一份合理的数据库
维护计划,不要等日志文件或者LOG文件越长越大的时候才去整理数据库。
还有很多很多要注意的东西,。。。。。。