欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

深入分析MySQL Sending data查詢慢問題

 更新時間:2017年12月07日 16:56:59   投稿:laozhang  
給大家深入分析一下MySQL Sending data表查詢慢的問題,并給出了詳細的解決方案,一起來參考下。

通過一個實例給大家分享了MySQL Sending data表查詢慢問題解決辦法。

最近在代碼優(yōu)化中,發(fā)現(xiàn)了一條sql語句非常的慢,于是就用各種方法進行排查,最后終于找到了原因。

一、事故現(xiàn)場

SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
GROUP BY og.color_id, og.size_id

上面的這條語句是一個聯(lián)表分組查詢語句。

執(zhí)行結(jié)果:

我們可以看到,這條語句用了 1.300 秒, 而 Sending data 就用了 1.28 秒,占用了將近 99% 的時間,所以,我們對這個進行優(yōu)化。

怎么優(yōu)化呢?

二、SQL語句分析三板斧

1、explain分析

對上邊的語句進行 explain 分析:

explain SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
GROUP BY og.color_id, og.size_id

執(zhí)行結(jié)果:

通過explain, 我們可以看到上邊的語句,有用到索引key。

2、show processlist

explain看不出問題,那到底慢在哪里呢?

于是想到了使用 show processlist 查看sql語句執(zhí)行狀態(tài),查詢結(jié)果如下:

發(fā)現(xiàn)很長一段時間,查詢都處在 “Sending data”狀態(tài)

查詢一下“Sending data”狀態(tài)的含義,原來這個狀態(tài)的名稱很具有誤導性,所謂的“Sending data”并不是單純的發(fā)送數(shù)據(jù),而是包括“收集 + 發(fā)送 數(shù)據(jù)”。

這里的關鍵是為什么要收集數(shù)據(jù),原因在于:mysql使用“索引”完成查詢結(jié)束后,mysql得到了一堆的行id,如果有的列并不在索引中,mysql需要重新到“數(shù)據(jù)行”上將需要返回的數(shù)據(jù)讀取出來返回個客戶端。

3、show profile

為了進一步驗證查詢的時間分布,于是使用了 show profile 命令來查看詳細的時間分布

首先打開配置:set profiling=on;

執(zhí)行完查詢后,使用show profiles查看query id;

使用show profile for query query_id查看詳細信息;

三、排查優(yōu)化

1.排查對比

經(jīng)過以上步驟,已經(jīng)確定查詢慢是因為大量的時間耗費在了Sending data狀態(tài)上,結(jié)合Sending data的定義,將目標聚焦在查詢語句的返回列上面

經(jīng)過一 一排查,最后定為到一個description的列上,這個列的設計為:descriptionvarchar(8000) DEFAULT NULL COMMENT '游戲描述',

于是采取了對比的方法,看看“不返回description的結(jié)果”如何。show profile的結(jié)果如下:

【解決方法】

找到了問題的根本原因,解決方法也就不難了。有幾種方法:

1)查詢時去掉description的查詢,但這受限于業(yè)務的實現(xiàn),可能需要業(yè)務做較大調(diào)整

2)表結(jié)構(gòu)優(yōu)化,將descripion拆分到另外的表,這個改動較大,需要已有業(yè)務配合修改,且如果業(yè)務還是要繼續(xù)查詢這個description的信息,則優(yōu)化后的性能也不會有很大提升。

相關文章

  • MySQL不就是多表查詢嗎

    MySQL不就是多表查詢嗎

    這篇文章主要介紹了MySQL多表查詢相關知識,今天我們學習要對多張表進行相關操作,相比較于單一的表來說,多張表操作相對復雜一些,本文給大家介紹的非常詳細,需要的朋友可以參考下
    2023-06-06
  • Ubuntu 18.04安裝mysql 5.7.23

    Ubuntu 18.04安裝mysql 5.7.23

    這篇文章主要為大家詳細介紹了Ubuntu 18.04安裝mysql 5.7.23的相關資料,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2019-02-02
  • CenOS6.7下mysql 8.0.22 安裝配置方法圖文教程

    CenOS6.7下mysql 8.0.22 安裝配置方法圖文教程

    這篇文章主要為大家詳細介紹了CenOS6.7下mysql 8.0.22 安裝配置方法圖文教程,文中安裝步驟介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2020-11-11
  • MySQL數(shù)據(jù)庫之存儲過程?procedure

    MySQL數(shù)據(jù)庫之存儲過程?procedure

    這篇文章主要介紹了MySQL數(shù)據(jù)庫之存儲過程?procedure,文章圍繞主題展開詳細的內(nèi)容介紹,具有一定的參考價值,感興趣的小伙伴可以參考一下
    2022-06-06
  • 一文詳解MySQL的并發(fā)控制

    一文詳解MySQL的并發(fā)控制

    無論何時只要有多個查詢需要在同一時刻修改數(shù)據(jù),都會產(chǎn)生并發(fā)控制問題,MySQL可以在兩個層面進行并發(fā)控制,服務器層和存儲引擎層,下面這篇文章主要給大家介紹了關于MySQL并發(fā)控制的相關資料,需要的朋友可以參考下
    2023-05-05
  • 庫名表名大小寫問題與sqlserver兼容的啟動配置方法

    庫名表名大小寫問題與sqlserver兼容的啟動配置方法

    庫名表名大小寫問題與sqlserver兼容的啟動配置方法,需要的朋友可以參考下。
    2010-12-12
  • MySQL存儲引擎總結(jié)

    MySQL存儲引擎總結(jié)

    這篇文章主要介紹了MySQL存儲引擎總結(jié),本文講解了什么是存儲引擎、MyISAM、InnoDB、MEMORY、MERGE等內(nèi)容,需要的朋友可以參考下
    2014-09-09
  • 解決centos下MySQL登錄1045問題

    解決centos下MySQL登錄1045問題

    這篇文章主要介紹了解決centos下MySQL登錄1045問題,本文給大家介紹的非常詳細,具有一定的參考借鑒價值,需要的朋友可以參考下
    2020-01-01
  • mysql創(chuàng)建表設置表主鍵id從1開始自增的解決方案

    mysql創(chuàng)建表設置表主鍵id從1開始自增的解決方案

    在MySQL中用很多類型的自增ID,每個自增ID都設置了初始值,一般情況下初始值都是從0開始,然后按照一定的步長增加(一般是自增 1),下面這篇文章主要給大家介紹了關于mysql創(chuàng)建表設置表主鍵id從1開始自增的解決方案,需要的朋友可以參考下
    2023-04-04
  • MySQL主從復制搭建流程分步實現(xiàn)

    MySQL主從復制搭建流程分步實現(xiàn)

    這篇文章主要介紹了MySQL的主從復制原理詳細分析,讀寫分離是基于主從復制來實現(xiàn)的。文章圍繞主題展開詳細的內(nèi)容介紹,具有一定的參考價值,需要的小伙伴可以參考一下
    2022-11-11

最新評論