作者1：慘綠少年

https://www.cnblogs.com/clsn/p/8214048.html

作者2:喜歡拿鐵的人

在進行MySQL的最佳化之前，必須要了解的就是MySQL的查詢過程，很多查詢最佳化工作實際上就是遵循一些原則，讓MySQL的最佳化器能夠按照預想的合理方式執行而已。

史上最全SQL最佳化方案

圖-MySQL查詢過程

1 最佳化的哲學

注：最佳化有風險，涉足需謹慎

a 最佳化可能帶來的問題？

最佳化不總是對一個單純的環境進行，還很可能是一個複雜的已投產的系統；
最佳化手段本來就有很大的風險，只不過你沒能力意識到和預見到；
任何的技術可以解決一個問題，但必然存在帶來一個問題的風險；
對於最佳化來說解決問題而帶來的問題，控制在可接受的範圍內才是有成果；
保持現狀或出現更差的情況都是失敗！

b 最佳化的需求？

穩定性和業務可持續性，通常比效能更重要；
最佳化不可避免涉及到變更，變更就有風險；
最佳化使效能變好，維持和變差是等機率事件；
切記最佳化，應該是各部門協同，共同參與的工作，任何單一部門都不能對資料庫進行最佳化！

所以最佳化工作，是由業務需要驅使的！

c 最佳化由誰參與？

在進行資料庫最佳化時，應由資料庫管理員、業務部門代表、應用程式架構師、應用程式設計人員、應用程式開發人員、硬體及系統管理員、儲存管理員等，業務相關人員共同參與。

2 最佳化思路

a 最佳化什麼？

在資料庫最佳化上有兩個主要方面：即安全與效能。

安全->資料可持續性；
效能->資料的高效能訪問。

b 最佳化的範圍有哪些？

儲存、主機和作業系統方面：

主機架構穩定性；
I/O規劃及配置；
Swap交換分割槽；
OS核心引數和網路問題。

應用程式方面：

應用程式穩定性；
SQL語句效能；
序列訪問資源；
效能欠佳會話管理；
這個應用適不適合用MySQL。

資料庫最佳化方面：

記憶體；
資料庫結構（物理&邏輯）；
例項配置。

說明：不管是設計系統、定位問題還是最佳化，都可以按照這個順序執行。

c 最佳化維度？

資料庫最佳化維度有四個：

硬體、系統配置、資料庫表結構、SQL及索引。

史上最全SQL最佳化方案

最佳化選擇：

最佳化成本：硬體>系統配置>資料庫表結構>SQL及索引。
最佳化效果：硬體<系統配置<資料庫表結構<SQL及索引。

1 最佳化工具有啥？

a 資料庫層面？

檢查問題常用工具：

1）MySQL

2）msyqladmin：MySQL客戶端，可進行管理操作

3）mysqlshow：功能強大的檢視shell命令

4）show [SESSION | GLOBAL] variables：檢視資料庫引數資訊

5）SHOW [SESSION | GLOBAL] STATUS：檢視資料庫的狀態資訊

6）information_schema：獲取後設資料的方法

7）SHOW ENGINE INNODB STATUS：Innodb引擎的所有狀態

8）SHOW PROCESSLIST：檢視當前所有連線session狀態

9）explain：獲取查詢語句的執行計劃

10）show index：檢視錶的索引資訊

11）slow-log：記錄慢查詢語句

12）mysqldumpslow：分析slowlog檔案的

不常用但好用的工具：

1）Zabbix：監控主機、系統、資料庫（部署zabbix監控平臺）

2）pt-query-digest：分析慢日誌

3）MySQL slap：分析慢日誌

4）sysbench：壓力測試工具

5）MySQL profiling：統計資料庫整體狀態工具

6）Performance Schema：MySQL效能狀態統計的資料

7）workbench：管理、備份、監控、分析、最佳化工具（比較費資源）

關於Zabbix參考：

http://www.cnblogs.com/clsn/p/7885990.html

b 資料庫層面問題解決思路？

一般應急調優的思路：針對突然的業務辦理卡頓，無法進行正常的業務處理，需要立馬解決的場景。

1）show processlist；

2）explain select id ,name from stu where name='clsn'; # ALL id name age sex；

select id,name from stu where id=2-1 函式結果集>30；show index from table；

3）透過執行計劃判斷，索引問題（有沒有、合不合理）或者語句本身問題；

4）show status like '%lock%'; # 查詢鎖狀態

kill SESSION_ID; # 殺掉有問題的session。

常規調優思路：針對業務週期性的卡頓，例如在每天10-11點業務特別慢，但是還能夠使用，過了這段時間就好了。

1）檢視slowlog，分析slowlog，分析出查詢慢的語句；

2）按照一定優先順序，一個一個排查所有慢語句；

3）分析top SQL，進行explain除錯，檢視語句執行時間；

4）調整索引或語句本身。

c 系統層面？

Cpu方面：

vmstat、sar top、htop、nmon、mpstat；

記憶體：

free、ps-aux；

IO裝置（磁碟、網路）：

iostat、ss、netstat、iptraf、iftop、lsof；

vmstat命令說明：

1）Procs：r顯示有多少程式正在等待CPU時間。b顯示處於不可中斷的休眠的程式數量。在等待I/O。

2）Memory：swpd顯示被交換到磁碟的資料塊的數量。未被使用的資料塊，使用者緩衝資料塊，用於作業系統的資料塊的數量。

3）Swap：作業系統每秒從磁碟上交換到記憶體和從記憶體交換到磁碟的資料塊的數量。s1和s0最好是0。

4）Io：每秒從裝置中讀入b1的寫入到裝置b0的資料塊的數量。反映了磁碟I/O。

5）System：顯示了每秒發生中斷的數量（in）和上下文交換（cs）的數量。

6）Cpu：顯示用於執行使用者程式碼，系統程式碼，空閒，等待I/O的Cpu時間。

iostat命令說明：

例項命令：iostat -dk 1 5

　　　　 iostat -d -k -x 5 （檢視裝置使用率（%util）和響應時間（await））

1）tps：該裝置每秒的傳輸次數。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合併為“一次I/O請求”。

2）iops ：硬體出廠的時候，廠家定義的一個每秒最大的IO次數

3）"一次傳輸"請求的大小是未知的。

4）kB_read/s：每秒從裝置（drive expressed）讀取的資料量；

5）KB_wrtn/s：每秒向裝置（drive expressed）寫入的資料量；

6）kB_read：讀取的總資料量；

7）kB_wrtn：寫入的總數量資料量；這些單位都為Kilobytes。

d 系統層面問題解決辦法？

你認為到底負載高好，還是低好呢？在實際的生產中，一般認為Cpu只要不超過90%都沒什麼問題。

當然不排除下面這些特殊情況：

Cpu負載高，IO負載低：

1）記憶體不夠；

2）磁碟效能差；

3）SQL問題--->去資料庫層，進一步排查SQL 問題；

4）IO出問題了（磁碟到臨界了、raid設計不好、raid降級、鎖、在單位時間內tps過高）；

5）tps過高：大量的小資料IO、大量的全表掃描。

IO負載高，Cpu負載低：

1）大量小的IO寫操作：

autocommit，產生大量小IO；IO/PS，磁碟的一個定值，硬體出廠的時候，廠家定義的一個每秒最大的IO次數。

2）大量大的IO 寫操作：SQL問題的機率比較大

IO和cpu負載都很高：

硬體不夠了或SQL存在問題。

4 基礎最佳化

a 最佳化思路？

定位問題點吮吸：硬體-->系統-->應用-->資料庫-->架構（高可用、讀寫分離、分庫分表）。

處理方向：明確最佳化目標、效能和安全的折中、防患未然。

b 硬體最佳化？

主機方面：

根據資料庫型別，主機CPU選擇、記憶體容量選擇、磁碟選擇：

1）平衡記憶體和磁碟資源；

2）隨機的I/O和順序的I/O；

3）主機 RAID卡的BBU（Battery Backup Unit）關閉。

CPU的選擇：

CPU的兩個關鍵因素：核數、主頻

根據不同的業務型別進行選擇：

1）CPU密集型：計算比較多，OLTP - 主頻很高的cpu、核數還要多

2）IO密集型：查詢比較，OLAP - 核數要多，主頻不一定高的

記憶體的選擇：

OLAP型別資料庫，需要更多記憶體，和資料獲取量級有關。

OLTP型別資料一般記憶體是Cpu核心數量的2倍到4倍，沒有最佳實踐。

儲存方面：

1）根據儲存資料種類的不同，選擇不同的儲存裝置；

2）配置合理的RAID級別（raid5、raid10、熱備盤）；

3）對與作業系統來講，不需要太特殊的選擇，最好做好冗餘（raid1）（ssd、sas、sata）。

4）raid卡：

主機raid卡選擇：

實現作業系統磁碟的冗餘（raid1）；

平衡記憶體和磁碟資源；

隨機的I/O和順序的I/O；

主機raid卡的BBU（Battery Backup Unit）要關閉。

網路裝置方面：

使用流量支援更高的網路裝置（交換機、路由器、網線、網路卡、HBA卡）

注意：以上這些規劃應該在初始設計系統時就應該考慮好。

c 伺服器硬體最佳化？

1）物理狀態燈

2）自帶管理裝置：遠端控制卡（FENCE裝置：ipmi ilo idarc）、開關機、硬體監控。

3）第三方的監控軟體、裝置（snmp、agent）對物理設施進行監控。

4）儲存裝置：自帶的監控平臺。EMC2（hp收購了）、日立（hds）、IBM低端OEM hds、高階儲存是自己技術，華為儲存。

d 系統最佳化？

Cpu：

基本不需要調整，在硬體選擇方面下功夫即可。

記憶體：

基本不需要調整，在硬體選擇方面下功夫即可。

SWAP：

MySQL儘量避免使用swap。

阿里雲的伺服器中預設swap為0。

IO ：

raid、no lvm、ext4或xfs、ssd、IO排程策略。

Swap調整(不使用swap分割槽)

/proc/sys/vm/swappiness的內容改成0（臨時），/etc/sysctl. conf上新增vm.swappiness=0（永久）

這個引數決定了Linux是傾向於使用swap，還是傾向於釋放檔案系統cache。在記憶體緊張的情況下，數值越低越傾向於釋放檔案系統cache。

當然，這個引數只能減少使用swap的機率，並不能避免Linux使用swap。

修改MySQL的配置引數innodb_flush_ method，開啟O_DIRECT模式：

這種情況下，InnoDB的buffer pool會直接繞過檔案系統cache來訪問磁碟，但是redo log依舊會使用檔案系統cache。

值得注意的是，Redo log是覆寫模式的，即使使用了檔案系統的cache，也不會佔用太多。

IO排程策略：

#echo deadline>/sys/block/sda/queue/scheduler 臨時修改為deadline

永久修改

vi /boot/grub/grub.conf

更改到如下內容:

kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

e 系統引數調整？

Linux系統核心引數最佳化：

vim/etc/sysctl.conf

net.ipv4.ip_local_port_range = 1024 65535：# 使用者埠範圍

net.ipv4.tcp_max_syn_backlog = 4096

net.ipv4.tcp_fin_timeout = 30

fs.file-max=65535：# 系統最大檔案控制程式碼，控制的是能開啟檔案最大數量

使用者限制引數（MySQL可以不設定以下配置）：

vim/etc/security/limits.conf

* soft nproc 65535

* hard nproc 65535

* soft nofile 65535

* hard nofile 65535

f 應用最佳化？

業務應用和資料庫應用獨立；

防火牆：iptables、selinux等其他無用服務（關閉）：

chkconfig --level 23456 acpid off

chkconfig --level 23456 anacron off

chkconfig --level 23456 autofs off

chkconfig --level 23456 avahi-daemon off

chkconfig --level 23456 bluetooth off

chkconfig --level 23456 cups off

chkconfig --level 23456 firstboot off

chkconfig --level 23456 haldaemon off

chkconfig --level 23456 hplip off

chkconfig --level 23456 ip6tables off

chkconfig --level 23456 iptables off

chkconfig --level 23456 isdn off

chkconfig --level 23456 pcscd off

chkconfig --level 23456 sendmail off

chkconfig --level 23456 yum-updatesd off

安裝圖形介面的伺服器不要啟動圖形介面runlevel 3。

另外，思考將來我們的業務是否真的需要MySQL，還是使用其他種類的資料庫。用資料庫的最高境界就是不用資料庫。

5 資料庫最佳化

SQL最佳化方向：執行計劃、索引、SQL改寫。

架構最佳化方向：高可用架構、高效能架構、分庫分表。

a 資料庫引數最佳化？

調整

例項整體（高階最佳化，擴充套件）：

thread_concurrency：# 併發執行緒數量個數

sort_buffer_size：# 排序快取

read_buffer_size：# 順序讀取快取

read_rnd_buffer_size：# 隨機讀取快取

key_buffer_size：# 索引快取

thread_cache_size：# (1G—>8, 2G—>16, 3G—>32, >3G—>64)

連線層（基礎最佳化）

設定合理的連線客戶和連線方式：

max_connections # 最大連線數，看交易筆數設定

max_connect_errors # 最大錯誤連線數，能大則大

connect_timeout # 連線超時

max_user_connections # 最大使用者連線數

skip-name-resolve # 跳過域名解析

wait_timeout # 等待超時

back_log # 可以在堆疊中的連線數量

SQL層（基礎最佳化）

query_cache_size：查詢快取 >>> OLAP型別資料庫,需要重點加大此記憶體快取，但是一般不會超過GB。

對於經常被修改的資料，快取會立馬失效。

我們可以實用記憶體資料庫（redis、memecache），替代他的功能。

b 儲存引擎層（innodb基礎最佳化引數）？

default-storage-engine

innodb_buffer_pool_size # 沒有固定大小，50%測試值，看看情況再微調。但是儘量設定不要超過實體記憶體70%

innodb_file_per_table=(1,0)

innodb_flush_log_at_trx_commit=(0,1,2) # 1是最安全的，0是效能最高，2折中

binlog_sync

Innodb_flush_method=(O_DIRECT, fdatasync)

innodb_log_buffer_size # 100M以下

innodb_log_file_size # 100M 以下

innodb_log_files_in_group # 5個成員以下,一般2-3個夠用（iblogfile0-N）

innodb_max_dirty_pages_pct # 達到百分之75的時候刷寫記憶體髒頁到磁碟。

log_bin

max_binlog_cache_size # 可以不設定

max_binlog_size # 可以不設定

innodb_additional_mem_pool_size #小於2G記憶體的機器，推薦值是20M。32G記憶體以上100M

談談專案中常用的MySQL最佳化方法，共19條，具體如下：

1、EXPLAIN

做MySQL最佳化，我們要善用EXPLAIN檢視SQL執行計劃。

下面來個簡單的示例，標註（1、2、3、4、5）我們要重點關注的資料：

史上最全SQL最佳化方案

type列，連線型別。一個好的SQL語句至少要達到range級別。杜絕出現all級別。

key列，使用到的索引名。如果沒有選擇索引，值是NULL。可以採取強制索引方式。

key_len列，索引長度。

rows列，掃描行數。該值是個預估值。

extra列，詳細說明。注意，常見的不太友好的值，如下：Using filesort，Using temporary。

2、SQL語句中IN包含的值不應過多

MySQL對於IN做了相應的最佳化，即將IN中的常量全部儲存在一個陣列裡面，而且這個陣列是排好序的。但是如果數值較多，產生的消耗也是比較大的。再例如：select id from t where num in(1,2,3) 對於連續的數值，能用between就不要用in了；再或者使用連線來替換。

3、SELECT語句務必指明欄位名稱

SELECT*增加很多不必要的消耗（CPU、IO、記憶體、網路頻寬）；增加了使用覆蓋索引的可能性；當表結構發生改變時，前斷也需要更新。所以要求直接在select後面接上欄位名。

4、當只需要一條資料的時候，使用limit 1

這是為了使EXPLAIN中type列達到const型別

5、如果排序欄位沒有用到索引，就儘量少排序

6、如果限制條件中其他欄位沒有索引，儘量少用or

or兩邊的欄位中，如果有一個不是索引欄位，而其他條件也不是索引欄位，會造成該查詢不走索引的情況。很多時候使用union all或者是union（必要的時候）的方式來代替“or”會得到更好的效果。

7、儘量用union all代替union

union和union all的差異主要是前者需要將結果集合並後再進行唯一性過濾操作，這就會涉及到排序，增加大量的CPU運算，加大資源消耗及延遲。當然，union all的前提條件是兩個結果集沒有重複資料。

8、不使用ORDER BY RAND()

select id from `dynamic` order by rand() limit 1000;

上面的SQL語句，可最佳化為：

select id from `dynamic` t1 join (select rand() * (select max(id) from `dynamic`) as nid) t2 on t1.id > t2.nidlimit 1000;

9、區分in和exists、not in和not exists

select * from 表A where id in (select id from 表B)

上面SQL語句相當於

select * from 表A where exists(select * from 表B where 表B.id=表A.id)

區分in和exists主要是造成了驅動順序的改變（這是效能變化的關鍵），如果是exists，那麼以外層表為驅動表，先被訪問，如果是IN，那麼先執行子查詢。所以IN適合於外表大而內表小的情況；EXISTS適合於外表小而內表大的情況。

關於not in和not exists，推薦使用not exists，不僅僅是效率問題，not in可能存在邏輯問題。如何高效的寫出一個替代not exists的SQL語句？

原SQL語句：

select colname … from A表 where a.id not in (select b.id from B表)

高效的SQL語句：

select colname … from A表 Left join B表 on where a.id = b.id where b.id is null

取出的結果集如下圖表示，A表不在B表中的資料：

史上最全SQL最佳化方案

10、使用合理的分頁方式以提高分頁的效率

select id,name from product limit 866613, 20

使用上述SQL語句做分頁的時候，可能有人會發現，隨著表資料量的增加，直接使用limit分頁查詢會越來越慢。

最佳化的方法如下：可以取前一頁的最大行數的id，然後根據這個最大的id來限制下一頁的起點。比如此列中，上一頁最大的id是866612。SQL可以採用如下的寫法：

select id,name from product where id> 866612 limit 20

11、分段查詢

一些使用者選擇頁面中，可能一些使用者選擇的時間範圍過大，造成查詢緩慢。主要的原因是掃描行數過多。這個時候可以透過程式，分段進行查詢，迴圈遍歷，將結果合併處理進行展示。

如下圖這個SQL語句，掃描的行數成百萬級以上的時候就可以使用分段查詢：

史上最全SQL最佳化方案

12、避免在where子句中對欄位進行null值判斷

對於null的判斷會導致引擎放棄使用索引而進行全表掃描。

13、不建議使用%字首模糊查詢

例如LIKE“%name”或者LIKE“%name%”，這種查詢會導致索引失效而進行全表掃描。但是可以使用LIKE “name%”。

那如何查詢%name%？

如下圖所示，雖然給secret欄位新增了索引，但在explain結果並沒有使用：

史上最全SQL最佳化方案

那麼如何解決這個問題呢，答案：使用全文索引。

在我們查詢中經常會用到select id,fnum,fdst from dynamic_201606 where user_name like '%zhangsan%'; 。這樣的語句，普通索引是無法滿足查詢需求的。慶幸的是在MySQL中，有全文索引來幫助我們。

建立全文索引的SQL語法是：

ALTER TABLE `dynamic_201606` ADD FULLTEXT INDEX `idx_user_name` (`user_name`);

使用全文索引的SQL語句是：

select id,fnum,fdst from dynamic_201606 where match(user_name) against('zhangsan' in boolean mode);

注意：在需要建立全文索引之前，請聯絡DBA確定能否建立。同時需要注意的是查詢語句的寫法與普通索引的區別。

14、避免在where子句中對欄位進行表示式操作

比如：

select user_id,user_project from user_base where age*2=36;

中對欄位就行了算術運算，這會造成引擎放棄使用索引，建議改成：

select user_id,user_project from user_base where age=36/2;

15、避免隱式型別轉換

where子句中出現column欄位的型別和傳入的引數型別不一致的時候發生的型別轉換，建議先確定where中的引數型別。

16、對於聯合索引來說，要遵守最左字首法則

舉列來說索引含有欄位id、name、school，可以直接用id欄位，也可以id、name這樣的順序，但是name;school都無法使用這個索引。所以在建立聯合索引的時候一定要注意索引欄位順序，常用的查詢欄位放在最前面。

17、必要時可以使用force index來強制查詢走某個索引

有的時候MySQL最佳化器採取它認為合適的索引來檢索SQL語句，但是可能它所採用的索引並不是我們想要的。這時就可以採用forceindex來強制最佳化器使用我們制定的索引。

18、注意範圍查詢語句

對於聯合索引來說，如果存在範圍查詢，比如between、>、<等條件時，會造成後面的索引欄位失效。

19、關於JOIN最佳化

史上最全SQL最佳化方案

LEFT JOIN A表為驅動表，INNER JOIN MySQL會自動找出那個資料少的表作用驅動表，RIGHT JOIN B表為驅動表。

注意：

1）MySQL中沒有full join，可以用以下方式來解決：

select * from A left join B on B.name = A.namewhere B.name is nullunion allselect * from B;

2）儘量使用inner join，避免left join：

參與聯合查詢的表至少為2張表，一般都存在大小之分。如果連線方式是inner join，在沒有其他過濾條件的情況下MySQL會自動選擇小表作為驅動表，但是left join在驅動表的選擇上遵循的是左邊驅動右邊的原則，即left join左邊的表名為驅動表。

3）合理利用索引：

被驅動表的索引欄位作為on的限制欄位。

4）利用小表去驅動大表：

史上最全SQL最佳化方案

從原理圖能夠直觀的看出如果能夠減少驅動表的話，減少巢狀迴圈中的迴圈次數，以減少 IO總量及CPU運算的次數。

5）巧用STRAIGHT_JOIN：

inner join是由MySQL選擇驅動表，但是有些特殊情況需要選擇另個表作為驅動表，比如有group by、order by等「Using filesort」、「Using temporary」時。STRAIGHT_JOIN來強制連線順序，在STRAIGHT_JOIN左邊的表名就是驅動表，右邊則是被驅動表。在使用STRAIGHT_JOIN有個前提條件是該查詢是內連線，也就是inner join。其他連結不推薦使用STRAIGHT_JOIN，否則可能造成查詢結果不準確。

史上最全SQL最佳化方案

這個方式有時能減少3倍的時間。

以上19條MySQL最佳化方法希望對大家有所幫助！

史上最全SQL最佳化方案

相關文章