欢乐颂小说,琅琊榜海宴小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案

SQL優(yōu)化13連問(wèn)，收藏好！

前言

大家好，我是田螺。

公司主營(yíng)業(yè)務(wù)：網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。創(chuàng)新互聯(lián)推出石河子免費(fèi)做網(wǎng)站回饋大家。

金三銀四已經(jīng)開(kāi)始啦，準(zhǔn)備了SQL優(yōu)化的13連問(wèn)，內(nèi)容非常干！相信大家看完一定會(huì)有幫助的。

1.日常工作中，你是怎么優(yōu)化SQL的？

大家可以從這幾個(gè)維度回答這個(gè)問(wèn)題：

分析慢查詢?nèi)罩?/li>
使用explain查看執(zhí)行計(jì)劃
索引優(yōu)化
深分頁(yè)優(yōu)化
避免全表掃描
避免返回不必要的數(shù)據(jù)（如select具體字段而不是select*）
使用合適的數(shù)據(jù)類(lèi)型（如可以使用int類(lèi)型的話，就不要設(shè)計(jì)為varchar）
優(yōu)化sql結(jié)構(gòu)（如join優(yōu)化等等）
適當(dāng)分批量進(jìn)行 (如批量更新、刪除)
定期清理無(wú)用的數(shù)據(jù)
適當(dāng)分庫(kù)分表
讀寫(xiě)分離

2. 是否遇到過(guò)深分頁(yè)問(wèn)題，如何解決

我們可以通過(guò)減少回表次數(shù)來(lái)優(yōu)化。一般有標(biāo)簽記錄法和延遲關(guān)聯(lián)法。

標(biāo)簽記錄法

就是標(biāo)記一下上次查詢到哪一條了，下次再來(lái)查的時(shí)候，從該條開(kāi)始往下掃描。就好像看書(shū)一樣，上次看到哪里了，你就折疊一下或者夾個(gè)書(shū)簽，下次來(lái)看的時(shí)候，直接就翻到啦。

假設(shè)上一次記錄到100000，則SQL可以修改為：

select  id,name,balance FROM account where id > 100000 limit 10;

這樣的話，后面無(wú)論翻多少頁(yè)，性能都會(huì)不錯(cuò)的，因?yàn)槊辛薸d索引。但是這種方式有局限性：需要一種類(lèi)似連續(xù)自增的字段。

延遲關(guān)聯(lián)法

延遲關(guān)聯(lián)法，就是把條件轉(zhuǎn)移到主鍵索引樹(shù)，然后減少回表。假設(shè)原生SQL是這樣的的，其中id是主鍵，create_time是普通索引

select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;

使用延遲關(guān)聯(lián)法優(yōu)化，如下：

select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN 
(SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) 
AS acct2 on acct1.id= acct2.id;

優(yōu)化思路就是，先通過(guò)idx_create_time二級(jí)索引樹(shù)查詢到滿足條件的主鍵ID，再與原表通過(guò)主鍵ID內(nèi)連接，這樣后面直接走了主鍵索引了，同時(shí)也減少了回表。

3. 聊聊explain執(zhí)行計(jì)劃

當(dāng)explain與SQL一起使用時(shí)，MySQL將顯示來(lái)自優(yōu)化器的有關(guān)語(yǔ)句執(zhí)行計(jì)劃的信息。即MySQL解釋了它將如何處理該語(yǔ)句，包括有關(guān)如何連接表以及以何種順序連接表等信息。

一條簡(jiǎn)單SQL，使用了explain的效果如下：

一般來(lái)說(shuō)，我們需要重點(diǎn)關(guān)注type、rows、filtered、extra、key。

3.1 type

type表示連接類(lèi)型，查看索引執(zhí)行情況的一個(gè)重要指標(biāo)。以下性能從好到壞依次：system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

system：這種類(lèi)型要求數(shù)據(jù)庫(kù)表中只有一條數(shù)據(jù)，是const類(lèi)型的一個(gè)特例，一般情況下是不會(huì)出現(xiàn)的。
const：通過(guò)一次索引就能找到數(shù)據(jù)，一般用于主鍵或唯一索引作為條件，這類(lèi)掃描效率極高，，速度非常快。
eq_ref：常用于主鍵或唯一索引掃描，一般指使用主鍵的關(guān)聯(lián)查詢
ref : 常用于非主鍵和唯一索引掃描。
ref_or_null：這種連接類(lèi)型類(lèi)似于ref，區(qū)別在于MySQL會(huì)額外搜索包含NULL值的行
index_merge：使用了索引合并優(yōu)化方法，查詢使用了兩個(gè)以上的索引。
unique_subquery：類(lèi)似于eq_ref，條件用了in子查詢
index_subquery：區(qū)別于unique_subquery，用于非唯一索引，可以返回重復(fù)值。
range：常用于范圍查詢，比如：between ... and 或 In 等操作
index：全索引掃描
ALL：全表掃描

3.2 rows

該列表示MySQL估算要找到我們所需的記錄，需要讀取的行數(shù)。對(duì)于InnoDB表，此數(shù)字是估計(jì)值，并非一定是個(gè)準(zhǔn)確值。

3.3 filtered

該列是一個(gè)百分比的值，表里符合條件的記錄數(shù)的百分比。簡(jiǎn)單點(diǎn)說(shuō)，這個(gè)字段表示存儲(chǔ)引擎返回的數(shù)據(jù)在經(jīng)過(guò)過(guò)濾后，剩下滿足條件的記錄數(shù)量的比例。

3.4 extra

該字段包含有關(guān)MySQL如何解析查詢的其他信息，它一般會(huì)出現(xiàn)這幾個(gè)值：

Using filesort：表示按文件排序，一般是在指定的排序和索引排序不一致的情況才會(huì)出現(xiàn)。一般見(jiàn)于order by語(yǔ)句
Using index ：表示是否用了覆蓋索引。
Using temporary: 表示是否使用了臨時(shí)表,性能特別差，需要重點(diǎn)優(yōu)化。一般多見(jiàn)于group by語(yǔ)句，或者union語(yǔ)句。
Using where : 表示使用了where條件過(guò)濾.
Using index condition：MySQL5.6之后新增的索引下推。在存儲(chǔ)引擎層進(jìn)行數(shù)據(jù)過(guò)濾，而不是在服務(wù)層過(guò)濾，利用索引現(xiàn)有的數(shù)據(jù)減少回表的數(shù)據(jù)。

3.5 key

該列表示實(shí)際用到的索引。一般配合possible_keys列一起看。

注意:有時(shí)候，explain配合show WARNINGS; （可以查看優(yōu)化后,最終執(zhí)行的sql），效果更佳哦。

4.說(shuō)說(shuō)大表的優(yōu)化方案

數(shù)據(jù)庫(kù)設(shè)計(jì)優(yōu)化

合理的數(shù)據(jù)庫(kù)設(shè)計(jì)可以極大地提高查詢效率。我們?cè)谠O(shè)計(jì)大表時(shí)，可以考慮拆分表、使用分區(qū)表、添加索引等方式來(lái)優(yōu)化表結(jié)構(gòu)。同時(shí)也要避免使用大量冗余字段、避免頻繁使用join查詢等操作。

索引優(yōu)化

對(duì)于大表的查詢操作，索引優(yōu)化是非常重要的一環(huán)?？梢钥紤]增加或者修改索引、使用覆蓋索引、使用聯(lián)合索引等方式來(lái)提高查詢效率。同時(shí)也要注意定期清理冗余的索引以及對(duì)于經(jīng)常使用的查詢語(yǔ)句建立索引。

分區(qū)優(yōu)化

將大表按照某個(gè)列分成多個(gè)分區(qū)表，每個(gè)分區(qū)表的數(shù)據(jù)量較小，可以提高查詢和更新的性能。分區(qū)表還可以幫助在維護(hù)表結(jié)構(gòu)的同時(shí)，減少鎖表時(shí)間，提高并發(fā)處理能力。

數(shù)據(jù)清理歸檔

對(duì)于一些歷史數(shù)據(jù)或者無(wú)用數(shù)據(jù)，可以進(jìn)行定期歸檔，避免數(shù)據(jù)過(guò)多造成SQL查詢效率降低。同時(shí)也要注意對(duì)于大表進(jìn)行定期的數(shù)據(jù)備份以及緊急數(shù)據(jù)恢復(fù)的準(zhǔn)備工作。

緩存優(yōu)化

對(duì)于一些經(jīng)常被查詢的數(shù)據(jù)，可以使用緩存優(yōu)化。使用Redis等緩存中間件來(lái)緩存常用的數(shù)據(jù)，以減少查詢數(shù)據(jù)庫(kù)的次數(shù)，提高查詢效率。

SQL語(yǔ)句優(yōu)化

在編寫(xiě)SQL查詢語(yǔ)句時(shí)，要盡可能地簡(jiǎn)單明了，避免復(fù)雜的查詢語(yǔ)句，同時(shí)也要避免一些不必要的查詢操作。對(duì)于復(fù)雜的查詢語(yǔ)句，可以使用Explain執(zhí)行計(jì)劃來(lái)進(jìn)行優(yōu)化。同時(shí)也要注意避免使用OR等耗費(fèi)性能的操作符。

分庫(kù)分表

如果數(shù)據(jù)量千萬(wàn)級(jí)別，需要考慮分庫(kù)分表哈。分庫(kù)分表相關(guān)知識(shí)點(diǎn)，可以看我之前這篇文章哈，我們?yōu)槭裁匆謳?kù)分表？

5.哪些因素可能導(dǎo)致MySQL慢查詢？

慢查詢一般有以下這些原因：

大家有興趣可以看下。我之前寫(xiě)的這篇文章哈：盤(pán)點(diǎn)MySQL慢查詢的12個(gè)原因

6.如何使用索引優(yōu)化SQL查詢？

添加合適索引（在where、group by、order by等后面的字段添加合適索引）
選擇合適的索引類(lèi)型 (B-tree索引適合范圍查詢、哈希索引適合等值查詢)
注意不適合加索引的場(chǎng)景（數(shù)據(jù)量少的表，更新頻繁的字段，區(qū)分度低的字段）
加索引的時(shí)候，需要考慮覆蓋索引，減少回表，考慮聯(lián)合索引的最左前綴原則
explain查看SQL的執(zhí)行計(jì)劃，確認(rèn)是否會(huì)命中索引。
注意索引并不是越多越好，通常建議在單個(gè)表中不要超過(guò)5個(gè)索引。因?yàn)樗饕龝?huì)占用磁盤(pán)空間，索引更新代價(jià)高。

7.聊聊慢SQL的優(yōu)化思路

查看慢查詢?nèi)罩居涗?，分析慢SQL
explain分析SQL的執(zhí)行計(jì)劃
profile 分析執(zhí)行耗時(shí)
Optimizer Trace分析詳情
確定問(wèn)題并采用相應(yīng)的措施

7.1 查看慢查詢?nèi)罩居涗洠治雎齋QL

如何定位慢SQL呢、我們可以通過(guò)slow log來(lái)查看慢SQL。默認(rèn)的情況下呢，MySQL數(shù)據(jù)庫(kù)是不開(kāi)啟慢查詢?nèi)罩荆╯low query log）呢。所以我們需要手動(dòng)把它打開(kāi)。

查看下慢查詢?nèi)罩九渲茫覀兛梢允褂胹how variables like 'slow_query_log%'命令，如下：

slow query log表示慢查詢開(kāi)啟的狀態(tài)
slow_query_log_file表示慢查詢?nèi)罩敬娣诺奈恢?/li>

我們還可以使用show variables like 'long_query_time'命令，查看超過(guò)多少時(shí)間，才記錄到慢查詢?nèi)罩?，如下?/p>

long_query_time表示查詢超過(guò)多少秒才記錄到慢查詢?nèi)罩尽?/li>

我們可以通過(guò)慢查日志，定位那些執(zhí)行效率較低的SQL語(yǔ)句，重點(diǎn)關(guān)注分析。

7.2 explain查看分析SQL的執(zhí)行計(jì)劃

當(dāng)定位出查詢效率低的SQL后，可以使用explain查看SQL的執(zhí)行計(jì)劃。

一條簡(jiǎn)單SQL，使用了explain的效果如下：

一般來(lái)說(shuō)，我們需要重點(diǎn)關(guān)注type、rows、filtered、extra、key。

7.3 profile 分析執(zhí)行耗時(shí)

explain只是看到SQL的預(yù)估執(zhí)行計(jì)劃，如果要了解SQL真正的執(zhí)行線程狀態(tài)及消耗的時(shí)間，需要使用profiling。開(kāi)啟profiling參數(shù)后，后續(xù)執(zhí)行的SQL語(yǔ)句都會(huì)記錄其資源開(kāi)銷(xiāo)，包括IO，上下文切換，CPU，內(nèi)存等等，我們可以根據(jù)這些開(kāi)銷(xiāo)進(jìn)一步分析當(dāng)前慢SQL的瓶頸再進(jìn)一步進(jìn)行優(yōu)化。

profiling默認(rèn)是關(guān)閉，我們可以使用show variables like '%profil%'查看是否開(kāi)啟，如下：

可以使用set profiling=ON開(kāi)啟。開(kāi)啟后，可以運(yùn)行幾條SQL，然后使用show profiles查看一下。

show profiles會(huì)顯示最近發(fā)給服務(wù)器的多條語(yǔ)句，條數(shù)由變量profiling_history_size定義，默認(rèn)是15。如果我們需要看單獨(dú)某條SQL的分析，可以show profile查看最近一條SQL的分析。也可以使用show profile for query id（其中id就是show profiles中的QUERY_ID）查看具體一條的SQL語(yǔ)句分析。

除了查看profile ，還可以查看cpu和io，如上圖。

7.4 Optimizer Trace分析詳情

profile只能查看到SQL的執(zhí)行耗時(shí)，但是無(wú)法看到SQL真正執(zhí)行的過(guò)程信息，即不知道MySQL優(yōu)化器是如何選擇執(zhí)行計(jì)劃。這時(shí)候，我們可以使用Optimizer Trace，它可以跟蹤執(zhí)行語(yǔ)句的解析優(yōu)化執(zhí)行的全過(guò)程。

我們可以使用set optimizer_trace="enabled=on"打開(kāi)開(kāi)關(guān)，接著執(zhí)行要跟蹤的SQL，最后執(zhí)行select * from information_schema.optimizer_trace跟蹤，如下：

大家可以查看分析其執(zhí)行樹(shù)，會(huì)包括三個(gè)階段：

join_preparation：準(zhǔn)備階段
join_optimization：分析階段
join_execution：執(zhí)行階段

7.5 確定問(wèn)題并采用相應(yīng)的措施

最后確認(rèn)問(wèn)題，就采取對(duì)應(yīng)的措施。

多數(shù)慢SQL都跟索引有關(guān)，比如不加索引，索引不生效、不合理等，這時(shí)候，我們可以優(yōu)化索引。
我們還可以優(yōu)化SQL語(yǔ)句，比如一些in元素過(guò)多問(wèn)題（分批），深分頁(yè)問(wèn)題（基于上一次數(shù)據(jù)過(guò)濾等），進(jìn)行時(shí)間分段查詢
SQl沒(méi)辦法很好優(yōu)化，可以改用ES的方式，或者數(shù)倉(cāng)。
如果單表數(shù)據(jù)量過(guò)大導(dǎo)致慢查詢，則可以考慮分庫(kù)分表
如果數(shù)據(jù)庫(kù)在刷臟頁(yè)導(dǎo)致慢查詢，考慮是否可以優(yōu)化一些參數(shù)，跟DBA討論優(yōu)化方案
如果存量數(shù)據(jù)量太大，考慮是否可以讓部分?jǐn)?shù)據(jù)歸檔

我之前寫(xiě)了一篇文章，有關(guān)于導(dǎo)致慢查詢的12個(gè)原因，大家看一下哈:盤(pán)點(diǎn)MySQL慢查詢的12個(gè)原因

8.一條sql執(zhí)行過(guò)長(zhǎng)的時(shí)間，你如何優(yōu)化，從哪些方面入手？

這道面試題，其實(shí)跟慢SQl排查解決有點(diǎn)像，所以大家回答得時(shí)候，可以參考上一小節(jié)哈。我們可以從這幾個(gè)方面入手哈：

確定瓶頸
索引優(yōu)化
優(yōu)化SQL語(yǔ)句
數(shù)據(jù)庫(kù)參數(shù)優(yōu)化
分析鎖的情況
數(shù)據(jù)庫(kù)硬件升級(jí)

確定瓶頸

首先，通過(guò)查看MySQL日志，慢查詢?nèi)罩?，explain分析SQL的執(zhí)行計(jì)劃，profile 分析執(zhí)行耗時(shí)，Optimizer Trace分析詳情等操作，確定查詢執(zhí)行的瓶頸在哪里。只有確定了瓶頸，才能有針對(duì)性地進(jìn)行優(yōu)化。

索引優(yōu)化

在確定了瓶頸之后，可以考慮通過(guò)增加索引來(lái)優(yōu)化查詢效率?？梢愿鶕?jù)查詢語(yǔ)句的條件，增加相應(yīng)的索引，從而加快查詢速度。但是索引也會(huì)帶來(lái)一些負(fù)面影響，如占用磁盤(pán)空間，降低寫(xiě)入效率等，所以需要根據(jù)具體情況權(quán)衡。

優(yōu)化SQL語(yǔ)句

有些SQL語(yǔ)句本身可能存在一些問(wèn)題，如join操作過(guò)于頻繁，使用了不必要的子查詢等，這些都會(huì)導(dǎo)致查詢效率低下?？梢酝ㄟ^(guò)優(yōu)化SQL語(yǔ)句來(lái)減少不必要的操作，從而提高查詢效率。

數(shù)據(jù)庫(kù)參數(shù)優(yōu)化

數(shù)據(jù)庫(kù)參數(shù)也會(huì)影響查詢效率，可以通過(guò)修改數(shù)據(jù)庫(kù)參數(shù)來(lái)優(yōu)化查詢效率，如修改內(nèi)存緩存大小、修改連接池大小等。不同的數(shù)據(jù)庫(kù)參數(shù)優(yōu)化方式不同，需要根據(jù)具體情況進(jìn)行調(diào)整。

分析鎖的情況

查詢執(zhí)行時(shí)間過(guò)長(zhǎng)有可能是由于鎖的問(wèn)題導(dǎo)致的，需要分析查詢語(yǔ)句中是否存在鎖的問(wèn)題，如果存在鎖的問(wèn)題，可以考慮增加鎖的并發(fā)度，從而提高查詢效率。

數(shù)據(jù)庫(kù)硬件升級(jí)

如果以上方法都無(wú)法解決問(wèn)題，可以考慮對(duì)數(shù)據(jù)庫(kù)硬件進(jìn)行升級(jí)，如增加 CPU 數(shù)量、加快磁盤(pán)讀寫(xiě)速度等，從而提高數(shù)據(jù)庫(kù)的整體性能。

9. 列舉一下，常用的數(shù)據(jù)庫(kù)設(shè)計(jì)優(yōu)化技巧？

字段盡量避免使用NULL
合理選擇數(shù)據(jù)類(lèi)型
字段選擇合適的長(zhǎng)度
正確使用索引
盡量少定義text類(lèi)型
合理的數(shù)據(jù)表結(jié)構(gòu)設(shè)計(jì)
適當(dāng)?shù)娜哂嘣O(shè)計(jì)
優(yōu)化SQL查詢語(yǔ)句
一張表的字段不宜過(guò)多

10.列舉日常開(kāi)發(fā)中，列舉十個(gè)書(shū)寫(xiě)高質(zhì)量SQL的小技巧

查詢SQL盡量不要使用select *，而是select具體字段。
小表驅(qū)動(dòng)大表
優(yōu)化你的like語(yǔ)句
盡量避免在索引列上使用mysql的內(nèi)置函數(shù)
如果插入數(shù)據(jù)過(guò)多，考慮批量操作。
多用limit
小表驅(qū)動(dòng)大表
exist & in合理利用
in元素不要過(guò)多
盡量用union all替換union

大家可以參考我之前這篇文章哈：后端程序員必備：書(shū)寫(xiě)高質(zhì)量SQL的30條建議

11.index merge了解過(guò)嘛？

index merge是什么？

在MySQL中，當(dāng)執(zhí)行一個(gè)查詢語(yǔ)句需要使用多個(gè)索引時(shí)，MySQL可以使用索引合并(Index Merge)來(lái)優(yōu)化查詢性能。具體來(lái)說(shuō)，索引合并是將多個(gè)單列索引或多個(gè)聯(lián)合索引合并使用，以滿足查詢語(yǔ)句的需要。

當(dāng)使用索引合并時(shí)，MySQL會(huì)選擇最優(yōu)的索引組合來(lái)執(zhí)行查詢，從而避免了全表掃描和排序操作，提高了查詢效率。而對(duì)于使用多個(gè)單列索引的查詢語(yǔ)句，MySQL也可以使用索引合并來(lái)優(yōu)化查詢性能。

大家可以看一個(gè)使用index merge的例子：

假設(shè)有一個(gè)名為orders的表，包含order_id、customer_id、product_id、order_date等字段，其中order_id、customer_id、product_id三個(gè)字段都建有索引。

如果要查詢customer_id為1，order_date在2022年1月1日到2022年2月1日之間的訂單記錄，可以使用以下SQL語(yǔ)句：

SELECT *
FROM orders
WHERE customer_id = 1
AND order_date >= '2022-01-01'
AND order_date < '2022-02-01'

在執(zhí)行該查詢語(yǔ)句時(shí)，MySQL可以使用customer_id索引和order_date索引來(lái)優(yōu)化查詢。如果使用單個(gè)索引，則需要掃描整個(gè)索引樹(shù)來(lái)匹配查詢條件；但如果使用索引合并，則可以先使用customer_id索引來(lái)過(guò)濾出符合條件的記錄，然后再使用order_date索引來(lái)進(jìn)一步過(guò)濾記錄，從而大大減少了掃描的記錄數(shù)，提高了查詢效率。

大家可以使用EXPLAIN關(guān)鍵字可以查看查詢計(jì)劃，確認(rèn)是否使用了索引合并。例如，執(zhí)行以下語(yǔ)句：

EXPLAIN SELECT *
FROM orders
WHERE customer_id = 1
AND order_date >= '2022-01-01'
AND order_date < '2022-02-01'

如果查詢計(jì)劃中出現(xiàn)了Using index merge的信息，則表示該查詢使用了索引合并優(yōu)化。

12. order by查詢效率慢,如何優(yōu)化.

大家是否還記得order by查詢?yōu)槭裁磿?huì)慢嘛?

order by排序，分為全字段排序和rowid排序。它是拿max_length_for_sort_data和結(jié)果行數(shù)據(jù)長(zhǎng)度對(duì)比，如果結(jié)果行數(shù)據(jù)長(zhǎng)度超過(guò)max_length_for_sort_data這個(gè)值，就會(huì)走rowid排序，相反，則走全字段排序。

rowid排序，一般需要回表去找滿足條件的數(shù)據(jù)，所以效率會(huì)慢一點(diǎn).如果是order by排序,可能會(huì)借助磁盤(pán)文件排序的話，效率就更慢一點(diǎn).

如何優(yōu)化order by的文件排序?

因?yàn)閿?shù)據(jù)是無(wú)序的，所以就需要排序。如果數(shù)據(jù)本身是有序的，那就不會(huì)再用到文件排序啦。而索引數(shù)據(jù)本身是有序的，我們通過(guò)建立索引來(lái)優(yōu)化order by語(yǔ)句。
我們還可以通過(guò)調(diào)整max_length_for_sort_data、sort_buffer_size等參數(shù)優(yōu)化；

大家忘記order by的話,可以看我之前的這篇文章哈:看一遍就理解：order by詳解

13. group by 查詢慢的話,如何優(yōu)化呀.

group by一般用于分組統(tǒng)計(jì)，它表達(dá)的邏輯就是根據(jù)一定的規(guī)則，進(jìn)行分組。日常開(kāi)發(fā)中，我們使用得比較頻繁。如果不注意，很容易產(chǎn)生慢SQL。

group by可能會(huì)慢在哪里？因?yàn)樗扔玫脚R時(shí)表，又默認(rèn)用到排序。有時(shí)候還可能用到磁盤(pán)臨時(shí)表。

如果執(zhí)行過(guò)程中，會(huì)發(fā)現(xiàn)內(nèi)存臨時(shí)表大小到達(dá)了上限（控制這個(gè)上限的參數(shù)就是tmp_table_size），會(huì)把內(nèi)存臨時(shí)表轉(zhuǎn)成磁盤(pán)臨時(shí)表。
如果數(shù)據(jù)量很大，很可能這個(gè)查詢需要的磁盤(pán)臨時(shí)表，就會(huì)占用大量的磁盤(pán)空間。

如何優(yōu)化group by呢?

group by 后面的字段加索引
order by null 不用排序
盡量只使用內(nèi)存臨時(shí)表
使用SQL_BIG_RESULT

大家可以看下我這篇文章哈：看一遍就理解：group by詳解

本文轉(zhuǎn)載自微信公眾號(hào)「撿田螺的小男孩」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系撿田螺的小男孩公眾號(hào)。

本文題目：SQL優(yōu)化13連問(wèn)，收藏好！
文章網(wǎng)址：http://fisionsoft.com.cn/article/dppjehp.html