提升MySQL性能

2017年8月7日星期一

老男孩IT教育每日简报

每个DBA都需要知道的10个提升MySQL性能的基本技巧

从工作量分析到索引的三条规则,这些专家见解肯定会让您的MySQL服务器尖叫。

在所有的关系数据库中,MySQL已经被证明了完全是一头野兽,只要通知停止运行就绝对不会让你多等一秒钟,使你的应用置于困境之中,你的工作也承受极大的风险。

不过事实是,普通的错误都在MySQL性能错误的射程之内。所以为了使你的MySQL服务器能够高速运转,提供稳定且持续的服务,消除这些错误是非常有必要的,但是这可能常常会被你的繁忙工作或配置陷阱微妙地遮蔽了。

幸运的是,许多MySQL性能问题其实都有相似的解决办法,发现并解决问题,然后你的MySQL用起来就顺手多啦。

接下来就和大家分享一下10个使MySQL性能提升的小技巧。

MySQL性能提升小技巧1:对你的工作进行配置

想要了解你的服务器到底如何支配时间,最好的办法就是对服务器的工作进行配置。通过配置你的服务器,你可以expose最昂贵的query来为将来的调优做准备。从这个角度,时间就是最重要的衡量标准,因为当你对你的服务器发起一个query之后,除了它到底多块的完成之外你不会关心任何其他事。

配置你的工作文件的最优解就是MySQL Enterprise Monitor的query分析仪或者Percona Toolkit的pt-query-digest。这些工具可以帮助你捕捉你的服务器正在执行的询问以及返回按响应时间递减顺序排序的任务表,它还会持续不断地把最昂贵、费时的任务更新在最上方,这样你就能知道你的精力应该更加集中在什么地方了。

工作文件配置工具会把相似的询问分在一个组,你可以很方便地查看低速运行或者是告诉运行但是多次进行的询问。

MySQL性能提升小技巧2: 深入理解四个基本资源

一个数据库服务器需要以下4种资源才能正常运转:CPU,内存,硬盘以及网络。如果这其中任何一种性能不足,运转不力或者超负荷运转的话,那么数据库服务器就非常可能表现不佳。

理解基础的资源是非常重要是以下两个层面:选择硬件以及疑难问题解答。

当为MySQL选择硬件的时候,确保所有的组件都表现良好。同样重要的是把它们进行合理的配置。大多是时候,一些机构会选择高转速的CPU以及硬盘,但是他们通常来讲内存都不够用。在某些情况下,按照数量级增加内存是提升性能最廉价的办法,尤其是工作负载是绑定磁盘的情况下。这听起来可能违反常识,但是在许多情况下,硬盘都是过度使用的,因为没有足够的内存来储存数据工作集。

另外一个平衡的典范当属CPU。在大多数情况下,MySQL使用高转速的CPU会运转得很好,因为每一个询问都是在单线程中运行而不能在CPU之间并行。

当要解答疑难问题的时候,请了解清楚所有资源的性能和使用情况,用你审慎的目光来判断它们到底是本来就性能差劲还是因为承载了过多的任务。这个姿势应该能让你解决问题快一些。

MySQL性能提升小技巧3:别吧MySQL当成一个队列使

队列和队列访问模式可以在你完全没有察觉的情况下偷偷进入你的应用。举个栗子,如果你设置了某个项的状态,以便某个特定的工作进程在调用它之前可以声明它,那么你就在无意中创建了一个队列。把邮件标记为未发送,发送它们,然后它们被标记为已发送就是一个很好理解的栗子。

队列会产生问题主要有2个原因:它们连续运转你工作,防止它们并行,那么这通常就会产生一个表格,里面包含了进程中的工作还有很久以前已完成工作的历史数据。这不仅会使你的应用产生延迟而且也会给MySQL增加不必要的负荷。

MySQL性能提升小技巧4: 花费最少的结果先过滤

优化MySQL性能最好的办法就是先完成廉价、不确定的工作,然后在最小的结果数据集中完成艰难、准确的工作。

例如你要通过一个给定的地理位置半径来找到你想要的东西。在大多数程序员的工具箱里,他们首先会想到的一定是计算球面上的距离的大圆公式(Haversine)。但是用这个公式的问题在于可能要用到很多三角方面的运算,这对CPU的要求是非常高的。大圆的计算往往运行缓慢,使得机器的CPU使用率飙升。

在你开始应用大圆公式之前,在总集当中将你的记录减少成最小的子集,并把结果集整合成一个确切的圆。一个包含圆(确切或不确切的)的正方形是解决这个问题最简单的方法。这样的话,正方形之外的一切都不回碰上这些成本昂贵的三角函数。

MySQL性能提升小技巧5:了解两种伸缩性死亡陷阱

伸缩性其实并不像你想象的那样捉摸不定。实际上在数学当中已经有非常明确的将伸缩性表示为方程式的定义。这些方程式突出展现了为什么系统并没有如预期那样的良好伸缩。

参见通用可扩展法(Universal Scalability Law)—非常清晰地解释和量化了一个系统的伸缩性特性。它从两个基础成本方面对伸缩性问题进行了阐释:序列化(serialization)和串扰(crosstalk)。

多进程必须为在伸缩性上具有固有限制的序列化停止工作。相似地,如果多个进程必须时时刻刻互相交流才能配合他们的工作的话,他们就是在互相限制。

避免序列化以及串扰,你的应用伸缩性将会大大提升。那么在对MySQL来说意味着什么呢?因情况而异,但有些示例可以避免对行进行排它锁定。关于队列,参见技巧3,往往会因为队列伸缩性就变得很差。

MySQL性能提升小技巧6:不要太关注配置

DBA常常耗费大量的时间来调整配置。换来的结果有时却是伤害而不是大的提升。我看到过许多的最优化的服务器时不时就崩溃,内存不足,而且在工作负载稍微多一点的时候就表现很差。

MySQL上搭载的默认配置是一刀切并且严重过时的,但是它们也不需要完全重新配置。只要把最基础的设置正确,有需要的话再做小幅调整即可。在大多数情况下,通过正确设置大约10个选项,你可以获得服务器峰值性能的95%。其他无法应用此方法的的情况的话应该是非常特殊的情况,所以就不用去管他了。

在大多数情况下,服务器“转换”工具是不推荐的,因为它们常常会有一些在特定情况下并不适用的规则。有些甚至存在危险且不准确编码—例如缓存命中率和内存消耗公式。这些都是不对的,而且随这时代的进步他们变得更加地不对。

MySQL性能提升小技巧7: 小心分页询问

分页应用常常会把服务器搞瘫痪。在向你展示结果的页面当中,有翻到下一页的链接,这类应用通常不以索引的方式进行分类整理,然后他们使用一种 LIMIT和 offset使得服务器做大量的工作生成,然后丢弃行。

优化选项在用户界面常常自己就能找到。而不是展示确切的页数结果以及每个页面的单独链接,只展示下一列的链接就好。你也可以防止大家翻到太后面的页数。

从质询方面来看,你可以比你想要的多选取一行,然后当你点击“下一页”链接的时候,你可以指定最后一行作为下一组结果的起点,而不是使用带offset的 LIMIT。举个栗子,当用户在查看120行中的第101行时,你会同时select第121行;为了递交下一页,你可以向服务器询问第121行或者超过121的行,限定在21。

MySQL性能提升小技巧8: 及时保存数据,审慎警告

监管和预警是必不可少的,但是典型的监控系统到底怎么了?它开始发送一些错误的手势,然后系统管理员就设置了垃圾邮件过滤规则来停止这些烦扰。然后很快你的监管系统就会完全瘫痪。

我倾向于从两个方面来看待监管;获取指标以及发出预警。尽可能的获取并保存指标是非常重要的,因为当你想要知道系统到底改变了什么的时候你会很庆幸你当初保存了它们。有一天会突然出现一个很奇怪的错误,然后你就会很高兴你有能力指出服务器的工作负载中的一段然后展示这个改变。

相比之下,警告就可能有点多了。人们常常会对缓存命中率或者短期内每秒所创建的表格发出警告。问题是对这种缓存命中率并没有一个合适的阈值。正确的阈值并不是随着服务器的不同而变化,而是随着你工作负载的不同,每一个小时都是不一样的。

这就导致,警告只能有节制地并且只能在预示一个具体、可操作的问题时才是可行的。一个低缓存命中率并不是可操作的问题,而且他也不指向一个实在的问题,但对连接尝试没有响应的服务器才是真正需要结局的问题。

MySQL性能提升小技巧9: 学习index的三条法则

Index可能是数据库汇总最难理解的概念,因为很容易就对Index到底如何工作以及服务器如何使用它们感到困惑。确实要花些力气才能真正理解它到底是怎么回事。

Index经过适当设计后,主要在数据库服务器中提供如下三种服务:

Index让服务器查找相邻行的集合而不是单独的行。许多人可能会认为index的作用就是为了查找单独的行,但是查找单独的行会导致混乱的硬盘操作,速度就会变慢。而且查找行的集合要容易多了,所有或者说大多数都比一次只查找一个行要有趣多了。

Index通过按照阅读喜好进行排列省去了整理的过程。整理是耗费巨大的。按照自己的喜好进行阅读效率也更高。

Index完全满足了服务器的询问,根本就不需要再连接表格。这是众所周知的覆盖索引或仅索引查询。

如果你可以定义自己的索引和询问来利用这三个机会,你就可以使查询速度快几个数量级。

MySQL性能提升小技巧10: 利用同行的专业知识

不要一个人冒险。如果你对一个问题感到烦恼,同时也在做一些对你来说有逻辑且隔离的解决方式,那很好。这在20次中可能会有19次是有效的。但是剩下的1次,你可能会掉进兔子洞里,会非常费时费力,这完全是因为你现在所做的努力只是看起来可能是有意义的。

建立与MySQL相关的资源网络,这超越了工具和故障排除指南。有一些非常有知识的人潜伏在邮件列表、论坛、问答网站上,等等。会议、展会和本地用户团体活动都提供了宝贵的机会,让你能与那些在紧要关头帮助你的同行建立联系。

每日一句;人生是一条上下波动的曲线,有时候低,有时候高。低的时候你应该高兴,因为很快就要走向高处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,311评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,339评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,671评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,252评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,253评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,031评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,340评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,973评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,466评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,937评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,039评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,701评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,254评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,259评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,485评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,497评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,786评论 2 345

推荐阅读更多精彩内容