mysql優化1

一 操作系統層面的優化

1 交換分區與內存的比例

vm swappiness

設置如果交換分區太大，則會造成過多佔用交換分區內存，導致速度變慢，如果設置過小，則可能會造成內存溢出OOM

對於專用於MYSQL的系統，一般設置爲1，對於一般的系統建議設置爲10，
臨時修改swappiness

永久修改

2 I/O 調度

首選 deadline ，其次是noop
文件系統首選是xfs,其次是ext4 ，因爲xfs的結構更貼近與mysql的B+樹方式
查看系統支持的I/O調度方式

查看當前系統的I/O調度方式

臨時修改I/O調度算法

永久修改I/O調度算法


注意 ：
此處boot下的文件不同的Linux版本不同，請根據自己的實際情況選擇
需要重啓服務器方可生效

二 數據庫配置文件層面優化

1 innodb存儲引擎圖集

2 innodb_buffer_pool_size

默認是128M

一般的，只跑數據庫的服務器其大小設置爲內存的50%-80%。

具體限制如下：
計算Innodb_buffer_pool_pages_data/Innodb_buffer_pool_pages_total*100%
當結果 > 95% 則增加 innodb_buffer_pool_size， 建議使用物理內存的 75%
當結果 < 95% 則減少 innodb_buffer_pool_size
建議設置大小爲： Innodb_buffer_pool_pages_data* Innodb_page_size* 1.05 / (1024*1024*1024)
命令配置：
mysql 中配置命令：SET GLOBAL innodb_buffer_pool_size= 256M

文件中配置命令：innodb_buffer_pool_size=256M

3 表空間相關

1 獨佔表空間

每個表都將會形成以獨立的文件方式來進行存儲，每一個表都有一個.frm表描述文件，還有一個.idb 文件，其中這個文件包括了單獨一個表的數據內容以及索引內容，默認情況下他的存儲是在表的存儲位置中。

獨佔表空間：默認的文件名爲:ibdata1 初始化爲12M。

獨佔表空間在數據庫啓動時就已經佔用內存爲12M

查看默認使用的表空間方式

如果爲ON，則表示其是獨立表空間，如果是oFF，則表示其是共享表空間

配置文件中配置：
此配置只能在配置文件中實現，並且需要進行重啓。

innodb_data_file_path=ibdata1:12M;ibdata2:12M:autoextend

獨佔表空間可以配置多個，當每個文件都滿了的時候，ibdata2會自動擴展
如果用 autoextend 選項描述最後一個數據文件，當 InnoDB 用盡所有表自由空間後將會自動擴充最後一個數據文件，每次增量爲 8 MB。

當存儲空間滿了的時候，可以在其他的磁盤上添加數據文件
添加事例：
pathtodatafile:sizespecification;pathtodatafile:sizespec;.;pathtodatafile:sizespec[:autoextend[:max:sizespecification]]

2 共享表空間

innodb 所有數據都保存在一個單獨的表空間裏面，而這個表空間可以由多個文件組成，一個表可以跨多個文件存在，所以其大小限制不再是文件大小限制，而是其自身的限制，其表空間的最大限制爲64TB，包含其其他索引大小。

3 兩者的優缺點：

共享表空間：
優點：
可以將表空間分成多個文件存放到各個磁盤上，數據和文件放在一起方便管理，
缺點：
1 所有的數據和索引放置在一個恩建中會造成混合存儲，
2 當數據量非常大的時候，表做了大量刪除操作後表空間將會出現大量的空隙，對於統計分析數據十分不利。其不能進行回縮，當出現臨時創建索引或是創建一個臨時的操作表空間擴大後，就是刪除相關的表也沒有辦法回縮那部分空間。

獨佔表空間：
優點：
每個表都有自己獨立的表空間，每個表的數據和索引都會存儲在自己的表空間中，可以實現單表在不同數據庫中一定，空間可以通過drop進行回收，如果對於統計分析或日誌表，刪除大量數據可以通過：after table TableName engine=innodb 回收表空間
缺點：
但如果單表增加過大，當單表佔用空間過大時，存儲空間不足，只能從操作系統層面思考

4 共享表和獨立表空間之間的轉換

修改配置文件
innodb_file_per_table=1 表示爲獨佔表空間
innodb_file_per_table=0 表示爲共享表空間
運行中修改：

4 緩衝相關

1 查詢緩衝

用於對mysql 查詢結果進行緩存，如果下次收到同樣的查詢請求，不會再執行實際的查詢處理，而是直接返回結果，這樣可以提高查詢效率，並提高系統性能，前提是有很多的查詢而修改很少，如果修改很多，則沒有必要開啓此功能。

默認查詢緩衝是關閉的

配置方式

query_cache_type=1
如果設置爲0，則表示禁用，如果設置爲1，將會緩存所有的結果，除非使用了SQL_NO_CACHE，如果設置爲2，表示只緩存在select語句中通過SQL_CACHE 指定需要緩存的查詢

query_cache_size=20M 表示緩存設置的大小

2 排序緩衝

排序是數據庫中一個基本功能，用戶通過order by 語句能達到將指定的結果集排序的目的，不僅僅是order by，group by, distinct 語句也隱含使用排序。

mysql內部實現排序的方式主要有3種：常規排序、優化排序、優先隊列排序，主要涉及3種排序算法：快速排序，歸併排序和堆排序。

是否使用文件排序主要看sort buffer 是否能夠容下需要排序的結果集，這個buffer的大小由sort_buffer_size 參數控制，

1 普通排序緩存
排序緩存是會話緩存，如果客戶機向服務器發送的SQL語句中含有設計排序的order by 或者 group by 字句，mysql 就會選擇相應的排序算法，在普通排序索引上進行排序，提升排序速度，普通排序索引大小由sort_buffer_size參數決定，如果想要提升排序速度，首先應加上合適的索引，此後則增大排序緩衝。

2 優化排序規則
優化排序規則相對於常規排序，減少了第二次IO，主要區別在於，一次性取出SQL中出現的所有字段放入sort buffer 中而不是隻取排序需要的字段，由於sort buffer中包含了查詢所需的所有字段，因此排序完成後可以直接返回結果，無需二次取數據，所以如果此時sort_buffer 不夠大，則可能導致需要寫臨時文件，造成額外EI，當然在mysql中提供了max_length_for_sort_data，只有當排序sql裏出現的所有字段小於max_length_for_sort_data 時，才能採用優化排序的方式，否則只能用常規排序方式。

max_sort_length：
order by 或者group by 的時候使用該列的前max_sort_lenth 字節進行排序，操作完成後，將此排序信息記錄到本次會話的狀態中

3 優先隊列排序：爲了得到最終的排序結果，我們都需要將所有滿足條件的記錄進行排序才能返回，那麼相對於優化排序方式，還有優化空間，5.6版本針對order by limit M,N 語句，在空間層面做了優化，加入了一種新的排序方式--優先隊列，這種方式採用堆棧排序實現。詳情請見：https://www.cnblogs.com/zhoujinyi/p/5437289.html

查看排序統計信息：

sort_merge_passes： 使用臨時文件完成排序操作的次數，mysql在進行排序操作時，首先嚐試在普通排序緩存中完成排序，如果緩存空間不夠，mysql將利用緩存進行多次排序，並把每次排序的結果存放在臨時文件中，最後再把臨時文件中的數據進行排序，sort_merge_passes 值就是記錄了使用文件進行排序的次數，由於文件排序要涉及到讀文件，所以其消耗系統資源較大，因此如果sort_merge_passes很大，就表示需要注意sort_buffer_size。
sort_range
使用範圍排序的次數
sort_rows
已經排序的記錄行數
sort_scan
通過全表掃描完成排序的次數

3 join連接緩衝

join 緩存是會話緩存，如果兩張表相連，但是無法使用索引，mysql將爲每張表分配join連接緩存。

5 統計大小

1 統計每個庫大小：

命令：

use  information_schema;
SELECT TABLE_SCHEMA,SUM(DATA_LENGTH)/1024/1024/1024 as DATA_LENGTH,SUM(INDEX_LENGTH)/1024/1024/1024 
as INDEX_LENGTH,SUM(DATA_LENGTH+INDEX_LENGTH)/1024/1024/1024 as SUM_DATA_INDEX FROM information_schema.TABLES 
WHERE TABLE_SCHEMA!='information_schema' AND TABLE_SCHEMA!='mysql' GROUP BY TABLE_SCHEMA;

2 統計所有數據庫的大小

6 事務的隔離級別

默認使用的是RR 可重複讀

事物隔離級別	髒讀	不可重複讀	幻讀
讀未提交（read-uncommitted）	是	是	是
不可重讀讀（read-committed）	否	是	是
可重複讀（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

RU 的作用是當終端A修改的數據沒有提交，但終端B已經能夠查詢到終端A修改的數據。如果A 因某種情況而撤銷操作，則B讀取到的數據將會變成髒數據。

RC 的作用是當A修改的數據沒有提交，B 讀取不到A 已經修改的數據，此時解決了髒讀，但是一旦A的數據提交，B會立刻讀取到A的數據，此時。讀取到的數據將會產生不一致現象，此時成爲重複讀。

RR 客戶端A查看數據，客戶端B修改數據並提交，客戶端A此時查詢到的數據和之前B沒有修改查詢到的數據一致，不可重複讀解決，可重複讀的隔離級別下使用了MVCC機制，A事物中讀取的是記錄的快照版本，而非最新的版本,B事物的更新是創建了一個新版本來更新，不同事物的讀和寫是分離的。

SZ 同一時刻只能查看一張表，表被鎖了，因此不會出現幻讀，但此時併發低，很少用到。

7 redo 日誌相關

1 redo log 日誌刷新

1代表實時刷新 （默認配置）
0每隔1秒刷新一次
2交由操作系統管理（判斷當前的繁忙程度來進行刷新）

2 innodb_log_buffer_size

innodb_log_buffer_size 確保有足夠大的日誌緩衝區來保存髒數據在被寫入到日誌文件之前，因此其設置也不應過大，明智的做法是設置爲1M到8M，一個大的日誌緩衝允許大型事物運行而不需要再事物提交之往磁盤上寫日誌，因此，除非有大型事物，否則沒有必要如此。

3 redo 磁盤上的大小

決定了redo 的切換頻率，默認爲48M，一方面不能設置得太大，如果設置得很大，在恢復時可能需要很長時間，另一方面又不能太小，否則可能導致一個事務的日誌需要多次切換重做日誌文件。在32位計算機上日誌文件的合併大小必須小於4BG，默認是5M，值越大，在緩衝池中越少需要檢查點刷新行爲，以節約磁盤I/O，但其崩潰恢復也會更慢

4 innodb_log_files_in_group

在日誌組中日誌文件的數量，innodb以循環的方式寫入，如果此時設置爲1，則可能會導致redo日誌覆蓋，從而影響恢復，建議選擇默認設置。

5 innodb_max_dirty_pages_pct

這是一個範圍從0到100 的整數，默認是75.innodb的主線程試着從緩衝池寫頁面，使得髒頁的百分比不超過這個值，如果你有SUPER權限，則可以在運行過程中進行修改。

8 MySQL 登陸相關

1 交互式等待時間

2 非交互等待時間

此處如果設置過大，則會造成大量的鏈接，導致新的鏈接不能進入，從而影響系統的性能

3 最大鏈接數

默認是151 個鏈接

4 用戶鏈接數

對於mysql服務器最大連接數值的設置範圍比較理想的是：服務器響應的最大連接數值佔服務器上限連接數值的比例值在10%以上，如果在10%以下，說明mysql服務器最大連接上限值設置過高。

9 二進制日誌相關

1 二進制日誌記錄格式

默認是statement
3種格式：
1 statement 記錄SQL語句，其日誌記錄量小，節約磁盤IO空間但其必須要記錄上下文信息，保證在從服務器上執行結果和主服務器上相容，對一些非正確性函數無法進行正確複製，可能造成mysql複製的主備服務器數據不一致。
2 row * 以行記錄的方式存在，推薦使用
使mysql主從複製更加安全，對每一行的數據修改比基於段的複製高效，由於誤操作修改數據庫信息，且沒有備庫可恢復時，可用過對日誌數據操作反向處理回覆數據，但其機理日誌量較大

binlog_row_image = [FULL|MINMAL|NOBLOB]
查看binlog_row_image參數的默認值：

FULL：記錄修改行的所有列數據
MINMAL：僅記錄修改行中有發生數據變化的列，
NOBOLB：和full方式類似，僅僅當blog和text 這些列進行修改是時，不會記錄這些屬性的列

3 mixed 過度版 混合日誌格式
特點：根據sql語句由系統決定基於段和基於行的日誌格式中進行選擇

2 二進制日誌刷新方式binlog 日誌的刷新

1 代表事實刷新
0 代表交由操作系統刷
n代表n個事務刷新一次

默認是交由操作系統刷新，可進行修改：

3 binglog文件大小

如果binlog 文件大小過小，則會產生多個binlog文件，如果設置過大則恢復不易

4 binlog 使用內存大小

binlog使用內存的大小

binlog 使用內存的最大尺寸，（針對事物語句）
如果事物需要的內存超過此字節，則服務器會生成：ERROR 1197 (HY000): Multi-statement transaction required more than，其最低是4096，推薦的最大值設置爲4GB，因爲目前的mysql當二進制日誌位置大於4GB不會生效。

max_binlog_stmt_cache_size 針對非事物語句，當發現Binlog_cache_disk_use或者Binlog_stmt_cache_disk_use比較大時就需要考慮增大cache的大小

5 二進制日誌的過期時間

用於設置日誌日誌多少時間過期

11 慢查詢相關

mysql的慢查詢日誌是mysql提供的一種日誌記錄，用來記錄在mysql中響應時間超過閾值的語句，具體是指運行時間超過long_query_time的語句，默認是10S，及運行10秒以上的語句時慢查詢語句。
一般來說，慢查詢發生在大表，且查詢條件的字段沒有建立索引，此時，要匹配查詢條件的字段會進行全表掃描。

1 開啓慢查詢

2 查看慢查詢時間

3否記錄沒有利用索引的查詢

默認是OFF，設置爲ON表示會記錄沒有利用索引的查詢，一般在性能調優時會暫時開啓

12 表緩存相關

1打開文件數量，是該系統的實際值

2 查看打開表緩存大小

3 從服務器發送或接收的最大數據包長度

4 如果內存的臨時表超過該值，mysql自動將它轉換爲硬盤上的MYISAM表，如果你執行許多高級group by 查詢並且有大量內存，則可以增加tmp_table_size的值

5 該變量設置內存表可以增大到的最大空間大小，該變量用來計算內存表的max_rows 值，在已有的表上沒有效果，除非重建表。

三 mysql 其他查詢

1 線程相關

A 查看當前的線程

B 查看總線程

cached 被緩存的線程
running 處於激活狀態的線程
connected 當前鏈接的線程
create 被創建的線程

2詢吞吐量

由 Questions 指標帶來的以客戶端爲中心的視角常常比相關的Queries 計數器更容易解釋。作爲存儲程序的一部分，後者也會計算已執行語句的數量，以及諸如PREPARE 和 DEALLOCATE PREPARE 指令運行的次數，作爲服務器端預處理語句的一部分。

3 碎片的查詢和整理

產生碎片的原因
1 主要是因爲對大表進行刪除操作
2 其次是隨機方式插入新數據，可能導致輔助索產生大量碎片

碎片量爲
data_length+index_length-rows*avg_row_length

整理碎片的方式
1 整理表

2 導入導出

4 MySQL默認查找配置文件順序

5 MySQL 統計信息的收集方法

兩個結果不一致，表明統計信息不正確
收集統計信息
1 重啓mysql 服務
2 遍歷tables.

6 設置訪問頁被放置到熱端的時間

如果用戶預估自己的活躍的熱點數據不止63%，那麼在執行SQL語句之前，還可以通過pct 來減少熱點數據被刷新出來的概率。
LRU 列表用來管理已經讀取的頁，當數據庫剛啓動時，LRU列表時空的，及沒有任何的頁，這時頁都存放在free列表中，當需要從緩衝池中分頁時，首選從free列表中查找是否有可用的空閒頁，若有，則將該頁從free列表重刪除，放入到LRU列表中，當頁從LRU列表的old部分加入到new部分時，稱此時發送我那個的操作爲page made young ，而因爲innodb_old_blockes_time的設置而導致頁沒有從old部分移動到new部分的操作成爲page not made young，

Show engine innodb status顯示的不是當前的狀態，而是過去某個時間範圍內innodb存儲引擎的狀態。

Innodb 1.2 版本開始，可以通過使用innodb_buffer_pool_stats 來觀察緩衝池的運行狀態

7 MySQL執行計劃分析

先看type，如果當type爲all時，表示爲全表掃描，後面的rows表示是全表的數據總行，
如果type不爲all，則查看rows，掃描多少行數據，再看key ，key 表示可能用到的索引，最後看extra
數據庫的優化，大多是優化I/O

其值大於0.5，則可以作爲索引，越接近1越好