MySQL数据库后台优化的方案.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
MySQL数据库后台优化的方案

MySQL数据库后台优化的方案   摘 要:随着开发的一款手机应用用户的快速增长,开始阶段设计的MySQL数据库和服务器架构无法满足业务增长的实际需求,数据量过大导致前端手机应用API接口响应慢,同时后台web运营统计的速度也非常慢,简单的进行一些SQL语句级别的优化无法满足实际需求,因此对整体架构的优化势在必行。文章针对实际业务逻辑需要基于现有硬件架构的基础上,阐述分析业务瓶颈和最小改动下对后台统计功能的数据库查询优化方式。以最小代价完成了适应大量数据的MySQL优化。   关键词:移动应用;MySQL;优化;PHP   前言   开发的一套手机应用的后端服务器支持系统,目前的业务是前端两台Web服务器做HA,一台服务器做图片服务器。前端web服务器承担的是用户访问和手机客户端的API接口数据处理工作,要求处理速度快但是没有大规模查询。每天用户访问量大约为5-10万IP,分别用两台web做HA负载。两台Web共用一个数据库保持数据一致性,另外使用一台服务器数据库做数据库从库。从库作用是在主库死机之类的问题出现的时候,切换到从库来进行服务。但是实际起到的作用只是一个备份设备而已。   1 当前面临的问题   每次后台进行统计查询,由于数据总量过大,查询全表就会造成表锁死或者低速响应,造成客户端无法得到正常响应。鉴于这种问题,我们对后台统计功能进行一些优化处理。   问题的原因很容易定位,就是表数据量太大,可是业务的逻辑又不允许进行简单分表。尝试做表分区效果也很一般。查询大表的速度实在难以接受:例如lee_userlog表数据已经有两千六百多万条数据,每天需要查询这个表,看数据总体统计情况。具体问题分析如下:   直接加memcache的缓存,生存时间10秒-60秒不等。好处是实施方式简单,但是非常不适合我们的业务,因为每次生成缓存的查询还是非常慢,并且由于每次查询后间隔至少10分钟才查第二次,因此这种简单的缓存方式根本起不到任何作用,这样的查询并不十分频繁,每小时大约要看2-3次,因此直接做缓存是没有意义的,因为第一次查的时候还是慢,第二查完以后可能十几分钟后才查第二次。如果将结果缓存到半小时以上,将导致两次查询结果完全相同,导致无法对运营状态进行有效的数据分析,运维人员没法根据统计结果做出相应调整,考虑增加简单sql查询缓存,解决了按天查询的时候每天固定数据缓存的问题,提升效果明显,但是查当天数据的时候由于数据量还是很大,所以依然影响速度。进一步考虑的方案是,sql每次都查全表,但是后台管理界面查询时直接返回缓存数据,但是运行一个更新数据的服务,每10分钟在后台运行一次缓存对应的sql语句,将结果更新到结果集中,这样的设计牺牲了部分实时性,但符合实际使用的情况,至少间隔10分钟才会进行查询查看统计结果。同时大大增加用户使用的查询速度。瞬间即可得到结果,根据这种思路我们分析实际方案。   2 问题的解决方案   首先可以做的最简单的事情就是把前端用户使用数据库和后台查询数据库分开,这样进行读写分离后至少进行大规模查询不会造成业务卡死。我们建立一个只读的用户连接到从库,用户权限设置为只允许进行SELECT操作。   其次根据实际业务逻辑将问题拆解为三种情况:   (1)按日存储统计结果类型数据,每天会产生数据,但是过了当天数据就变为静止数据。统计结果不会改变。   (2)数据总体情况统计,整个表的数据记录,求和等操作。随时跟着时间在增加或减少。   (3)更复杂的统计情况,数据按日统计,但统计出来的数据也随时会变化。   第一种情况:按日统计的,在第一次查询的时候保存为一条数据记录通过查询时间来分析,如果含有当天记录则不缓存:   if (date(Y-m-d,$puttime)!=date(Y-m-d) date(Y-m-d,$endtime)!=date(Y-m-d))   如果是按日统计数据,不含有当天数据的,直接缓存统计结果到另一个缓存表中。   第二种情况:我们将数据统计的SQL语句整体缓存到缓存表中,后台做一个服务程序定时更新这个表,维持总体统计数据为准实时,这一过程大约每10分钟会更新一次,稍有滞后但是依然能满足实际需求。   第三种情况:我们记录每次更新数据的时间点和结果。新一次查询的时候,由于数据永远处于增量情况,因此我们只需要查出上次时间点到当前的增量数据统计情况合并如上次缓存结果中,同时更新缓存结果到当前时间点即可。这样查询量减少了几个数量级,速度也就有了保障。   3 缓存表设计   db_cache   字段说明:   sql_name插入值的之前要将插入sql语句做处理,防止sql嵌套出现问题。   sql_hash字段为表中的唯一字段,用来检索查询

文档评论(0)

3471161553 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档