- 1、本文档共12页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
Mysql应用层面的优化.doc
Mysql应用层面的优化
本书若不讲解一章关于连接到MySQL的应用程序优化的内容,那就不能算完整,因为人们常常把一些性能方面的问题都归咎到MySQL身上。书里面我们更多地是讲到MySQL的优化,但是,我们不想让你错过这个更大的图景。一个糟糕的应用设计会使你无论怎么优化MySQL也弥补不了它带来的损失。实际上,有时候对于这类问题的答案是把它们从MySQL上脱离开来,让应用自己或其他工具来做这些事情,这样或许会有较好的性能表现。
本章不是构建高性能应用的参考书,我们只是希望通过阅读这一章让你避免那些常见的会伤及MySQL性能的小错误。下文中我们以Web应用为主要讲解对象,因为MySQL主要是用在Web应用上的。
1.应用程序性能概述
对于更快性能的追求开始时很简单:应用响应请求花费了太长的时间,你总要为此做点什么吧。然而,真正的问题是什么呢?通常的瓶颈是缓慢的查询、锁、CPU饱和、网络延时和文件I/O。如果应用配置错误,或者不恰当地使用资源,以上任何一个因素都会引出一个大问题。
1.1找出问题的根源
第一个任务是找出肇事者。如果你的应用具备了显示系统运行概况的功能,这做起来就简单了。如果你已经做到了这一步,但还是没法找出引起性能低下的原因,那你就要增加更多的概况信息的调用,去找出那些要么缓慢要么被多次调用的资源。
如果你的应用因为CPU高占用率而一直等待,并且应用里有高并发性,那我们提到过的丢失的时间可能就成问题了。鉴于此,有些时候在有限的并发条件下生成应用的概况信息是很有用的。
网络延时会占用大块的时间,哪怕是在局域网里。应用层面的概况信息已经包括了网络延时,因此,你应该在概况系统里看到网络往返延时带来的影响了。举例来说,如果一个页面执行了1 000个查询,即使每次只有1毫秒的延时,那累加起来也有0.5秒的响应时间,这对高性能应用来说已经是个很大的数目了。
如果应用层面概况信息收集得很充分,那就不难找出问题的根源。如果还没有内置概况功能,那就尽可能地加上它。如果你无法添加这个功能,那也可以试试第76页的当你无法加入概况信息代码时里提供的那些建议。这个总比钻研像什么引起应用变慢那样没头绪的理论设想要更快更容易。
1.2寻找常见问题
同样的问题我在应用里一次又一次地遇到,其原因往往是人们使用了设计糟糕的原有系统,或者采用了简化开发的通用框架。虽然这在某些时候能让你在开发一些功能时变得方便又快速,但它们也给应用增加了风险,因为你不知道它们底下是怎么工作的。这里有一张清单你应该逐个检查一下:
在各个机器上的CPU、磁盘、网络和内存资源的使用情况如何?使用率对你而言是否合理?如果不合理,就检查那些影响资源使用的应用的程序基础。配置文件有时就是解决问题的最简单方法,举例来说,如果Apache耗光了内存,那是因为它创建1 000个工作者进程,每个工作进程需要50MB内存,这样,你就可通过配置文件配置这个应用能申请的Apache工作者进程数。你也可以配置系统,使之创建进程时少用些内存。
应用是否真正使用了它所取得的数据?一个常见的错误是:读取了1 000行数据,却只要显示10行就够了,其他990行就丢弃了(然而,如果应用缓存了余下的990条记录供以后使用,那么这可能是特意做的优化)。
应用里是否做了本该由数据库来做的处理?反之亦然。有个对应的例子是:读取了所有行的数据,然后在应用里计算它们的总数;以及在数据库里做复杂的字符串处理。数据库擅长于计数,而应用的编程语言擅长于正则表达式。你该使用正确的工具去干正确的活。
应用里执行了太多的查询?那些号称能把程序员从SQL代码里解救出来的ORM(Object-Relational Mapping)就因此常被人们责备。数据库服务器是被设计用来匹配多表数据的,因为要移除那些嵌套循环,代之以联接(Join)来做同样的查询。
应用里执行的查询太少了?我们只知道执行了太多的查询会成为问题。但是,有时手工的联接和与其相似的查询是个好主意,因为它们可以更加有效地利用缓存,更少的锁(尤其是MyISAM),有时当你在应用的代码里使用一个散列联接时(MySQL的嵌套循环的联接方法往往是低效的),查询的执行速度会更快。
应用是不是在毫无必要的时候还连到MySQL上去了?如果你能从缓存里读取数据,就不要去连数据库了。
应用连接到同一个MySQL实例的次数是不是太多了?这可能是因为应用的各个部分都各自开启了自己的数据库连接。有个建议在通常情况下都很对:从头到尾都重用同一个数据库连接。
应用是不是做了太多的垃圾查询?一个常见的例子是在做查询前才去选择需要的数据库。一个较好的做法是连接到名称明确的数据库,并使用表的全名做查询。(这样做,也便于通过日志或SHOW PROCESSLIST去查询情况,因为你可以直接执行这些查询语句,无需
文档评论(0)