【高性能MySQL】查询性能优化

合理的表结构、索引对于高性能查询来说是必不可少的。但是还需要合理的设计查询。如果查询写得很糟糕,那么表结构再合理、索引再合适,也无法实现高性能。
因此高性能的查询依赖于这三点:查询优化、索引优化、表结构优化。

为什么查询速度会慢

如果把查询看作是一个任务,那么它由一系列子任务组成,每个子任务都会消耗一定的时间。如果要优化查询,实际上要优化其子任务,要么消除其中一些子任务,要么减少子任务的执行次数,要么让子任务运行得更快。
查询的生命周期:从客户端,到服务器,然后在服务器上进行解析,生成执行计划,执行(包括调用存储引擎及调用后的排序、分组等数据处理),并返回结果给客户端。
在完成这些任务时,查询需要在不同地方花费时间,包括网络,CPU 计算,生成统计信息和执行计划、锁等待等操作。

优化数据访问

查询性能低下的原因可能是以下两种:

  1. 应用程序可能检索了超过需要的数据(访问了太多的行或者太多的列)。
  2. MySQL 服务器层可能在分析大量超过需要的数据行。
请求了不需要的数据
  1. 应用程序中做分页查询。
  2. 只查找确实需要的列,不用 SELECT *。
  3. 不要做重复查询。
MySQL 在扫描额外的记录

在确定了查询只返回需要的数据以后,接下来应该看查询为了返回结果是否扫描了过多的数据。最简单的衡量查询开销的三个指标如下:

  • 响应时间
  • 扫描的行数
  • 返回的行数

一般 MySQL 使用如下三种方式应用 WHERE 条件,从好到坏依次为:

  • 在索引中使用 WHERE 条件来过滤不匹配的记录。这是在存储引擎层完成的。
  • 使用覆盖索引返回记录,直接从索引中过滤不需要的记录并返回命中的结果。这是在 MySQL 服务器层完成的,但无需再回表查询记录。
  • 从数据表中返回数据,然后过滤不满足条件的记录。这是在 MySQL 服务器层完成的,MySQL 需要先从数据表读出记录然后过滤。

如果发现查询需要扫描大量的数据但只返回少数的行,可以这么做:

  • 使用覆盖索引扫描
  • 改变库表结构。例如使用单独的汇总表。
  • 重写复杂的查询。

重构查询的方式

一个复杂查询还是多个简单查询

一般情况下,能用一个查询解决的事就不要用多个查询。因为每次查询都有网络通信、查询解析和优化的过程。但是也有例外。因为 MySQL 从设计上让连接和断开连接都很轻量级,在返回一个小的查询结果方面很高效。

切分查询

比如需要将某张表的全部数据做DML操作,可以分多次进行。防止一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

分解关联查询

将一个关联查询分解为多个查询的优势:

  • 让缓存效率更高
  • 减少锁的竞争
  • 便于对数据库进行拆分
  • 查询本身效率可能会有所提高,如用 in()代替关联查询,可以让MySQL 按照 ID 顺序查询,这可能比随机的关联要更高效。
  • 可以减少冗余记录的查询。应用层做关联查询,意味着对于某条记录应用只需要查询一次,而在数据库中做关联查询,则可能需要重复地访问一部分数据。

查询执行的基础

MySQL 执行一个查询的过程,到底做了些什么:

Screen Shot 2017-05-15 at 10.45.27.png
  1. 客户端发送一条查询给服务器。
  2. 服务器检查查询是否可以命中缓存,命中则直接返回。否则进入下一阶段。
  3. 服务器进行 SQL 解析、预处理,再由优化器生成对应的执行计划。
  4. 调用存储引擎的 API 来执行查询
  5. 返回结果给客户端
客户端/服务器通信协议

通过抓包软件分析,可以看到 MySQL 客户端和服务器之间是通过 TCP 和 mysql 协议进行通信的。具体细节这里就不讲了,我也没仔细看。目前我们只要大致理解通信协议是如何工作的就够了。

  • 通信协议是“半双工”的:任意一个时刻,要么是服务器向客户端发送数据,要么是客户端向服务器发送数据。无法进行流量控制,一旦一端开始发送消息,另一端要接受完整消息才能响应它。
  • max_allowed_packet 参数可以限制数据包的长度。
  • 服务器响应给用户的数据通常很多,由多个数据包组成。
  • 客户端接受数据一般是将全部结果集缓存到内存中。这样可以减少服务器的压力。
查询缓存

在解析查询语句之前,如果查询缓存是打开的,那么 MySQL 会优先检查这个查询是否命中查询缓存中的数据。没命中则走下一个阶段。命中了,在返回结果之前还会检查用户权限。如果权限没问题,则直接返回数据给客户端。这种情况下,查询不会被解析,不用生成执行计划,不会被执行。

查询优化处理

查询的生命周期下一步是将 SQL 转化成执行计划。然后再按照执行计划和存储引擎交互。这包括多个子阶段:解析 SQL,预处理,优化执行计划。一条查询可能有多种执行方式,最后都返回相同的结果。优化器的作用就是找到其中最好的执行计划。

查询执行引擎

存储引擎根据查询计划来完成查询。

返回结果给客户端

查询执行的最后一个阶段是返回结果给客户端。即使客户端不需要结果,也会返回这个查询的一些信息,如该查询影响到的行数。MySQL 将结果集返回给客户端是一个增量、逐步返回的过程。好处是服务器不需要缓存太多的结果,客户端也能第一时间获得返回的结果。

优化特定类型的查询

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

推荐阅读更多精彩内容