发布网友 发布时间:2022-04-24 14:48
共1个回答
热心网友 时间:2022-04-07 17:48
1、使你的数据库结构规范化,但是不要求一定达到第三范式,为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处,减少被频繁访问的核心表的数量,并在这些核心表上重点优化索引,表结构(尽量紧凑)。典型的核心表是代码表。3、对于统计类应用,如果可能应写成触发器和存储过程,这样就有可能把一个消耗大量时间的统计运算分布到每INSERT,DELETE,或者UPDATE来处理,从而极大提高查询类操作的速度。查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系统资源和时间,所以过多的索引对性能是损害甚至是毫无效果的。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文件越长越大的时候才去整理数据库。还有很多很多要注意的东西,。。。。。。