<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          是怎么樣的SQL優(yōu)化能做到 900W+數(shù)據(jù),從17s到300ms?

          共 6275字,需瀏覽 13分鐘

           ·

          2022-01-15 19:39

          往期熱門文章:

          1、RedisJson發(fā)布官方性能報告,性能碾壓ES和Mongo
          2、分布式數(shù)據(jù)一致性思考-B端系統(tǒng)一致性
          3、Java字符串拼接的五種方法,哪種性能最好?
          4、一次線上JVM調(diào)優(yōu)實踐,F(xiàn)ullGC40次/天到10天一次的優(yōu)化過程
          5、Chrome 瀏覽器全球大翻車?讓 20 多億用戶無網(wǎng)可上

          作者: Muscleape
          來源: jianshu.com/p/0768ebc4e28d

          有一張財務(wù)流水表,未分庫分表,目前的數(shù)據(jù)量為9555695,分頁查詢使用到了limit,優(yōu)化之前的查詢耗時16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms),按照下文的方式調(diào)整SQL后,耗時347 ms (execution: 163 ms, fetching: 184 ms);
          操作: 查詢條件放到子查詢中,子查詢只查主鍵ID,然后使用子查詢中確定的主鍵關(guān)聯(lián)查詢其他的屬性字段;
          原理:
          1. 減少回表操作;
          2. 可參考《阿里巴巴Java開發(fā)手冊(泰山版)》第五章-MySQL數(shù)據(jù)庫、(二)索引規(guī)約、第7條:
          【推薦】利用延遲關(guān)聯(lián)或者子查詢優(yōu)化超多分頁場景。
          說明:MySQL并不是挑過offeset行,而是取offset+N行,然后返回放棄前offset行,返回N行,那當(dāng)offset特別大的時候,效率就非常的底下,要么控制返回的總頁數(shù),要么對超過特定閾值的頁數(shù)進(jìn)行SQL改寫。
          正例:先快速定位需要獲取的id段,然后再關(guān)聯(lián):
          SELECT a.* FROM 表1 a,(select id from 表1 where 條件 LIMIT 100000,20) b where a.id = b.id;
          --?優(yōu)化前SQL
          SELECT??各種字段
          FROM?`table_name`
          WHERE?各種條件
          LIMIT?0,10;
          --?優(yōu)化后SQL
          SELECT??各種字段
          FROM?`table_name`?main_tale
          RIGHT?JOIN?
          (
          SELECT??子查詢只查主鍵
          FROM?`table_name`
          WHERE?各種條件
          LIMIT?0,10;
          )?temp_table?ON?temp_table.主鍵?=?main_table.主鍵

          Part1前言

          首先說明一下MySQL的版本:
          mysql>?select?version();
          +-----------+
          |?version()?|
          +-----------+
          |?5.7.17????|
          +-----------+
          1?row?in?set?(0.00?sec)
          表結(jié)構(gòu):
          mysql>?desc?test;
          +--------+---------------------+------+-----+---------+----------------+
          |?Field??|?Type????????????????|?Null?|?Key?|?Default?|?Extra??????????|
          +--------+---------------------+------+-----+---------+----------------+
          |?id?????|?bigint(20)?unsigned?|?NO???|?PRI?|?NULL????|?auto_increment?|
          |?val????|?int(10)?unsigned????|?NO???|?MUL?|?0???????|????????????????|
          |?source?|?int(10)?unsigned????|?NO???|?????|?0???????|????????????????|
          +--------+---------------------+------+-----+---------+----------------+
          3?rows?in?set?(0.00?sec)
          id為自增主鍵,val為非唯一索引。
          灌入大量數(shù)據(jù),共500萬:
          mysql>?select?count(*)?from?test;
          +----------+
          |?count(*)?|
          +----------+
          |??5242882?|
          +----------+
          1?row?in?set?(4.25?sec)
          我們知道,當(dāng)limit offset rows中的offset很大時,會出現(xiàn)效率問題:
          mysql>?select?*?from?test?where?val=4?limit?300000,5;
          +---------+-----+--------+
          |?id??????|?val?|?source?|
          +---------+-----+--------+
          |?3327622?|???4?|??????4?|
          |?3327632?|???4?|??????4?|
          |?3327642?|???4?|??????4?|
          |?3327652?|???4?|??????4?|
          |?3327662?|???4?|??????4?|
          +---------+-----+--------+
          5?rows?in?set?(15.98?sec)
          為了達(dá)到相同的目的,我們一般會改寫成如下語句:
          mysql>?select?*?from?test?a?inner?join?(select?id?from?test?where?val=4?limit?300000,5)?b?on?a.id=b.id;
          +---------+-----+--------+---------+
          |?id??????|?val?|?source?|?id??????|
          +---------+-----+--------+---------+
          |?3327622?|???4?|??????4?|?3327622?|
          |?3327632?|???4?|??????4?|?3327632?|
          |?3327642?|???4?|??????4?|?3327642?|
          |?3327652?|???4?|??????4?|?3327652?|
          |?3327662?|???4?|??????4?|?3327662?|
          +---------+-----+--------+---------+
          5?rows?in?set?(0.38?sec)
          時間相差很明顯。
          為什么會出現(xiàn)上面的結(jié)果?我們看一下select * from test where val=4 limit 300000,5;的查詢過程:
          查詢到索引葉子節(jié)點數(shù)據(jù)。
          根據(jù)葉子節(jié)點上的主鍵值去聚簇索引上查詢需要的全部字段值。
          類似于下面這張圖:
          像上面這樣,需要查詢300005次索引節(jié)點,查詢300005次聚簇索引的數(shù)據(jù),最后再將結(jié)果過濾掉前300000條,取出最后5條。MySQL耗費了大量隨機(jī)I/O在查詢聚簇索引的數(shù)據(jù)上,而有300000次隨機(jī)I/O查詢到的數(shù)據(jù)是不會出現(xiàn)在結(jié)果集當(dāng)中的。
          肯定會有人問:既然一開始是利用索引的,為什么不先沿著索引葉子節(jié)點查詢到最后需要的5個節(jié)點,然后再去聚簇索引中查詢實際數(shù)據(jù)。這樣只需要5次隨機(jī)I/O,類似于下面圖片的過程:
          其實我也想問這個問題。

          Part2證實

          下面我們實際操作一下來證實上述的推論:
          為了證實select * from test where val=4 limit 300000,5是掃描300005個索引節(jié)點和300005個聚簇索引上的數(shù)據(jù)節(jié)點,我們需要知道MySQL有沒有辦法統(tǒng)計在一個sql中通過索引節(jié)點查詢數(shù)據(jù)節(jié)點的次數(shù)。我先試了Handler_read_*系列,很遺憾沒有一個變量能滿足條件。
          我只能通過間接的方式來證實:
          InnoDB中有buffer pool。里面存有最近訪問過的數(shù)據(jù)頁,包括數(shù)據(jù)頁和索引頁。所以我們需要運(yùn)行兩個sql,來比較buffer pool中的數(shù)據(jù)頁的數(shù)量。預(yù)測結(jié)果是運(yùn)行select * from test a inner join (select id from test where val=4 limit 300000,5); 之后,buffer pool中的數(shù)據(jù)頁的數(shù)量遠(yuǎn)遠(yuǎn)少于select * from test where val=4 limit 300000,5;對應(yīng)的數(shù)量,因為前一個sql只訪問5次數(shù)據(jù)頁,而后一個sql訪問300005次數(shù)據(jù)頁。
          select * from test where val=4 limit 300000,5
          mysql>?select?index_name,count(*)?from?information_schema.INNODB_BUFFER_PAGE?where?INDEX_NAME?in('val','primary')?and?TABLE_NAME?like?'%test%'?group?by?index_name;Empty?set?(0.04?sec)
          可以看出,目前buffer pool中沒有關(guān)于test表的數(shù)據(jù)頁。
          mysql>?select?*?from?test?where?val=4?limit?300000,5;
          +---------+-----+--------+
          |?id??????|?val?|?source?|
          +---------+-----+--------+|?
          3327622?|
          ???4?|??????4?|
          |?3327632?|???4?|??????4?|
          |?3327642?|???4?|??????4?|
          |?3327652?|???4?|??????4?|
          |?3327662?|???4?|??????4?|
          +---------+-----+--------+
          5?rows?in?set?(26.19?sec)

          mysql>?select?index_name,count(*)?from?information_schema.INNODB_BUFFER_PAGE?where?INDEX_NAME?in('val','primary')?and?TABLE_NAME?like?'%test%'?group?by?index_name;
          +------------+----------+
          |?index_name?|?count(*)?|
          +------------+----------+
          |
          ?PRIMARY????|?????4098?|
          |?val????????|??????208?|
          +------------+----------+2?rows?in?set?(0.04?sec)
          可以看出,此時buffer pool中關(guān)于test表有4098個數(shù)據(jù)頁,208個索引頁。
          select * from test a inner join (select id from test where val=4 limit 300000,5) ;為了防止上次試驗的影響,我們需要清空buffer pool,重啟mysql。
          mysqladmin?shutdown
          /usr/local/bin/mysqld_safe?&
          mysql>?select?index_name,count(*)?from?information_schema.INNODB_BUFFER_PAGE?where?INDEX_NAME?in('val','primary')?and?TABLE_NAME?like?'%test%'?group?by?index_name;

          Empty?set?(0.03?sec)
          運(yùn)行sql:
          mysql>?select?*?from?test?a?inner?join?(select?id?from?test?where?val=4?limit?300000,5)?b?on?a.id=b.id;
          +---------+-----+--------+---------+
          |?id??????|?val?|?source?|?id??????|
          +---------+-----+--------+---------+
          |?3327622?|???4?|??????4?|?3327622?|
          |?3327632?|???4?|??????4?|?3327632?|
          |?3327642?|???4?|??????4?|?3327642?|
          |?3327652?|???4?|??????4?|?3327652?|
          |?3327662?|???4?|??????4?|?3327662?|
          +---------+-----+--------+---------+
          5?rows?in?set?(0.09?sec)

          mysql>?select?index_name,count(*)?from?information_schema.INNODB_BUFFER_PAGE?where?INDEX_NAME?in('val','primary')?and?TABLE_NAME?like?'%test%'?group?by?index_name;
          +------------+----------+
          |?index_name?|?count(*)?|
          +------------+----------+
          |?PRIMARY????|????????5?|
          |?val????????|??????390?|
          +------------+----------+
          2?rows?in?set?(0.03?sec)
          我們可以看明顯的看出兩者的差別:第一個sql加載了4098個數(shù)據(jù)頁到buffer pool,而第二個sql只加載了5個數(shù)據(jù)頁到buffer pool。符合我們的預(yù)測。也證實了為什么第一個sql會慢:讀取大量的無用數(shù)據(jù)行(300000),最后卻拋棄掉。
          而且這會造成一個問題:加載了很多熱點不是很高的數(shù)據(jù)頁到buffer pool,會造成buffer pool的污染,占用buffer pool的空間遇到的問題

          Part3

          為了在每次重啟時確保清空buffer pool,我們需要關(guān)閉innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup,這兩個選項能夠控制數(shù)據(jù)庫關(guān)閉時dump出buffer pool中的數(shù)據(jù)和在數(shù)據(jù)庫開啟時載入在磁盤上備份buffer pool的數(shù)據(jù)。

          最近熱文閱讀:

          1、RedisJson發(fā)布官方性能報告,性能碾壓ES和Mongo
          2、分布式數(shù)據(jù)一致性思考-B端系統(tǒng)一致性
          3、Java字符串拼接的五種方法,哪種性能最好?
          4、一次線上JVM調(diào)優(yōu)實踐,F(xiàn)ullGC40次/天到10天一次的優(yōu)化過程
          5、Chrome 瀏覽器全球大翻車?讓 20 多億用戶無網(wǎng)可上
          6、while(1) 和 for(;;)有什么區(qū)別?
          7、使用MySQL,請用好 JSON 這張牌!
          8、延時任務(wù)實現(xiàn)方案
          9、服務(wù)端如何防止重復(fù)支付
          10、五年工作經(jīng)驗總結(jié) 16 條的代碼規(guī)范
          關(guān)注公眾號,你想要的Java都在這里

          瀏覽 42
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  日韩婬乱片A片AAA真人视频 | 欧美黄色一级A片 | 免费一片A | 日韩视频在线播放 | 日韩欧美视频青青 |