MySQL性能優化

1 優化介紹

在進行優化分享之前，先請大家記住不要聽信你看到的關于優化的“絕對真理”，而應該是在實際的業務場景下通過測試來驗證你關于執行計劃以及響應時間的假設：本次隻是給大家提供一些優化方面的方向和思路，而具體業務場景的不同，使用的MySQL服務版本不同，都會使得優化方案的制定也不同。

1.1 MySQL介紹

MySQL憑借着出色的性能、低廉的成本、豐富的資源，已經成為絕大多數網際網路公司的首選關系型資料庫。可以看到Google，Facebook，Twitter，百度，新浪，騰訊，淘寶，網易，久遊等絕大多數網際網路公司資料庫都是用的MySQL資料庫，甚至将其作為核心應用的資料庫系統。

雖然性能出色，但所謂“好馬配好鞍”，如何能夠更好的使用它，已經成為開發工程師的必修課，我們經常會從職位描述上看到諸如“精通MySQL”、“SQL語句優化”、“了解資料庫原理”等要求。我們知道一般的應用系統，讀寫比例在10:1左右，而且插入操作和一般的更新操作很少出現性能問題，遇到最多的，也是最容易出問題的，還是一些複雜的查詢操作，是以查詢語句的優化顯然是重中之重。

我們将這裡進行一個較為全面的分析，讓大家了解到MySQL的性能到底與哪些地方有關，以便于讓大家尋找出其性能問題的根本原因，而盡可能清楚的知道該如何去優化自己的資料庫。

1.2 優化要考慮的問題

注意：優化有風險，涉足需謹慎！

1.2.1 優化可能帶來的問題

優化不總是對一個單純的環境進行，還很可能是一個複雜的已投産的系統！
優化手段有很大的風險，一定要意識到和預見到！
任何的技術可以解決一個問題，但必然存在帶來一個問題的風險！
對于優化來說調優而帶來的問題,控制在可接受的範圍内才是有成果。
保持現狀或出現更差的情況都是失敗！

1.2.2 優化的需求

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

是以優化工作,是由業務需要驅使的！！！

1.2.3 優化由誰參與

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

1.2.4 優化的方向

在資料庫優化上有兩個主要方向：即安全與性能。

安全 : 資料安全性
性能 : 資料的高性能通路

本次主要是在性能優化方向進行介紹

1.2.5 優化的次元

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

從上圖中可以看出，我們把資料庫優化分為四個緯度：硬體，系統配置，資料庫表結構，SQL及索引

硬體： CPU、記憶體、存儲、網絡裝置等

系統配置：伺服器系統、資料庫服務參數等

資料庫表結構：高可用、分庫分表、讀寫分離、存儲引擎、表設計等

Sql及索引： sql語句、索引使用等

從優化成本進行考慮：硬體>系統配置>資料庫表結構>SQL及索引
從優化效果進行考慮：硬體<系統配置<資料庫表結構<SQL及索引

1.3 資料庫使用優化思路

本次盡可能的全面介紹資料庫的調優思路，但是在多數時候，我們進行調優不需要進行這麼全面、大範圍的調優，一般情況下，我們進行資料庫層面的優化就可以了，那我們該如何調優的呢？

應急調優的思路：

針對突然的業務辦理卡頓，無法進行正常的業務處理！需要立馬解決的場景！

show processlist（檢視連接配接session狀态）
explain(分析查詢計劃)，show index from tableName（分析索引）
show status like ‘%lock%’; # 查詢鎖狀态

正常調優的思路：

針對業務周期性的卡頓，例如在每天10-11點業務特别慢，但是還能夠使用，過了這段時間就好了。

開啟慢查詢日志，運作一天
檢視slowlog，分析slowlog，分析出查詢慢的語句。
按照一定優先級，進行一個一個的排查所有慢語句。
分析top sql，進行explain調試，檢視語句執行時間。
調整索引或語句本身。

2 優化實踐

2.1 查詢優化

2.1.1 MySQL查詢流程

我們該如何進行sql優化呢，首先我們需要知道，sql優化其實主要是解決查詢的優化問題，是以我們先從資料庫的查詢開始入手，下面這幅圖顯示了查詢的執行路徑：

① 用戶端将查詢發送到伺服器；

② 伺服器檢查查詢緩存，如果找到了，就從緩存中傳回結果，否則進行下一步。

③ 伺服器解析，預處理。

④ 查詢優化器優化查詢

⑤ 生成執行計劃，執行引擎調用存儲引擎API執行查詢

⑥伺服器将結果發送回用戶端。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

查詢緩存

在解析一個查詢語句之前，如果查詢緩存是打開的，那麼MySQL會優先檢查這個查詢是否命中查詢緩存中的資料，如果命中緩存直接從緩存中拿到結果并傳回給用戶端。這種情況下，查詢不會被解析，不用生成執行計劃，不會被執行。

文法解析和預處理器

MySQL通過關鍵字将SQL語句進行解析，并生成一棵對應的“解析樹”。MySQL解析器将使用MySQL文法規則驗證和解析查詢。

查詢優化器

文法樹被校驗合法後由優化器轉成查詢計劃，一條語句可以有很多種執行方式，最後傳回相同的結果。優化器的作用就是找到這其中最好的執行計劃。

查詢執行引擎

在解析和優化階段，MySQL将生成查詢對應的執行計劃，MySQL的查詢執行引擎則根據這個執行計劃來完成整個查詢。最常使用的也是比較最多的引擎是MyISAM引擎和InnoDB引擎。mysql5.5開始的預設存儲引擎已經變更為innodb了。

前面的查詢流程分析，我們大概了解了MySQL是如何執行的。現在我們先從查詢優化部分開始。

sql是我們和資料庫交流最重要的部分，是以我們在調優的時候，需要花費的大量時間就在sql調優上面。常見的分析手段有慢查詢日志，EXPLAIN 分析查詢，通過定位分析性能的瓶頸，才能更好的優化資料庫系統的性能。

2.1.2 慢查詢日志(重要)

預設情況下慢日志查詢是禁用的。通過

show variables like '%slow_query_log%'

檢視慢查詢日志的開啟情況

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

2.1.2.1 慢查詢日志開啟

如要開啟慢查詢日志，可以使用指令

set global slow_query_log=1;

。再次檢視慢查詢日志，可以發現已經開啟。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

但是當重新開機MySQL後，則又會關閉。如果需要長期開啟的話，需要在配置檔案 /etc/my.cnf 或my.ini中在[mysqld]一行下面加入三個配置參數

slow_query_log=ON
slow-query-log-file=/var/lib/mysql/slow-query.log
long_query_time=0

修改完成後，重新開機mysql：service mysqld restart

慢查詢分析

如果慢查詢日志中記錄内容很多，可以使用mysqldumpslow工具（MySQL用戶端安裝自帶）來對慢查詢日志進行分類彙總。mysqldumpslow對日志檔案進行了分類彙總，顯示彙總後摘要結果。

進入log的存放目錄，運作：

[[email protected]_data]# mysqldumpslow slow-query.log
Reading mysql slow query log fromslow-query.log
Count: 2 Time=11.00s (22s) Lock=0.00s (0s)Rows=1.0 (2), root[root]@mysql
select count(N) from t_user;

mysqldumpslow指令

mysqldumpslow -s c -t 10 slow-query.log

這會輸出記錄次數最多的10條SQL語句，其中：

-s, 是表示按照何種方式排序，c、t、l、r分别是按照記錄次數、時間、查詢時間、傳回的記錄數來排序，ac、at、al、ar，表示相應的倒叙

-t, 是top n的意思，即為傳回前面多少條的資料；

例如：

mysqldumpslow -s r -t 10 slow-query.log

：得到傳回記錄集最多的10個查詢。

mysqldumpslow -s t -t 10 -g “leftjoin” slow-query.log

：得到按照時間排序的前10條裡面含有左連接配接的查詢語句。

使用mysqldumpslow指令可以非常明确的得到各種我們需要的查詢語句，對MySQL查詢語句的監控、分析、優化是MySQL優化非常重要的一步。開啟慢查詢日志後，由于日志記錄操作，在一定程度上會占用CPU資源影響mysql的性能，但是可以階段性開啟來定位性能瓶頸。

拓展：分布式鍊路跟蹤系統（APM系統追蹤）：SKYwalking、pinpoint、cat（大衆點評）、spring cloud slueth+zipkin、鷹眼（阿裡）

2.1.3 執行計劃Explain

2.1.3.1 Explain概述

使用explain關鍵字可以模拟優化器執行SQL查詢語句, 進而知道MYSQL是如何處理SQL語句的。我們可以用執行計劃來分析查詢語句或者表結構的性能瓶頸

2.1.3.2 Explain作用

檢視表的讀取順序
檢視資料庫讀取操作的操作類型
檢視哪些索引有可能被用到
檢視哪些索引真正被用到
檢視表之間的引用
檢視表中有多少行記錄被優化器查詢

2.1.3.3 文法

文法

explain  sql語句

示例

explain select * from tb_user;

2.1.3.4 各字段解釋

準備工作

create table t1(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

create table t2(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

create table t3(
  id int primary key,
  name varchar(20),
  col1 varchar(20),
  col2 varchar(20),
  col3 varchar(20)
);

insert into t1 values(1,'zs1','col1','col2','col3');
insert into t2 values(1,'zs2','col2','col2','col3');
insert into t3 values(1,'zs3','col3','col2','col3');

create index ind_t1_c1 on t1(col1);
create index ind_t2_c1 on t2(col1);
create index ind_t3_c1 on t3(col1);

create index ind_t1_c12 on t1(col1,col2);
create index ind_t2_c12 on t2(col1,col2);
create index ind_t3_c12 on t3(col1,col2);

2.1.3.4.1 id

select 查詢的序列号,包含一組數字,表示查詢中執行Select子句或操作表的順序
兩種情況:

id值相同：執行順序由上而下。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化
id值不同：id值越大優先級越高。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

2.1.3.4.2 select_type

- SIMPLE : 簡單的select查詢,查詢中不包含子查詢或者UNION

- PRIMARY: 查詢中若包含複雜的子查詢,最外層的查詢則标記為PRIMARY

- SUBQUERY : 在SELECT或者WHERE清單中包含子查詢

- DERIVED : 在from清單中包含子查詢被标記為DRIVED衍生,MYSQL會遞歸執行這些子查詢,把結果放到臨時表中

- UNION: 若第二個SELECT出現在union之後,則被标記為UNION, 若union包含在from子句的子查詢中,外層select被标記為:derived

- UNION RESULT: 從union表擷取結果的select

執行sql

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

2.1.3.4.3 table

顯示這一行的資料是和哪張表相關

2.1.3.4.4 type

type顯示的是通路類型，是較為重要的一個名額，結果值從最好到最壞依次是

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range(盡量保證) > index > ALL

一般來說，得保證查詢至少達到range級别，最好能達到ref。

system：表(系統表)中隻有一行記錄, 這是const類型的特例, 基本上不會出現
const：通過索引一次查詢就找到了，const用于比較primary key或者unique索引，該表最多有一個比對行, 在查詢開始時讀取。由于隻有一行, 是以該行中列的值可以被優化器的其餘部分視為常量。const 表非常快, 因為它們隻讀一次。

eq_ref：讀取本表中和關聯表表中的每行組合成的一行。除了 system 和 const 類型之外, 這是最好的聯接類型。當連接配接使用索引的所有部分時, 索引是主鍵或唯一非 NULL 索引時, 将使用該值。

ref ：非唯一性索引掃描，傳回比對某個單獨值的所有行，本質上也是一種索引通路，它傳回所有符合條件的行。

range : 隻檢索給定範圍的行, 使用一個索引來選擇行.key列顯示的是真正使用了哪個索引,一般就是在where條件中使用between,>,<,in 等範圍的條件,這種在索引範圍内的掃描比全表掃描要好,因為它隻在某個範圍中掃描,不需要掃描全部的索引

index : 掃描整個索引表, index 和all的差別為index類型隻周遊索引樹. 這通常比all快,因為索引檔案通常比資料檔案小,雖然index和all都是讀全表,但是index是從索引中讀取,而all是從硬碟中讀取資料

all : 全表掃描 ,将周遊全表以找到比對的行

注意: 開發中,我們得保證查詢至少達到range級别,最好能達到ref.

如果百萬條資料出現all, 一般情況下就需要考慮使用索引優化了

2.1.3.4.5 key

查詢過程中真正使用的索引，如果為null，則表示沒有使用索引

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

2.1.3.4.6 key_len

索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度，長度越短越好。

2.1.3.4.7 ref

顯示索引的哪一列被使用了,如果可能的話,是一個常數.哪些列或者常量被用于查找索引列上的值

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

2.1.3.4.8 rows

根據表統計資訊及索引選用的情況,估算找出所需記錄要讀取的行數 (有多少行記錄被優化器讀取) ,越少越好

2.1.3.4.9 extra

包含不适合在其他列中顯示但十分重要的額外資訊。

2.2 索引優化

2.2.1 準備工作

建立以下表：

create database mysql_optimization;
use mysql_optimization;

CREATE TABLE `tb_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `name` varchar(20) DEFAULT NULL COMMENT '姓名',
  `number` int(11) DEFAULT NULL COMMENT '編号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

執行以下sql，批量添加1000000條資料：

drop procedure if exists tb_insert; 
CREATE PROCEDURE tb_insert()
BEGIN
DECLARE i INT;
SET i = 0;
START TRANSACTION;
WHILE i < 1000000 DO -- 1000000即插入1000000條資料
	INSERT INTO tb_table (`name`,`number`) VALUES (concat("張三",i),i);
	SET i = i+1;
END WHILE;
COMMIT;
END;

call tb_insert();

在表沒有添加索引的時候，都執行以下查詢：

2.2.2 索引介紹

2.2.2.1 什麼是索引

索引（Index）是幫助MySQL高效擷取資料的資料結構。在資料之外，資料庫系統還維護着滿足特定查找算法的資料結構，這些資料結構以某種方式指向資料，這樣就可以在這些資料結構上實作高效的查找算法，這種資料結構就是索引。

一般來說索引本身也很大，不可能全部存儲在記憶體中，是以往往以索引檔案的形式存放在磁盤中.。我們平常所說的索引，如果沒有特别說明都是指BTree索引(平衡多路搜尋樹).

2.2.2.2 索引的優缺點

優點
- 類似大學圖書館建書目索引，提高資料檢索的效率，降低資料庫的IO成本.
- 通過索引列對資料進行排序, 降低資料排序的成本，降低了CPU的消耗
缺點
- 實際上索引也是一張表，該表儲存了主鍵與索引字段，并指向實體表的記錄，是以索引列也是要占用空間的
- 雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對表進行INSERT、UPDATE和DELETE。因為更新表時，MySQL不僅要儲存資料，還要儲存一下索引檔案每次更新添加了索引列的字段都會調整。因為更新所帶來的鍵值變化後的索引資訊
- 索引隻是提高效率的一個因素，如果你的MySQL有大資料量的表，就需要花時間研究建立最優秀的索引，或優化查詢語句

2.2.2.3 索引的類别

2.2.2.3.1 普通索引

最基本的索引，它沒有任何限制.

2.2.2.3.2 唯一索引

與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。

2.2.2.3.3 主鍵索引

是一種特殊的唯一索引，這個時候需要一個表隻能有一個主鍵，不允許有空值。一般是在建表的時候同時建立主鍵索引.也就是說主鍵限制預設索引

2.2.2.3.4 複合索引

指多個字段上建立的索引，隻有在查詢條件中使用了建立索引時的第一個字段，索引才會被使用。使用組合索引時遵循最左字首規格

2.2.2.3.5 全文索引

主要用來查找文本中的關鍵字，而不是直接與索引中的值相比較。fulltext索引跟其它索引大不相同，它更像是一個搜尋引擎，而不是簡單的where語句的參數比對。目前隻有char、varchar，text 列上可以建立全文索引。值得一提的是，在資料量較大時候，先将資料放入一個沒有全局索引的表中，然後再用CREATE index建立fulltext索引，要比先為一張表建立fulltext然後再将資料寫入的速度快很多。

CREATE TABLE `info` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    PRIMARY KEY (`id`),
    FULLTEXT (content)
);

2.2.2.4 索引的基本文法

建立

删除

檢視

SHOW INDEX FROM 表名

2.2.2.5 索引的存儲結構

2.2.2.5.1 BTree索引

在前面的例子中我們看見有USING BTREE，這個是什麼呢？這個就是MySQL所使用的索引方案，MySQL中普遍使用B+Tree做索引，也就是BTREE。

為什麼使用B+樹：

B+樹是一個多路平衡查找樹，它和B樹的主要差別在于:

B樹中每個節點（葉子節點和非葉子節點）都存儲真實資料。而B+樹這種葉子節點存儲值，非葉子節點存儲鍵。
B樹中一條記錄隻會出現一次，不會出現重複。而B+樹的鍵可能出現重複。
B+樹的葉子節點使用雙向連結清單連接配接。

基于上述特點，B+樹具有如下優勢：

更少的IO次數： B+樹的非葉節點隻包含鍵，而不包含真實資料，是以每個節點存儲的記錄個數比B數多很多（即階m更大），是以B+樹的高度更低，通路時所需要的IO次數更少。此外，由于每個節點存儲的記錄數更多，是以對通路局部性原理的利用更好，緩存命中率更高。
更适于範圍查詢：在B樹中進行範圍查詢時，首先找到要查找的下限，然後對B樹進行中序周遊，直到找到查找的上限；而B+樹的範圍查詢，隻需要對連結清單進行周遊即可。
更穩定的查詢效率： B樹的查詢時間複雜度在1到樹高之間(分别對應記錄在根節點和葉節點)，而B+樹的查詢複雜度則穩定為樹高，因為所有資料都在葉節點。

但是B+樹也有其自身的缺點，因為鍵有可能出現重複，是以會占用更多的空間。但對于現代伺服器對比性能來說，空間劣勢基本都是可以接受的。

2.2.2.5.2 哈希索引

Hash索引在MySQL中使用的并不是很多，目前主要是Memory存儲引擎使用，在Memory存儲引擎中将Hash索引作為預設的索引類型。所謂Hash索引，實際上就是通過一定的Hash算法，将需要索引的鍵值進行Hash運算，然後将得到的Hash值存入一個Hash表中。然後每次需要檢索的時候，都會将檢索條件進行相同算法的Hash運算，然後再和Hash表中的Hash值進行比較并得出相應的資訊。

特點：

Hash索引僅僅隻能滿足“=”,“IN”和“<=>”查詢，不能使用範圍查詢；
Hash索引無法被利用來避免資料的排序操作；
Hash索引不能利用部分索引鍵查詢；
Hash索引在任何時候都不能避免表掃描；
Hash索引遇到大量Hash值相等的情況後性能并不一定就會比B+Tree索引高；

2.2.2.6 索引失效情況（重點）

環境準備

CREATE TABLE staffs (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR (24)  NULL DEFAULT '' COMMENT '姓名',
  age INT NOT NULL DEFAULT 0 COMMENT '年齡',
  pos VARCHAR (20) NOT NULL DEFAULT '' COMMENT '職位',
  add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入職時間'
) CHARSET utf8 COMMENT '員工記錄表' ;
 

INSERT INTO staffs(name,age,pos,add_time) VALUES('zhangsan',18,'manager',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('lisi',19,'dev',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('wangwu',20,'dev',NOW());

SELECT * FROM staffs;

ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

全值比對 (索引idx_staffs_nameAgePos 建立索引時以 name，age，pos 的順序建立的。全值比對表示按順序比對的

EXPLAIN SELECT * FROM staffs WHERE name = 'July';
EXPLAIN SELECT * FROM staffs WHERE name = 'July' AND age = 25;
EXPLAIN SELECT * FROM staffs WHERE age = 25 AND name = 'July' AND pos = 'dev';

EXPLAIN SELECT * FROM staffs WHERE age = 25;  
EXPLAIN SELECT add_time FROM staffs WHERE age = 25 AND pos = 'dev';

最左字首法則(如果索引了多列，要遵守最左字首法則。指的是查詢從索引的最左前列開始并且不跳過索引中的列。)

-- 【注意】
-- and 忽略左右關系。既即使沒有沒有按順序 由于優化器的存在，會自動優化。
-- 除開上述條件 才滿足最左字首法則。
EXPLAIN SELECT * FROM staffs WHERE age = 25 AND pos = 'dev'; -- 索引失效 
EXPLAIN SELECT * FROM staffs WHERE pos = 'dev';-- 索引失效

不在索引列上做任何操作（計算、函數、(自動or手動)類型轉換），如果做的話，會導緻索引失效而轉向全表掃描

存儲引擎不能使用索引中範圍條件(between、<、>、in等)右邊的列(範圍條件右邊與範圍條件使用的同一個組合索引，右邊的才會失效。若是不同索引則不會失效)。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

減少select *，使用哪些字段查哪些字段。
mysql5.7 在使用不等于(!= 或者<>)的時候無法使用索引會導緻全表掃描。但8.0不會。

EXPLAIN SELECT * FROM staffs WHERE  name = 'July';
EXPLAIN SELECT * FROM staffs WHERE  name <> 'July';
EXPLAIN SELECT * FROM staffs WHERE  name != 'July';

mysql5.7 is not null 也無法使用索引，但是is null是可以使用索引的。但8.0不會

EXPLAIN SELECT * FROM staffs WHERE  NAME IS NOT NULL; -- 索引失效
EXPLAIN SELECT * FROM staffs WHERE  NAME IS NULL;

like以%開頭(’%abc…’)mysql索引失效會變成全表掃描的操作

EXPLAIN SELECT * FROM staffs WHERE  NAME LIKE '%J'; -- ALL(索引失效)
EXPLAIN SELECT * FROM staffs WHERE  NAME LIKE '%J%'; -- ALL(索引失效)
EXPLAIN SELECT * FROM staffs WHERE  NAME LIKE 'J%'; -- range

字元串不加單引号索引失效 ( 底層進行轉換使索引失效，使用了函數造成索引失效)（隐式類型轉換）

一般在開發中，當要進行調優時，需要有一定的依賴資訊，可以通過

show status like 'Handler_read%';

檢視索引的使用情況。

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

handler_read_key：這個值越大說明使用索引查詢到的次數越多。

handler_read_rnd_next：這個值越高，說明查詢低效。

3 存儲優化

MySQL中索引是在存儲引擎層實作的，這裡我們會講解存儲引擎。

執行查詢引擎的指令show engines，可以看到MySQL支援的存儲引擎結果如下：

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

mysql支援存儲引擎有好幾種，咱們這裡主要讨論一下常用的Innodb，MyISAM存儲引擎。

3.1 存儲引擎介紹

3.1.1 InnoDB存儲引擎

特點：

InnoDB存儲引擎提供了具有送出、復原和崩潰恢複能力的事務安全。相比較MyISAM存儲引擎，InnoDB寫的處理效率差一點并且會占用更多的磁盤空間保留資料和索引。
提供了對資料庫事務ACID（原子性Atomicity、一緻性Consistency、隔離性Isolation、持久性Durability）的支援，實作了SQL标準的四種隔離級别。
設計目标就是處理大容量的資料庫系統，MySQL運作時InnoDB會在記憶體中建立緩沖池，用于緩沖資料和索引。
執行“select count(*) from table”語句時需要掃描全表，因為使用innodb引擎的表不會儲存表的具體行數，是以需要掃描整個表才能計算多少行。
InnoDB引擎是行鎖，粒度更小，是以寫操作不會鎖定全表，在并發較高時，使用InnoDB會提升效率。即存在大量UPDATE/INSERT操作時，效率較高，有可能出現死鎖。

使用場景：

經常UPDETE/INSERT的表，使用處理多并發的寫請求
支援事務，隻能選出InnoDB。
可以從災難中恢複（日志+事務復原）
外鍵限制、列屬性AUTO_INCREMENT支援

3.1.2 MyISAM存儲引擎

特點：

MyISAM不支援事務，不支援外鍵，SELECT/INSERT為主的應用可以使用該引擎，MyISAM引擎是表鎖，鎖定粒度大，并發性能低，避免出現死鎖。
每個MyISAM在存儲成3個檔案，擴充名分别是：

1) frm：存儲表定義（表結構等資訊）

2) MYD(MYData)，存儲資料

3) MYI(MYIndex)，存儲索引

不同MyISAM表的索引檔案和資料檔案可以放置到不同的路徑下。
MyISAM類型的表提供修複的工具，可以用CHECK TABLE語句來檢查MyISAM表健康，并用REPAIR TABLE語句修複一個損壞的MyISAM表。
在MySQL5.6以前，隻有MyISAM支援Full-text全文索引

使用場景：

經常SELECT的表，插入不頻繁，查詢非常頻繁。
不支援事務。
做很多count 的計算。

3.1.3 MyISAM和Innodb差別

InnoDB和MyISAM是許多人在使用MySQL時最常用的兩個存儲引擎，這兩個存儲引擎各有優劣，視具體應用而定。基本的差别為：MyISAM類型不支援事務處理，而InnoDB類型支援。MyISAM類型強調的是性能，其執行速度比InnoDB類型更快，而InnoDB提供事務支援已經外部鍵等進階資料庫功能。

具體實作的差别：

MyISAM是非事務安全型的，而InnoDB是事務安全型的。
MyISAM鎖的粒度是表級，而InnoDB支援行級鎖定。
MyISAM不支援外鍵，而InnoDB支援外鍵
MyISAM相對簡單，是以在效率上要優于InnoDB，小型應用可以考慮使用MyISAM。
InnoDB表比MyISAM表更安全。

3.2 存儲優化

3.2.1 禁用索引

對于使用索引的表，插入記錄時，MySQL會對插入的記錄建立索引。如果插入大量資料，建立索引會降低插入資料速度。為了解決這個問題，可以在批量插入資料之前禁用索引，資料插入完成後再開啟索引。

禁用索引的語句：

開啟索引語句：

MyISAM對于空表批量插入資料，則不需要進行操作，因為MyISAM引擎的表是在導入資料後才建立索引。

3.2.2 禁用唯一性檢查

唯一性校驗會降低插入記錄的速度，可以在插入記錄之前禁用唯一性檢查，插入資料完成後再開啟。(保證插入的資料沒有重複的)

禁用唯一性檢查的語句：SET UNIQUE_CHECKS = 0;

開啟唯一性檢查的語句：SET UNIQUE_CHECKS = 1;

3.2.3 禁用外鍵檢查

插入資料之前執行禁止對外鍵的檢查，資料插入完成後再恢複，可以提供插入速度。

禁用：SET foreign_key_checks = 0;

開啟：SET foreign_key_checks = 1;

3.2.4 禁止自動送出

插入資料之前執行禁止事務的自動送出，資料插入完成後再恢複，可以提高插入速度。

禁用：SET autocommit = 0;

開啟：SET autocommit = 1;

4 資料庫結構優化

4.1 優化表結構

盡量将表字段定義為NOT NULL限制，這時由于在MySQL中含有空值的列很難進行查詢優化，NULL值會使索引以及索引的統計資訊變得很複雜。
對于隻包含特定類型的字段，可以使用enum、set 等資料類型。
數值型字段的比較比字元串的比較效率高得多，字段類型盡量使用最小、最簡單的資料類型。例如IP位址可以使用int類型。
盡量使用TINYINT（4）、SMALLINT（6）、MEDIUM_INT（8）作為整數類型而非INT，如果非負則加上UNSIGNED。
VARCHAR的長度隻配置設定真正需要的空間
盡量使用TIMESTAMP而非DATETIME，但TIMESTAMP隻能表示1970 - 2038年，比DATETIME表示的範圍小得多，而且TIMESTAMP的值因時區不同而不同。
單表不要有太多字段，建議在20以内
合理的加入備援字段可以提高查詢速度。

4.2 表拆分

4.2.1 垂直拆分

垂直拆分按照字段進行拆分，其實就是把組成一行的多個列分開放到不同的表中，這些表具有不同的結構，拆分後的表具有更少的列。例如使用者表中的一些字段可能經常通路，可以把這些字段放進一張表裡。另外一些不經常使用的資訊就可以放進另外一張表裡。

插入的時候使用事務，也可以保證兩表的資料一緻。缺點也很明顯，由于拆分出來的兩張表存在一對一的關系，需要使用備援字段，而且需要join操作。但是我們可以在使用的時候可以分别取兩次，這樣的來說既可以避免join操作，又可以提高效率。

4.2.2 水準拆分

水準拆分按照行進行拆分，常見的就是分庫分表。以使用者表為例，可以取使用者ID，然後對ID取10的餘數，将使用者均勻的配置設定進這 0-9這10個表中。查找的時候也按照這種規則，又快又友善。

有些表業務關聯比較強，那麼可以使用按時間劃分的。例如每天的資料量很大，需要每天建立一張表。這種業務類型就是需要高速插入，但是對于查詢的效率不太關心。表越大，插入資料所需要索引維護的時間也就越長。

4.3 寫分離

大型網站會有大量的并發通路，如果還是傳統的資料存儲方案，隻是靠一台伺服器處理，如此多的資料庫連接配接、讀寫操作，資料庫必然會崩潰，資料丢失的話，後果更是不堪設想。這時候，我們需要考慮如何降低單台伺服器的使用壓力，提升整個資料庫服務的承載能力。

我們發現一般情況對資料庫而言都是“讀多寫少”，也就說對資料庫讀取資料的壓力比較大，這樣分析可以采用資料庫叢集的方案。其中一個是主庫，負責寫入資料，我們稱為寫庫；其它都是從庫，負責讀取資料，我們稱為讀庫。這樣可以緩解一台伺服器的通路壓力。

MySql自帶主從複制功能，我們可以使用主從複制的主庫作為寫庫，從庫和主庫進行資料同步，那麼可以使用多個從庫作為讀庫，已完成讀寫分離的效果。

4.4 資料庫叢集

如果通路量非常大，雖然使用讀寫分離能夠緩解壓力，但是一旦寫操作一台伺服器都不能承受了，這個時候我們就需要考慮使用多台伺服器實作寫操作。

例如可以使用MyCat搭建MySql叢集，對ID求3的餘數，這樣可以把資料分别存放到3台不同的伺服器上，由MyCat負責維護叢集節點的使用。

5 硬體優化

伺服器硬體的性能瓶頸，直接決定MySQL資料庫的運作速度和效率。可以從以下幾個方面考慮：

5.1 記憶體

足夠大的記憶體，是提高MySQL資料庫性能的方法之一。記憶體的IO比硬碟快的多，可以增加系統的緩沖區容量，使資料在記憶體停留的時間更長，以減少磁盤的IO。伺服器記憶體建議不要小于2GB，推薦使用4GB以上的實體記憶體。

5.2 磁盤

MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。是以，通常認為磁盤I/O是制約MySQL性能的最大因素之一，對于日均通路量在100萬PV以上的系統，由于磁盤I/O的制約，MySQL的性能會非常低下考慮以下幾種解決方案：

使用SSD或者PCIe SSD裝置，至少獲得數百倍甚至萬倍的IOPS提升；
購置陣列卡，可明顯提升IOPS
盡可能選用RAID-10，而非RAID-5
使用機械盤的話，盡可能選擇高轉速的，例如選用15000RPM，而不是7200RPM的盤

5.3 CPU

CPU僅僅隻能決定運算速度，及時是運算速度都還取決于與記憶體之間的總線帶寬以及記憶體本身的速度。但是一般情況下，我們都需要選擇計算速度較快的CPU。

關閉節能模式。作業系統和CPU硬體配合，系統不繁忙的時候，為了節約電能和降低溫度，它會将CPU降頻。這對環保人士和抵制地球變暖來說是一個福音，但是對MySQL來說，可能是一個災難。為了保證MySQL能夠充分利用CPU的資源，建議設定CPU為最大性能模式。

5.4 網絡

應該盡可能選擇網絡延時低，吞吐量高的裝置。

網絡延時：不同的網絡裝置其延時會有差異，延時自然是越小越好。
吞吐量：對于資料庫叢集來說，各個節點之間的網絡吞吐量可能直接決定叢集的處理能力。

6 緩存優化

6.1 查詢緩存

query_cache_size：作用于整個 MySQL，主要用來緩存MySQL中的ResultSet，也就是一條SQL語句執行的結果集，是以僅僅隻能針對select語句。查詢緩存從MySQL 5.7.20開始已被棄用，并在MySQL 8.0中被删除。

當我們打開了 Query Cache功能，MySQL在接受到一條select語句的請求後，如果該語句滿足Query Cache的要求，MySQL會直接根據預先設定好的HASH算法将接受到的select語句以字元串方式進行hash，然後到Query Cache中直接查找是否已經緩存。如果已經在緩存中，該select請求就會直接将資料傳回，進而省略了後面所有的步驟(如SQL語句的解析，優化器優化以及向存儲引擎請求資料等)，極大的提高性能。

當然，Query Cache也有一個緻命的缺陷，那就是當某個表的資料有任何任何變化，都會導緻所有引用了該表的select語句在Query Cache中的緩存資料失效。是以，當我們的資料變化非常頻繁的情況下，使用Query Cache可能會得不償失。

如果緩存命中率非常高的話，有測試表明在極端情況下可以提高效率238%，而在糟糕時，QC會降低系統13%的處理能力。

通過以下指令檢視緩存相關變量

have_query_cache：表示此版本mysql是否支援緩存
query_cache_limit ：緩存最大值
query_cache_size：緩存大小
query_cache_type：off 表示不緩存，on表示緩存所有結果。

6.2 全局緩存

資料庫屬于IO密集型的應用程式，其主職責就是資料的管理及存儲工作。而我們知道，從記憶體中讀取一個資料庫的時間是微秒級别，而從一塊普通硬碟上讀取一個 IO是在毫秒級别，二者相差3個數量級。是以，要優化資料庫，首先第一步需要優化的就是IO，盡可能将磁盤IO轉化為記憶體IO,也就是使用緩存

啟動MySQL時就要配置設定并且總是存在的全局緩存，可以在MySQL的my.conf或者my.ini檔案的[mysqld]組中配置。查詢緩存屬于全局緩存。

目前有：

key_buffer_size(預設值：402653184,即384M)、

innodb_buffer_pool_size(預設值：134217728即：128M)、

innodb_additional_mem_pool_size（預設值：8388608即：8M）、

innodb_log_buffer_size(預設值：8388608即：8M)、

query_cache_size(預設值：33554432即：32M)

key_buffer_size

用于索引塊的緩沖區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，對MyISAM表性能影響最大的一個參數。如果你使它太大，系統将開始換頁并且真的變慢了。

嚴格說是它決定了資料庫索引處理的速度，尤其是索引讀的速度。對于記憶體在4GB左右的伺服器該參數可設定為256M或384M.

innodb_buffer_pool_size

主要針對InnoDB表性能影響最大的一個參數。功能與Key_buffer_size一樣。InnoDB占用的記憶體，除innodb_buffer_pool_size用于存儲頁面緩存資料外，另外正常情況下還有大約8%的開銷，主要用在每個緩存頁幀的描述、adaptive hash等資料結構，如果不是安全關閉，啟動時還要恢複的話，還要另開大約12%的記憶體用于恢複，兩者相加就有差不多21%的開銷。

innodb_additional_mem_pool_size

設定了InnoDB存儲引擎用來存放資料字典資訊以及一些内部資料結構的記憶體空間大小，是以當我們一個MySQL Instance中的資料庫對象非常多的時候，是需要适當調整該參數的大小以確定所有資料都能存放在記憶體中提高通路效率的。

innodb_log_buffer_size

這是InnoDB存儲引擎的事務日志所使用的緩沖區。類似于Binlog Buffer。InnoDB在寫事務日志的時候，為了提高性能，也是先将資訊寫入Innofb Log Buffer中，當滿足innodb_flush_log_trx_commit參數所設定的相應條件(或者日志緩沖區寫滿)之後，才會将日志寫到檔案(或者同步到磁盤)中。可以通過innodb_log_buffer_size 參數設定其可以使用的最大記憶體空間。

InnoDB 将日志寫入日志磁盤檔案前的緩沖大小。理想值為 1M 至 8M。大的日志緩沖允許事務運作時不需要将日志儲存入磁盤而隻到事務被送出(commit)。是以，如果有大的事務處理，設定大的日志緩沖可以減少磁盤I/O。這個參數實際上還和另外的flush參數相關。一般來說不建議超過32MB。

6.3 局部緩存

除了全局緩沖，MySql還會為每個連接配接發放連接配接緩沖。個連接配接到MySQL伺服器的線程都需要有自己的緩沖。大概需要立刻配置設定256K，甚至線上程空閑時，它們使用預設的線程堆棧，網絡緩存等。事務開始之後，則需要增加更多的空間。運作較小的查詢可能僅給指定的線程增加少量的記憶體消耗，然而如果對資料表做複雜的操作例如掃描、排序或者需要臨時表，則需配置設定大約read_buffer_size，

sort_buffer_size，read_rnd_buffer_size，tmp_table_size大小的記憶體空間. 不過它們隻是在需要的時候才配置設定，并且在那些操作做完之後就釋放了。

read_buffer_size

是MySql讀入緩沖區大小。對表進行順序掃描的請求将配置設定一個讀入緩沖區，MySql會為它配置設定一段記憶體緩沖區。read_buffer_size變量控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁，并且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及記憶體緩沖區大小提高其性能.

sort_buffer_size

是MySql執行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小

read_rnd_buffer_size

是MySql的随機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，将配置設定一個随機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜尋，提高查詢速度，如果需要排序大量資料，可适當調高該值。但MySql會為每個客戶連接配接發放該緩沖空間，是以應盡量适當設定該值，以避免記憶體開銷過大。

tmp_table_size

是MySql的heap （堆積）表緩沖大小。所有聯合在一個DML指令内完成，并且大多數聯合甚至可以不用臨時表即可以完成。大多數臨時表是基于記憶體的(HEAP)表。具有大的記錄長度的臨時表 (所有列的長度的和)或包含BLOB列的表存儲在硬碟上。

如果某個内部heap（堆積）表大小超過tmp_table_size，MySQL可以根據需要自動将記憶體中的heap表改為基于硬碟的MyISAM表。還可以通過設定tmp_table_size選項來增加臨時表的大小。也就是說，如果調高該值，MySql同時将增加heap表的大小，可達到提高聯接查詢速度的效果。

record_buffer

record_buffer每個進行一個順序掃描的線程為其掃描的每張表配置設定這個大小的一個緩沖區。如果你做很多順序掃描，你可能想要增加該值。

6.4 其它緩存

table_cache

TABLE_CACHE(5.1.3及以後版本又名TABLE_OPEN_CACHE)，table_cache指定表高速緩存的大小。每當MySQL通路一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地通路表内容。

不能盲目地把table_cache設定成很大的值。如果設定得太高，可能會造成檔案描述符不足，進而造成性能不穩定或者連接配接失敗。

thread_cache_size

伺服器線程緩存，預設的thread_cache_size=8，,這個值表示可以重新利用儲存在緩存中線程的數量,當斷開連接配接時如果緩存中還有空間,那麼用戶端的線程将被放到緩存中,如果線程重新被請求，那麼請求将從緩存中讀取,如果緩存中是空的或者是新的請求，那麼這個線程将被重新建立,如果有很多新的線程，

增加這個值可以改善系統性能.通過比較Connections 和 Threads_created 狀态的變量，可以看到這個變量的作用。

7 MySQL伺服器優化

7.1 MySQL參數

通過優化MySQL的參數可以提高資源使用率，進而達到提高MySQL伺服器性能的目的。MySQL的配置參數都在my.conf或者my.ini檔案的[mysqld]組中，常用的參數如下：

back_log

在MySQL暫時停止回答新請求之前的短時間内多少個請求可以被存在堆棧中（每個連接配接256kb，占用：125M）。也就是說，如果MySql的連接配接資料達到max_connections時，新來的請求将會被存在堆棧中，以等待某一連接配接釋放資源，該堆棧的數量即back_log，如果等待連接配接的數量超過back_log，将不被授予連接配接資源。

wait_timeout

當MySQL連接配接閑置，超過一定時間後将會被強行關閉。MySQL預設的wait-timeout值為8個小時。

設定這個值是非常有意義的，比如你的網站有大量的MySQL連結請求（每個MySQL連接配接都是要記憶體資源開銷的），由于你的程式的原因有大量的連接配接請求空閑啥事也不幹，白白占用記憶體資源，或者導緻MySQL超過最大連接配接數從來無法建立連接配接導緻“Too many connections”的錯誤。在設定之前你可以檢視一下你的MYSQL的狀态（可用showprocesslist)，如果經常發現MYSQL中有大量的Sleep程序，則需要修改wait-timeout值了。

max_connections

是指MySql的最大連接配接數，如果伺服器的并發連接配接請求量比較大，建議調高此值，以增加并行連接配接數量，當然這建立在機器能支撐的情況下，因為如果連接配接數越多，介于MySql會為每個連接配接提供連接配接緩沖區，就會開銷越多的記憶體，是以要适當調整該值，不能盲目提高設值。

MySQL伺服器允許的最大連接配接數16384

max_user_connections

是指每個資料庫使用者的最大連接配接針對某一個賬号的所有用戶端并行連接配接到MYSQL服務的最大并行連接配接數。簡單說是指同一個賬号能夠同時連接配接到mysql服務的最大連接配接數。設定為0表示不限制。

thread_concurrency

的值的正确與否, 對mysql的性能影響很大, 在多個cpu(或多核)的情況下，錯誤設定了thread_concurrency的值, 會導緻mysql不能充分利用多cpu(或多核), 出現同一時刻隻能一個cpu(或核)在工作的情況。thread_concurrency應設為CPU核數的2倍。

skip-name-resolve

禁止MySQL對外部連接配接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠端主機連接配接授權都要使用IP位址方式，否則MySQL将無法正常處理連接配接請求！

default-storage-engine

default-storage-engine=InnoDB(設定InnoDB類型，另外還可以設定MyISAM類型)設定建立資料庫及表預設存儲類型

L預設的wait-timeout值為8個小時。

max_connections

MySQL伺服器允許的最大連接配接數16384

max_user_connections

thread_concurrency

的值的正确與否, 對mysql的性能影響很大, 在多個cpu(或多核)的情況下，錯誤設定了thread_concurrency的值, 會導緻mysql不能充分利用多cpu(或多核), 出現同一時刻隻能一個cpu(或核)在工作的情況**。thread_concurrency應設為CPU核數的2倍。**

skip-name-resolve

default-storage-engine

default-storage-engine=InnoDB(設定InnoDB類型，另外還可以設定MyISAM類型)設定建立資料庫及表預設存儲類型

MySQL性能優化MySQL性能優化1 優化介紹2 優化實踐3 存儲優化4 資料庫結構優化5 硬體優化6 緩存優化7 MySQL伺服器優化

MySQL性能優化

1 優化介紹

1.1 MySQL介紹

1.2 優化要考慮的問題

1.2.1 優化可能帶來的問題

1.2.2 優化的需求

1.2.3 優化由誰參與

1.2.4 優化的方向

1.2.5 優化的次元

1.3 資料庫使用優化思路

2 優化實踐

2.1 查詢優化

2.1.1 MySQL查詢流程

2.1.2 慢查詢日志(重要)

2.1.2.1 慢查詢日志開啟

2.1.3 執行計劃Explain

2.1.3.1 Explain概述

2.1.3.2 Explain作用

2.1.3.3 文法

2.1.3.4 各字段解釋

2.1.3.4.1 id

2.1.3.4.2 select_type

2.1.3.4.3 table

2.1.3.4.4 type

2.1.3.4.5 key

2.1.3.4.6 key_len

2.1.3.4.7 ref

2.1.3.4.8 rows

2.1.3.4.9 extra

2.2 索引優化

2.2.1 準備工作

2.2.2 索引介紹

2.2.2.1 什麼是索引

2.2.2.2 索引的優缺點

2.2.2.3 索引的類别

2.2.2.3.1 普通索引

2.2.2.3.2 唯一索引

2.2.2.3.3 主鍵索引

2.2.2.3.4 複合索引

2.2.2.3.5 全文索引

2.2.2.4 索引的基本文法

2.2.2.5 索引的存儲結構

2.2.2.5.1 BTree索引

2.2.2.5.2 哈希索引

2.2.2.6 索引失效情況（重點）

3 存儲優化

3.1 存儲引擎介紹

3.1.1 InnoDB存儲引擎

3.1.2 MyISAM存儲引擎

3.1.3 MyISAM和Innodb差別

3.2 存儲優化

3.2.1 禁用索引

3.2.2 禁用唯一性檢查

3.2.3 禁用外鍵檢查

3.2.4 禁止自動送出

4 資料庫結構優化

4.1 優化表結構

4.2 表拆分

4.2.1 垂直拆分

4.2.2 水準拆分

4.3 寫分離

4.4 資料庫叢集

5 硬體優化

5.1 記憶體

5.2 磁盤

5.3 CPU

5.4 網絡

6 緩存優化

6.1 查詢緩存

6.2 全局緩存

6.3 局部緩存

6.4 其它緩存

7 MySQL伺服器優化

7.1 MySQL參數

繼續閱讀