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 語句，在空間層面作了優化，加入了一種新的排序方式--優先隊列，這種方式採用堆棧排序實現。詳情請見：http://www.javashuo.com/article/p-gazptlas-z.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 用戶連接數

其中Threads_connected 表示用戶鏈接數

對於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越好