2.MySQL性能优化篇（6~11章）.pdf
70墨值下载
第 6
6
6
6 章 影响 MySQL
MySQL
MySQL
MySQL Server
Server
Server
Server 性能的相关因素
前言：
大部分人都一致认为一个数据库应用系统（这里的数据库应用系统概指所有使用数据库的系统）的
性能瓶颈最容易出现在数据的操作方面，而数据库应用系统的大部分数据操作都是通过数据库管理软件
所提供的相关接口来完成的。所以数据库管理软件也就很自然的成为了数据库应用系统的性能瓶颈所
在，这是当前业界比较普遍的一个看法。但我们的应用系统的性能瓶颈真的完全是因为数据库管理软件
和数据库主机自身造成的吗？我们将通过本章的内容来进行一个较为深入的分析，让大家了解到一个数
据库应用系统的性能到底与哪些地方有关，让大家寻找出各自应用 系统的出现性能问题的根本原因，而
尽可能清楚的知道该如何去优化自己的应用系统。
考虑到本书的数据库对象是 MySQL ，而 MySQL 最多的使用场景是 WEB 应用，那么我们就以一个 WEB 应
用系统为例，逐个分析其系统构成，结合笔者在大型互联网公司从事 DBA 工作多年的经验总结，分析出
数据库应用系统中各个环境对性能的影响。
6.1
6.1
6.1
6.1 商业需求对性能的影响
商业需求对性能的影响
商业需求对性能的影响
商业需求对性能的影响
应用系统中的每一个功能在设计初衷肯定都是出于为用户提供某种服务，或者满足用户的某种需
求，但是，并不是每一个功能在最后都能很成功，甚至有些功能的推出可能在整个系统中是画蛇添足。
不仅没有为用户提高任何体验度，也没有为用户改进多少功能易用性，反而在整个系统中成为一个累
赘，带来资源的浪费。
不合理需求造成资源投入产出比过低
需求是否合理很多时候可能并不是很容易界定，尤其是作为技术人员来说，可能更难以确定一个需
求的合理性。即使指出，也不一定会被产品经历们认可。那作为技术人员的我们怎么来证明一个需求是
否合理呢？
第一、每次产品经理们提出新的项目（或者功能需求）的时候，应该要求他们同时给出该项目的预
期收益的量化指标，以备项目上先后统计评估投入产出比率；
第二、在每次项目进行过程中，应该详细记录所有的资源投入，包括人力投入，硬件设施的投入，
以及其他任何项目相关的资源投入；
第三、项目（或者功能需求）上线之后应该及时通过手机相关数据统计出项目的实际收益值，以便
计算投入产出比率的时候使用；
第四、技术部门应该尽可能推动设计出一个项目（或者功能需求）的投入产出比率的计算规则。在
项目上线一段时间之后，通过项目实际收益的统计数据和项目的投入资源量，计算出整个项目的实际投
入产出值，并公布给所有参与项目的部门知晓，同时存放以备后查。
有了实际的投入产出比率，我们就可以和项目立项之初产品经理们的预期投入产出比率做出比较，
判定出这个项目做的是否值得。而且当积累了较多的项目投入产出比率之后，我们可以根据历史数据分
析出一个项目合理的投入产出比率应该是多少。这样，在项目立项之初，我们就可以判定出产品经理们
的预期投入产出比率是否合理，项目是否真的有进行的必要。
有了实际的投入产出比率之后，我们还可以拿出数据给老板们看，让他知道功能并不是越多越好，
让他知道有些功能是应该撤下来的，即使撤下该功能可能需要投入不少资源。
实际上，一般来说，在产品开发及运营部门内部都会做上面所说的这些事情的。但很多时候可能更
多只是一种形式化的过程。在有些比较规范的公司可能也完成了上面的大部分流程，但是要么数据不公
开，要么公开给其他部门的数据存在一定的偏差，不具备真实性。
为什么会这样？其实就一个原因，就是部门之间的利益冲突及业绩冲突问题。产品经理们总是希望
尽可能的让用户觉得自己设计的产品功能齐全，让老板觉得自己做了很多事情。但是从来都不会去关心
因为做一个功能所带来的成本投入，或者说是不会特别的关心这一点。而且很多时候他们也并不能太理
解技术方面带来的复杂度给产品本身带来的负面影响。
这里我们就拿一个看上去很简单的功能来分析一下。
需求：一个论坛帖子总量的统计
附加要求：实时更新
在很多人看来，这个功能非常容易实现，不就是执行一条 SELECT COUNT(*) 的 Query 就可以得到结 果
了么？是的，确实只需要如此简单的一个 Query 就可以得到结果。但是，如果我们采用不是 MyISAM 存储
引擎，而是使用的 Innodb 的存储引擎，那么大家可以试想一下，如果存放帖子的表中已经有上千万的帖
子的时候，执行这条 Query 语句需要多少成本？恐怕再好的硬件设备，恐怕都不可能在 10 秒之内完成一
次查询吧。如果我们的访问量再大一点，还有人觉得这是一件简单的事情么？
既然这样查询不行，那我们是不是该专门为这个功能建一个表，就只有一个字段，一条记录，就存
放这个统计量，每次有新的帖子产生的时候，都将这个值增加 1 ，这样我们每次都只需要查询这个表就 可
以得到结果了，这个效率肯定能够满足要求了。确实，查询效率肯定能够满足要求，可是如果我们的系
统帖子产生很快，在高峰时期可能每秒就有几十甚至上百个帖子新增操作的时候，恐怕这个统计表又要
成为大家的噩梦了。要么因为并发的问题造成统计结果的不准确，要么因为锁资源争用严重造成整体性
能的大幅度下降。
其实这里问题的焦点不应该是实现这个功能的技术细节，而是在于这个功能的附加要求 “ 实时更
新 ” 上面。当一个论坛的帖子数量很大了之后，到底有多少人会关注这个统计数据是否是实时变化的？
有多少人在乎这个数据在短时间内的不精确性？我想恐怕不会有人会傻傻的盯着这个统计数字并追究当
自己发了一个帖子然后回头刷新页面发现这个统计数字没有加 1 吧？即使明明白白的告诉用户这个统计
数据是每过多长时间段更新一次，那有怎样？难道会有很多用户就此很不爽么？
只要去掉了这个 “ 实时更新 ” 的附加条件，我们就可以非常容易的实现这个功能了。就像之前所提
到的那样，通过创建一个统计表，然后通过一个定时任务每隔一定时间段去更新一次里面的统计值，这
样既可以解决统计值查询的效率问题，又可以保证不影响新发贴的效率，一举两得。
实际上，在我们应用的系统中还有很多很多类似的功能点可以优化。如某些场合的列表页面参与列
表的数据量达到一个数量级之后，完全可以不用准确的显示这个列表总共有多少条信息，总共分了多少
of 130
70墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论