数据库性能优化浅析

数据库性能优化浅析

从奥运会门票销售系统瘫痪发生以来，我写了一篇再显数据库软肋的文章，在网络上引起了热议。很多网友也给我发信表达了他们的看法，本人深受启发，增长了很多的知识。奥运门票系统事件以来，大家对数据库的优化更加感兴趣。虽然我本人对高性能系统有其他非数据库观点，但是理论上讲，通过合理的优化，数据库是可以支撑高压力访问的。有很多网友跟我说，既然我认为数据库有问题，为什么不写一篇数据库优化的文章？本人一直从事数据库优化，分布式系统领域工作的，才疏学浅，但还是想把自己对数据库优化的看法写出来，欢迎大家讨论，共同提高。

互联网系统区别于erp，boss等系统的最大区别就是它的技术架构把的高性能的要求放在了首位，因为每天都有来自全球各地的对服务器的访问

。

1。性能定位。
在对一个后台数据库系统进行调优之前，一定要定位性能的瓶颈。但是复杂的后台系统往往是各种系统的对立统一的整体，消除了这个瓶颈，可能另外的以前不是瓶颈的地方又成为瓶颈。典型的有减少磁盘访问次数，但是数据就要占用内存等。可以用“排队法”来进行建模。假如请求随机到来，计算机的各种资源包括cup,磁盘，内存等的利用率会保持健康值。不断加压，直到各种资源的利用率到达危险值时，队列开始阻塞，后面发过来的请求就不会被处理。这时，记下这个队列长度和计算机的资源占用数据，然后开始调优，比较各种资源的数据，反复进行。直到你认为不会再有调优可能，大压力下，队列仍然很短，再开始进行服务器的分布。以上就是大概的思路。

2。设计调优。
数据库的设计调优是最普遍的，一般凡是发现性能有问题，第一个想到的就是它的表设计是不是有问题了。减少表的关联，减少关系数据，感觉似乎要违背范式的天条，但是为了性能，这时最普遍的做法。

3。索引，事务优化。
为了查询速度快，针对某个字段建立索引，一般比较快的索引就是hash和b+数。但是你的需求要保证尽量少的更新这个索引。事务的话就是要尽可能的保证不要上锁，一个事务在查询，另一个在更新，如果解除了锁，效率肯定高，但是查询不保证准确。高性能数据库设计原则就是尽量减少锁。还有数据库日志系统等。

4。数据库参数调整。
每个商用数据库都有很熟的技术支持人员和详细的培训手册，不再叙述。

5。硬件调整。
现在的数据库一般都把文件系统建立在磁盘上，如果一个数据库访问量巨大，那么磁盘的工作量就非常大。如果，经过性能定位，发现的确是磁盘问题，下一步就是要增加磁盘，而不是更换磁盘。使一个频繁访问的大文件系统分布在若干磁盘上要比世界上最高效的一个磁盘要好。这是在硬件层次上的分布。当然，如果选用RAID，那么到底是RAID几还要根据具体情况考虑了。内存调整，要看具体需求，如果一条记录在几分钟之内会在被访问，就把它放到内存里。内存和磁盘的比例要看具体财力和实际需求了。

当今数据库有着非常强大的功能和各种各样的组件，想达到什么目的都没有问题。财力雄厚，可以直接购买成熟的商用数据库，解决后顾之忧；财力不足，采用开源产品，也是不错的选择。