Question

如何客观评测内存数据库的性能

Answer 1

　　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文件越长越大的时候才去整理数据库。