数据库性能优化杂谈

数据库性能优化杂谈

 

盼望着，盼望着，我的《PostgreSQL9.0性能调校》译著样书终于到手了，印刷精美。非常感谢本书责编陈冀康兄对我的教诲和帮助，使我更进一步认识到了“文责自负”这句话的深刻含义。好了，散尽题外话，回归到本文题目当中所包含的主旨上来。

 

这篇文章的题目是数据库性能优化，但是我在这里并不想具体讲如何去优化某种具体的数据库，以及如何在具体某种情景下的优化，因此题目当中出现了“杂谈”的写法。

 

《PostgreSQL9.0性能调校》一书讲述的是与PostgreSQL数据库有关的性能调优，拿到冀康兄推荐的电子版随便翻了翻，第一感觉让我想起了之前的另外一本书——《物理数据库设计》。前者之于后者的共同之处在于用了很多的篇幅来阐述硬件环境，以及一些相关的背景知识。为什么这么安排内容，仔细分析下来也不是那么难理解：

 

其一，鉴于开发人员对于软硬件的认识侧重不同，有必要对一些与性能有关的重要系统部件背景知识进行阐述。磁盘、磁盘控制器、阵列等等都需要做些简短说明。

 

其二，软件环境是寄生在硬件环境之上的，在进行调优之前必须要明确所处的环境，否则所有调优都变成一纸空谈。硬件能够为软件提供的是I/O，在系统中可能更多地会被表现为tps的数量单位，单位硬件内所能提供的最大吞吐I/O应当作为性能调优的一个重要考虑因素。两本书当中都不约而同的提到了TPC-H的基准评测，这些内容可以作为好事者进一步刨根问底的基础。同时这也是各个厂商用以炫耀并且自豪着的统一准则。

 

其三，作为软件开发者，特别是立志于DBA这样一项伟大事业的业内外人士，至少也应该了解一些硬件知识，不能把这部分内容寄托在苦逼的系统管理员身上。多了解些硬件的基础知识是没有坏处的。在对系统硬件充分了解的基础上，有些时候一个好的系统架构，可能比动辄几十万上百万的额外硬件采购好实施的多。

 

索性敞开谈了去，一个系统的优化，应该是多个层面上的优化。具体来说，也就是遵循着类似“硬件——操作系统——应用服务器——数据库——SQL语句——应用程序”这样的优化层次进行调优。尽量能够同一时间仅仅去优化一个层次上的东西，而不是多头调控；这样会有针对性的对性能问题进行分析和处理。要了解系统的真正瓶颈所在，这样也许能够解决类似“花钱增加磁盘存储器之后，才发现系统没有处理器资源去处理”这样的问题。

 

前面谈的都是硬件方面的问题，可能还有一些内容没有谈到，这其中就包括RAID技术、集群技术、和数据库分区等。这些内容在这里展开讲，可能可以写本书；或者至少是书中的某几个章节，而其中有些东西我本人也无法“说三道四”，仅在这里作为一些点缀罢了。而在软件方面，上面也曾经讲过，好的架构胜过去采购更高级的硬件。换句话说，对于数据库应用程序方面的优化，很多情况下是取决于数据库逻辑设计本身。逻辑设计不理想，其附加值就是随之而来的数据库性能问题。也许在系统上线初期没有什么显现，但是在系统运行一段时间之后就会比较突出。在翻译《物理数据库设计》一书的时候，书中就提到了它的姊妹篇——《逻辑数据库设计》（Database.Modeling.and.Design.5th.Edition,Morgan.Kaufmann）。这本书的电子版我读完之后感受还是很深的，从ER模型、UML到需求分析、数据建模，以及最终的实施过程等等都有涉及，应该来说还是本不错的教科书。也许是篇幅或者内容设置的关系，至今还未见中文版的出现（或是个人看法），有些小遗憾。

 

总结一下，在各位计划或者已经付诸实施对数据库进行调优工作的时候，不妨在心中或者脑海里反复琢磨以下一些问题，这样很容易能够确定从什么地方开始查找问题：

 

l  系统响应慢的何种程度？是否比预期的慢10%还是慢10倍？

l  是什么时候开始注意此问题的？最近还是一直都存在？

l  是否知道其他用户也存在同样的问题？抱怨此问题的是一两个人还是整个一组的人？

l  遇到的问题是否跟特定的事务或者应用程序有关？

l  问题是定时出现还是持续出现？

 

说了这么多，感觉比较杂，实属拿到样书后怀着激动的心情写出了这么一篇东西。拼音输入法打字，错别字在所难免，在我那几本译作当中也有出现，实属个人粗心大意，各位看官见谅并海涵。