数据库性能优化浅析 (自我分析)

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

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

。

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

------确定极限,需要一定的OS和硬件知识

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

------以冗余和业务关系来减少关联,如对客户与车的设计

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

------加锁和不加锁以业务为实际标准!

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

------针对每种数据库的参数进行调优!缓存分配,等 以后追加 ^_^

 

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

以上的调优手段只是最为基本的，但是通过调优就会发现，不遵守严格的数据库表关联，事务锁是一个法宝，也是用的最多的做法。但是这样做，数据库的功能使用已经很少了。这也是我之所以在“数据库的软肋”文章发表了看法的原因。

可以做如下的比喻：

古代有人要用马车运货，要求最快到达，本来用马最合适，偏偏选用大象。大象住不进马圈，只好加大马圈，大象食量很大，只好给它喂更多的粮食，大象不如马驾驭方便，只好专门请训练大象的人。到最后，大象拉车慢，成本高，误了此人运货的时限，此人后悔不已。其实大象不是用来壮胆的，要求最快到达，要的是效率，而不是体积。体积大只能壮胆，别无它用。用商用数据库感觉其实就是壮胆，个家之言。 

 ------不要为了商业数据库而强行采用商业数据库 需要日后实践中慢慢体会