• 效能指標

show engine innodb status \G

mysql> show engine innodb status \G
---
LOG
（Innodb 事務日誌相關資訊，包括當前的日誌序列號（Log sequence number），已經重新整理同步到那個序列號，最近的check point到那個序列號了。除此之外，還顯示了系統從啟動到現在已經做了多少次check point，多少次日誌重新整理。）
---
 

（注：小括號為官方解釋。）
Log sequence number 2560255（當前的日誌序列號）
Log flushed up to   2560255（重新整理到日誌重做日誌檔案的lsn）
Pages flushed up to 2560255（寫入磁碟的髒頁的lsn。記錄在checkpoint中）
Last checkpoint at 2560246（重新整理到磁碟的lsn）
0 pending(掛起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

解析：

• Log sequence number：日誌序列號：現在已經產生到的日誌量（位元組）
  
  • 不同時刻的lsn的值的差值/時間差==日誌的產生速度
• Log flushed up to：刷出去了多少日誌
  
  • Log sequence number - Log flushed up to== 當前logbuffer的值
  • 所以，此值應<<1M
  • 不同時刻的差值/時間間隔==日誌的寫入速度
• Pages flushed up to
  
  • Log sequence number - Pages flushed up to 值很小，說明髒頁寫入的很快
• Last checkpoint at：檢查點。系統啟動的時候，日誌恢復的起點，肯定比Pfut的值低。防止系統崩
  
  • Log flushed up to - Last checkpoint at == 系統要恢復的日誌數
  • Pages flushed up to - Last checkpoint at == checkpoint的跟進速度，如果大的話，說明checkpoint需要增大。

問：有5個2個G的日誌，Log flushed up to - Pages flushed up to 的值必須保證至少是多大？
答：6個G。因為，當前用著一個，必須保證想覆蓋的下一個是寫進去的，所以，只能是3個日誌沒寫進去，即6個G。

四個引數能反應出來什麼

1.日誌的生成速度？

• 不同時刻的Log sequence number的值的差/時間差==每秒生成的日誌量

2.日誌的寫入速度？

• Log flushed up to

3.髒頁的寫入速度？

• Log flushed up to - Pages flushed up to ==髒頁的寫入速度

4.資料庫的啟動時間是多少？

• 啟動時要回滾的日誌數

Checkpoint詳解

引子

checkpoint是一個內部事件，這個事件啟用以後會觸發資料庫寫程序(DBWR)將資料緩衝(DATABUFFER CACHE)中的髒資料塊寫出到資料檔案中。

check point是做什麼的

在資料庫系統中，寫日誌和寫資料檔案是資料庫中IO消耗最大的兩種操作，在這兩種操作中寫資料檔案屬於分散寫，寫日誌檔案是順序寫，因此為了保證資料庫的效能，通常資料庫都是保證在提交(commit)完成之前要先保證日誌都被寫入到日誌檔案中，而髒資料塊則儲存在資料快取(buffer cache)中再不定期的分批寫入到資料檔案中。也就是說日誌寫入和提交操作是同步的，而資料寫入和提交操作是不同步的。這樣就存在一個問題，當一個數據庫崩潰的時候並不能保證快取裡面的髒資料全部寫入到資料檔案中，這樣在例項啟動的時候就要使用日誌檔案進行恢復操作，將資料庫恢復到崩潰之前的狀態，保證資料的一致性。檢查點是這個過程中的重要機制，通過它來確定，恢復時哪些重做日誌應該被掃描並應用於恢復。

一般所說的checkpoint是一個數據庫事件(event)，checkpoint事件由checkpoint程序(LGWR/CKPT程序)發出，當checkpoint事件發生時DBWn會將髒塊寫入到磁碟中，同時資料檔案和控制檔案的檔案頭也會被更新以記錄checkpoint資訊。

作用

checkpoint主要2個作用：

• 保證資料庫的一致性，這是指將髒資料寫入到硬碟，保證記憶體和硬碟上的資料是一樣的;

• 縮短例項恢復的時間，例項恢復要把例項異常關閉前沒有寫出到硬碟的髒資料通過日誌進行恢復。如果髒塊過多，例項恢復的時間也會很長，檢查點的發生可以減少髒塊的數量，從而提高例項恢復的時間。

  通俗的說checkpoint就像word的自動儲存一樣。

Checkpoint所做的事情

將緩衝池（buffer pool）中的髒頁刷回磁碟。每次重新整理多少頁到磁碟，每次從哪裡取髒頁，以及什麼時間觸發Checkpoint。在InnoDB儲存引擎內部，Checkpoint負責這些事。

checkpoint分類

有2種Checkpoint：

• Sharp Checkpoint（完全檢查點）
• Fuzzy Checkpoint（模糊檢查點）

checkpoint的具體解釋

1.Sharp Checkpoint（完全檢查點）

資料庫關閉時，會將所有的髒頁都重新整理回磁碟，這是預設的工作方式。引數 innodb_fast_shutdown=1

2.Fuzzy Checkpoint（模糊檢查點）

但是若在資料庫執行時也使用完全檢查點，那資料庫的可用性就會受到很大影響。
所以，在InnoDB儲存引擎內部使用Fuzzy Checkpoint進行頁的重新整理，即只重新整理一部分髒頁，而不是將所有的髒頁刷回磁碟。

Fuzzy checkpoint工作過程

• 先讀LRU list，把一部分髒頁（相對冷的）寫到磁碟上；
• 再找Frush list，把最早髒的寫到磁碟上。（更新檢查點）

Fuzzy Checkpoint又分為4種

• ①Master Thread Checkpoint
• ②FLUSH_LRU_LIST Checkpoint
• ③Async/Sync Flush Checkpoint（非同步/同步 flush檢查點）
• ④Dirty Page too much Checkpoint

1）Master Thread Checkpoint

對於Master Thread 中發生的Checkpoint，差不多以每秒或每十秒的速度從緩衝池的髒頁列表中重新整理一定比例的頁回去磁碟。這個過程是非同步的，即此時InnoDB儲存引擎可以進行其他的操作，使用者查詢執行緒不會阻塞。
–》即：常規性的fuzzy checkpoint，寫入操作不阻塞使用者執行緒

2）FLUSH_LRU_LIST Checkpoint

FLUSH_LRU_LIST Checkpoint是因為InnoDB儲存引擎需要保證LRU列表中需要有差不多100個空閒頁可供使用。在innodb1.1X版本以前，需要檢查LRU列表中是否有足夠的可用空間操作發生在使用者查詢執行緒中，顯然會阻塞使用者的查詢操作。若沒有100個可用空閒頁，那麼innodb會將LRU列表末端的頁移除。如果這些頁中有髒頁，那就要進行Checkpoint，而這些頁是來自LRU列表的，因此成為FLUSH_LRU_LIST Checkpoint。
–》即：Flush lru list checkpoint：flush list上的髒頁數量超過閾值；會阻塞使用者執行緒。

3）Async/Sync Flush list Checkpoint

（在資料庫的報錯日誌裡能夠看到！）
Async/Sync Flush list Checkpoint指的是重做日誌檔案不可用的情況，這時需要強制將一些頁重新整理回磁碟，而此時髒頁是從髒頁列表中選取的。若將已經寫入到redo log的LSN（Log sequence number）記作redo_lsn，將已經重新整理回磁碟最新頁的LSN記為checkpoint_lsn，則可定義：
redo_lsn - checkpoint_lsn == checkpoint_age
又定義：
async_water_mark==75% * total_redo_log_file_size
sync_water_mark==90% * total_redo_log_file_size
假設每個redo log的大小是1G，並且定義兩個redo log，則redo log總共2G。
則，async_water_mark=1.5G，sync_water_mark=1.8G。則：

• ① checkpoint_age< async_water_mark 時，不需要重新整理任何髒頁到磁碟；
• ② **async_water_mark < checkpoint_age<
  sync_water_mark**（即：有25%的日誌能被覆蓋時） 時，觸發Async Flush，從Async Flush
  列表中重新整理足夠的髒頁回磁碟。最終滿足①；
• ③ checkpoint_age > sync_water_mark
  時（即有90%的日誌能被覆蓋時），極少發生，除非設定的redo log太小，並且在進行類似LOAD DATA的BULK
  INSERT操作。此時觸發Sync Flush操作，從Flush列表中重新整理足夠的髒頁回磁碟，使得重新整理後滿足①。

注意：在較早版本的innodb中，Async Flush list Checkpoint會阻塞發現問題的使用者查詢執行緒，而Sync Flush list Checkpoint會阻塞所有的使用者查詢執行緒，並且等待髒頁重新整理完成。
但在5.6版本（即innodb1.2x版本）開始，這部分的重新整理操作同樣放入到了單獨的Page Cleaner Thread中，所以不會再阻塞使用者查詢執行緒了。

4）Dirty Page too much Checkpoint

即髒頁的數量太多，導致innodb儲存引擎強制進行 檢查點。
目的：還是為了保證buffer pool緩衝池中有足夠的可用的頁。
可由引數 innodb_max_dirty_pages_pct 控制。

innodb_max_dirty_pages_pct引數官方文件解釋：

innodb_max_dirty_pages_pct_lwm引數解釋：

發現，該引數值預設為75，即：當buffer pool中髒頁的數量佔據75%時，強制進行Checkpoint，重新整理一部分的髒頁到磁碟。
（在innodb1.0x以前，該引數預設是90，之後的版本都為75。）

能夠觸發寫操作的一些因素

1. 常規性寫入操作：（影響不大）

• 1.master thread
• 2.io write 寫入執行緒
• 3.每次寫入的量 –》怎麼控制？ 增加寫入執行緒的數量。

2. flush 列表太大

會觸發對使用者執行緒的阻塞

增加後：頻繁的寫。（影響不大）

3. 可以覆蓋的日誌太少了：（影響大）

• 增加日誌的大小和組的數量
• 避免同步和非同步
• 髒頁的總量【一般調成90%】（影響大）

防止因為寫入操作而導致系統hang住！

控制寫入操作

1.控制每次寫入的量

• 1.innodb_io_capacity（可以調節每次寫入的資料量）
  
  • 假設我們使用閃盤，io可以達到50萬iops
  • 【IOPS：Input/Output Operations Per Second，即每秒進行讀寫（I/O）操作的次數，多用於資料庫等場合，衡量隨機訪問的效能。】
    200,300,400,500
    看一下髒頁的數量是否還是過多（指標）
• 2.innodb_lru_scan_depth
  
  • 每次查詢髒頁的深度
• 3.調整log file的大小和組數
• 4.髒頁的比例：75%（預設）、90%（推薦）（但系統崩潰的時候恢復時會比較慢）…

如何來確認系統的寫入操作是大還是小

1、如何來調整寫入這個操作？

• innodb_io_capacity（容量）–》調大可加大髒頁寫入速度
• innodb_lru_scan_depth –》調大可加大髒頁寫入速度
• 增加log file組數和大小
• 加大或者縮小innodb_max_dirty_pages_pct

2、為什麼增大或者減小寫入操作？

• 1.我們要確認系統是寫入還是讀取為主的系統（調不調）
  如果是以寫入為主的系統，就需要加大上面的相關引數。
• 2.觀察我們的系統的io狀況【iostat -x 1】【%util達到70%左右、w/s也很好，說明引數調的很好】
  來確認調整的合理程度。（調多少）
• 3.通過double write 寫入來監控我們的系統的寫入壓力夠不夠（讓寫入壓力大一些好）

（如果w/s太大，就是寫的太快，此時就應降低寫功能）

wrqm/s 反映的是double write的功能
InnoDB_dblwr_writes：寫的次數
InnoDB_dblwr_pages_written：寫的頁數
pages：writes的值能夠看一次寫多少頁】

• 4.通過日誌產生速度和髒頁重新整理速度的差值
• 5.髒頁和pool的比值（看此時髒頁的數量大小）

引數innodb_fast_shutdown髒頁重新整理控制引數

在關閉時，引數innodb_fast_shutdown影響著表的儲存引擎為innodb的行為。該引數可取值為0、1、2，預設值為1。

• 0：表示在MySQL資料庫關閉時，innodb需要完成所有的full purge（）和merge（合併） insert buffer
  ，並且將所有的髒頁重新整理回磁碟。這需要一段時間，有時甚至需要幾個小時來完成。如果在進行innodb升級時，必須將這個引數調為0，然後再關閉資料庫。
• 1：是引數innodb_fast_shutdown的預設值，表示不需要完成上述的full purge和merge
  insert操作，但是在緩衝池中的一些資料髒頁還是會重新整理回磁碟。
• 2：表示不完成full purge和merge insert
  buffer操作，也不將緩衝池中的資料髒頁寫回磁碟，而是將日誌都寫入日誌檔案。這樣不會有任何事務的丟失，但是下次MySQL資料庫啟動時，會進行恢復操作。

當正常關閉MySQL資料庫時，下次的啟動應該會非常“正常”。但是如果沒有正常地關閉資料庫，比如用kill 命令關閉資料庫，在MySQL資料庫執行中重啟了伺服器，或者在關閉資料庫時，將引數innodb_fast_shutdown設為了2時，下次MySQL資料庫啟動時都會對InnoDB儲存引擎的表進行恢復操作。

恢復引數 innodb_force_recovery

引數 innodb_force_recovery 影響了整個innodb儲存引擎恢復的狀況。該引數值預設為0，代表當發生需要恢復時，進行所有的恢復操作，當不能進行有效恢復時，如資料頁發生了corruption（損壞），mysql資料庫可能發生宕機（crash），並把錯誤寫到錯誤日誌去。

但是，在某些情況下，可能並不需要進行完整的恢復操作，因為使用者自己知道怎麼恢復。比如在對一個表進行alter table操作時發生意外了，資料庫重啟時會對innodb表進行回滾操作，對於一個大表來說這需要很長時間，可能是幾個小時。這時使用者可以自行進行恢復，如可以把表刪除，從備份中重新匯入資料到表，可能這些操作的速度要遠遠快於回滾操作。

引數innodb_force_recovery 還可以設定為6個非零值：1~6。大的數字包含了前面所有小數字表示的影響：

• 1：SRV_FORCE_IGNORE_CORRUPT：忽略檢查到的corrupt頁。
• 2：SRV_FORCE_NO_TRX_UNDO：阻止Master Thread 執行緒的執行，如Master Thread執行緒需要進行full purge操作，而這會導致crash。
• 3：SRV_FORCE_NO_TRX_UNDO：不進行事務的回滾操作。
• 4：SRV_FORCE_NO_IBUF_MERGE：不進行插入緩衝的合併操作。
• 5：SRV_FORCE_NO_UNDO_LOG_SCAN：不檢視撤銷日誌（undo log），InnoDB儲存引擎會將未提交的事務視為已提交。
• 6：SRV_FORCE_NO_LOG_REDO：不進行前滾的操作。

需要注意：在設定了引數innodb_force_recovery大於0後，使用者可以對錶進行select、create和drop操作，但insert、update和delete這類DML操作是不允許的。

前滾和回滾

如果系統因為執行了一個非常大的DML或者DDL操作，導致系統hang住，我們想斷掉這個操作，怎麼辦？
①kill thread –》要前滾

②kill process –》要回滾

資料庫效能監控

1.效能指標

怎麼來監控？
（1）通過show engine innodb status \G 來看log的部分：

Log sequence number 2560255    （當前的日誌序列號）
Log flushed up to   2560255    （重新整理到日誌重做日誌檔案的lsn）
Pages flushed up to 2560255    （寫入磁碟的髒頁的lsn。記錄在checkpoint中）
Last checkpoint at 2560246    （重新整理到磁碟的lsn）
0 pending(掛起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

• 1
• 2
• 3
• 4
• 5
• 6

（2）通過一些引數來看：

• innodb_dblwr_pages_written：看寫的快慢
• Com_select
• Com_delete
• Com_update -》增刪改查的統計量
• Com_commit -》提交的事務數
• InnoDB_dblwr_writes：寫的次數
• InnoDB_dblwr_pages_written：寫的頁數
  【pages：writes的值能夠看一次寫多少頁】

（3）iostat
觀察系統的io狀況的命令

壓力測試的工具

• 測IO的：測出IOPS–》fifo、orion等
• 測網路的：測出吞吐量–》傳包

• 測資料庫

  • tpcc-mysql ：它自己建立業務系統，模擬業務操作，進行壓力測試。
  • loadrunner：可以模擬我們的真實的生產系統，進行壓力測試。（業務部門做的，需要開發程式設計等…）
  • tcpcopy：引流進行壓力測試。

TPCCMySQL 小工具的使用

README手冊：

1.Build binaries
     cd scr ; make ( you should have mysql_config available in $PATH)
2.Load data
  ①  create database mysqladmin create tpcc1000
  ② create tables mysql tpcc1000 < create_table.sql
  ③create indexes and FK ( this step can be done after loading data) mysql tpcc1000 < add_fkey_idx.sql
  ④ populate data
        1）simple step tpcc_load -h127.0.0.1 -d tpcc1000 -u root -p "" -w 1000 |hostname:port| |dbname| |user| |password| |WAREHOUSES| ref. tpcc_load --help for all options
        2）load data in parallel check load.sh script
3.start benchmark
    ①./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -w10 -c32 -r10 -l10800
    ②|hostname| |port| |dbname| |user| |WAREHOUSES| |CONNECTIONS| |WARMUP TIME| |BENCHMARK TIME|
    ③ref. tpcc_start --help for all options

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

常用引數：

• -w 10 –》載入10個數據倉庫就不少了！（實驗用三四個就行！）
• -h 往哪個地址
• -d 哪個資料庫

資料庫效能相關指標小結

show glabal status like ‘%wait%’;
show glabal status like ‘%thread%’;
show glabal status like ‘%abor%’;
show glabal status like ‘%question%’;
show glabal status like ‘%que%’;
show glabal status like ‘%full%’;
show glabal status like ‘%scan%’;
show glabal status like ‘%slow%’;
show glabal status like ‘%read%’;
show glabal status like ‘%write%’;
show glabal status like ‘%log%’;
show glabal status like ‘%commit%’;
show glabal status like ‘%Com%’;
QPS
TPS
buffer hit
show glabal status like ‘%disk%’;
show glabal status like ‘%max%’;
show glabal status like ‘%page%’;
show glabal status like ‘%fsync%’;

show status 看的是執行狀態，是不能調的！
show variables 看的是變數，可以調！

上面這些引數的詳解：

1.show glabal status like ‘%wait%’;

Innodb_buffer_pool_wait_free：buffer pool沒有空閒記憶體了。【如果每秒增長的值比較高 –》能覆蓋的磁碟太少了！即 髒頁太多！！】
【髒頁太多的一個最經典的指標！！！】
Innodb_log_waits：因log buffer不足導致等待的次數。

2.show glabal status like ‘%thread%’;

• Threads_cache：在快取池子裡快取了幾個。例如先建立20個執行緒放在池子裡，當短連線上來之後，就分配給它，用完就釋放
• Threads_connected：當前的連線數
• Threads_created：系統一共累計建立了多少執行緒，若此值很大，則系統頻繁的建立和斷開執行緒！則 thread_cache_size小了，容易幹（溢位）！
• Threads_running：當前活躍的執行緒的數量。一共有多少個想幹活的。

當created的值很大時：
show variables like ‘%thread%’;

看到thread_cache_size的值為9。假設有100個執行緒上來了，快取池子快取了9個，忽然斷開。則需要新建立91個執行緒。
所以，當thread_cache_size增大，可理解為池子增多了。則Threads_created的數量就會降下來了。
thread_concurrency：真正在幹活的數量。（截的圖上沒有…）
48core*2個執行緒==96個執行緒 –》cpu能夠服務的執行緒數

Threads_running和 thread_concurrency的關係

• ①running的數<64，就把concurrency設定為0
• ②running值>>128，就把concurrency設定為128（最大值）
• ③running值∈（10,200）–》嘗試調整：concurrency
  先調成60：然後算tps和qps；然後80，若發現tps和qps上升了，則好；再100，若發現tps或qps下降了，則降低，調成80就好。

我們有個限制：concurrency<=cpu的core *2/4 –》（4是能併發的處理4個執行緒）

max_connection：允許的最大連線數

預設151。最好調成三四百。
所以，當Threads_created 等於151時，就該調max_connection了。

3.show glabal status like ‘%abor%’;

被異常終止的連線的數量。

Aborted_connection的值很大時，說明被異常終止的連線的數量很多。

4.show glabal status like ‘%question%’;

描述資料庫的處理能力。

5.show glabal status like ‘%que%’;

Queries：sql查詢（增刪改）的數量。

Com_stmt_execute：累積的SQL語句的執行數量。

【發現Queryes的值與它差不多】

6.show glabal status like ‘%full%’;

select_full_join：應用到其他表，沒有使用索引的連線的數量；
select_full_range_join：應用到其他表，在引用的表中使用範圍搜尋的連線的數量。

7.show glabal status like ‘%scan%’;

Select_scan：系統全表掃描的累計值。

8.show glabal status like ‘%slow%’;

Slow_queries：慢查詢（後面會講）的數量。

slow_launch_time：2秒。
一個SQL語句的執行時間超過2秒–》認為是一個慢sql，就記錄在/mysql/data/slowmysql.log，同時slow_queries的值+1

9.show glabal status like ‘%read%’;

read往往意味著物理讀。

• Innodb_buffer_pool_reads：在buffer pool裡找值沒找到發生物理讀的累積次數。【不同時刻的差值/間隔==buffer pool每秒發生的物理讀】
• Innodb_buffer_pool_read_ahead：預讀 數是169。此值如果高的時候，就是全表掃描。
• Innodb_buffer_pool_read_requests：innodb_buffer 中總的請求數。
  
  • （buffer hit）命中率==(requests-reads)/requests
• Innodb_data_pending_reads：掛起數。資料庫系統裡面曾經出現的IO請求，但由於IO已經滿了，就會出現pending，被掛起了。

10.show glabal status like ‘%write%’;

寫請求。

• Innodb_buffer_pool_write_requests：寫請求的總數。
• Innodb_dblwr_writes：double write 寫的次數。（寫髒頁）
• innodb_log_writes：日誌寫的次數。【寫負載一般關注兩點：寫髒頁、日誌寫】
• innodb_os_log_pending_writes：日誌掛起的次數，【大了就說明：寫功能可能壞了–》cache的電池】

11.show glabal status like ‘%log%’;

Innodb_log_waits：先往log buffer裡寫，logfile裡寫redo log時，如果滿了，就會有等待。

12.show glabal status like ‘%commit%’;

Com_commit的提交數量。與rollback一起，可以算 命中率。

13.show glabal status like ‘%Com%’;

關於累計值。

經常關注的幾個：

• Com_commit：執行的commit的數量；
• Com_delete：執行的刪除數量；
• Com_insert：執行的插入數量；
• Com_select：執行的查詢數量；
• Com_stmt_execute：總的sql執行的數量。
• QPS：不同時刻的Questions的差值/時間差
  
  • QPS：Query Per Second，每秒查詢率
• TPS：（Com_rollbacl+Com_commit）/時間差
  
  • TPS：Transaction Per Second，每秒事務處理量。

14.show glabal status like ‘%disk%’;

15.show glabal status like ‘%max%’;

• ①Connection_errors_max_connections的值>0：因為超過了最大連線數而導致的錯誤，應該保持是0才正常。
• ②Max_used_connections：一定<<事務的Max_connections

16.show glabal status like ‘%page%’;

• Innodb_buffer_pool_pages_tocal：innodb buffer pool的總大小；
• Innodb_buffer_pool_pages_dirty：髒頁的數量
• Innodb_dblwr_pages_written：double write 的位元組數

17.show glabal status like ‘%fsync%’;

檔案系統。

• Innodb_data_fsyncs：是物理寫。跳過檔案系統的快取，直接往磁碟寫。一般指日誌。

一般是：資料先寫到檔案系統的快取，然後再寫到磁碟！

• Innodb_data_pending_fsyncs：寫日誌的時候的物理寫。
• Innodb_os_log_pending_fsyncs：redo log的pending fsyncs() 次數

18.show global status like ‘%dbl%’;

判斷資料庫系統繁忙度。

（現在的比值是21:1，意思就是每次寫，寫21個頁。）
注意比值：當written/writes比值為128:1時，就是寫操作比較繁忙，壓力比較大。
小於128時，就是不繁忙。

為什麼是128:1就是繁忙的？（圖解：）