innodb data written / read
計算每秒questions
數據庫性能變化趨勢判斷服務器資源是否足夠
select benchmark(100000000, 'call mysp()'); #第一個函數調用多少次，第二個函數執行的sql。 注意響應時間
select benchmark(100000000, ‘select 1+1'); #判斷服務器性能，做基准測試。然后監控系統監控每秒指標，響應時長。
mysqladmin ext | grep -i trx #判斷事物id,percona版本才有，官方版本查看information_schema查看trx信息&innodb status
select * from QUERY_RESPONSE_TIME; percona查看sql區間響應耗時
idle = 100% - %user - %sys - %iowait
iowait越高說明當前IO性能差，io負載高。
真正可用的內存有：free + cached + buffer
IOwait高可能是buffer poll太小導致讀盤多，或者沒索引走全表掃描。
常用工具：top、free、ps、df、sysstat、（sar、mpstat、iostat）\dstat\omstaat、netstat、oprofile、systemtap、perf
iotop
sysstat（sar、mpstat、iostat）\ dstat \ omstaat \ iotop
select case when sum(DATA_LENGTH)+sum(INDEX_LENGTH) is NULL then 0 else sum(DATA_LENGTH)+sum(INDEX_LENGTH) end as innodb_tabsize from information_schema.TABLES where TABLE_SCHEMA not in ('information_schema','mysql','performance_schema','test') and ENGINE = 'InnoDB';#統計is庫
實際可用內存為buffer/cache + free
釋放 swap：swapoff/swapon #負載高容易hang
sar -u #CPU利用率
sar -d #塊設備，IO利用率,rd_sec/s wr_sec/s （讀寫扇區）每個扇區是512字節 ，可計算相應多少字節，可用iotop定位。await,io等待。 svctm本次io響應時間， util使用率ssd不用太擔心，機械是串行寫入，ssd可並行寫入。
sar -r #磁盤利用率 %memused 查看是否平穩。
vmstat:
vmstat -S m 1 #只是內存用兆方式顯示，1秒刷新。
r：在運行隊列中等待未執行的進程數 。
b：在等待io的進程數 ，不能被中斷的進程。
b：在等待io的進程數 ，不能被中斷的進程。
表示正在發生的swap
bi = block in to mem read from disk，io讀
bo = block out from mem write to disk，io寫
si = block in to swap in from disk，swap讀（單位是block 4kb）
so = block out from swap out to disk，swap寫（單位是block 4kb）
swpd列：總的swap
us = %user
sy = %sys
id = %idle #cpu空閑率
wa = %iowait
st = 虛擬機使用的cpu資源
cpu比較高基本是沒有索引引起的
iostat -d -x 1
r/s+w/s=iops
await：總的服務時間包括隊列時間。通常大於svctm
svctm:服務時間
util:util比較高說明當前io占比高。如果是磁盤陣列，因為可以並行，所以不太靠譜。ssd並行IO更好，每秒一兩百m，也不太靠譜。
io不高而svctm,util比較高，說明服務器性能比較差。
avgqu-sz是平均請求隊列的長度
iops \ iowait \ util #查看io瓶頸
計算機械盤iops 10000轉/60s=167(iops),多盤可以並行*盤數*Linux（4kb）
配置最大連接數，如果每個線程配置的cache比較大，內存溢出導致服務不可用。
mysql監控：
1. 每秒活躍DML（sql）數，/事物數/請求數/當前並發連接數/平均響應時長
2.鎖：表鎖，行鎖，鎖等待，死鎖。#最大行鎖時間，發生次數。
3，內存：buffer/cache命中率、內存如果等待釋放（如果內存等待釋放，mysqld可能需要增加buffer）。
4.事物：事物ID增長，有沒有持續穩定增長。unpurged 未清除的歷史事物積壓有多少。
5.慢查詢：平均耗時，平均次數
mysqladmin ext|grep -i 'Innodb_buffer_pool_wait_free'
3個等待事件狀態，如果有發生需要關注：
1.Innodb_buffer_pool_wait_free #innodb等待更多的buffer、page釋放，比較嚴重，說明當前buffer使用很厲害，沒有空閑。
2.innodb_log_waits #redo log 需要切換，沒有足夠空間。
3.table_locks_waited #請求表鎖的時候沒有立刻獲得表鎖，需要等待。
慢日志，看哪種sql發生最多，優先解決，其次解決耗時最長。
查看mysql狀態：
1，show 【full processlist】 #sending data,超過1秒請求數據量太大。
2，show 【global】 status like"handler%" #讀隨機下一行，發生全表掃描或者全表join， 產生臨時表甚至臨時文件，發生多少次。
鎖監控：
表鎖
1.table_locks_immediate #立刻獲得的表鎖
2.table_locks_waited #發生的請求需要等待
行鎖
1.innodb_row_lock_current_waits #當前等待的行鎖數量
2.innodb_row_lock_time #從實例啟動到當前，請求行鎖總耗時
3.innodb_row_lock_time_avg #請求行鎖平均耗時
4.innodb_row_lock_time_max #請求行鎖最久耗時（ms，可以對此事物加監控）
5.innodb_row_lock_waits #行鎖發生次數
show processlist；
copying to tmp table #沒有索引（條件鏈沒有合適索引）
總耗時，是否發生全表掃描，全表join，掃描的數據頁有12252
select count（*） 通常優先訪問輔助索引。
dstat\orzdba.pl #mysql兩個不錯的監控工具
監控事物ID的增長
這兩種表示沒有利用索引發生的讀
show global status；或者mysqladmin extended-status 縮寫、簡寫模式 mysqladmin ext
Aborted_clients #由於客戶端沒有正確關閉連接導致客戶端終止而中斷的連接數。
Binlog_cache_disk_use #無法使用內存保存binlog，需要使用基於磁盤的臨時文件次數。
binlog-cache-size #將內存中的binlog寫到磁盤之前緩沖，提升寫入。如果太小導致比較大的事物無法將binlog內存，會用到磁盤。
Binlog_stmt_cache_disk_use &Binlog_stmt_cache_use #非事務性的用到磁盤文件（以myisam為主）
Created_tmp_disk_tables #用到磁盤表
Binlog_cache_use #使用臨時二進制日志緩存的事務數量，越多越好。
Connections #試圖連接到(不管是否成功)MySQL 服務器的連接數
Created_tmp_tables #服務器執行語句時自動創建的內存中的臨時表的數量。如果 Created_tmp_disk_tables 較大,你可能要增加 tmp_table_size 值使臨時表基於內 存而不基於硬盤。
Created_tmp_disk_tables #服務器執行語句時在硬盤上自動創建的臨時表的數量。
tmp-table-size & max-heap-table-size #允許在內存里面最大的臨時內存是多少。
Created_tmp_disk_tables/(Created_tmp_disk_tables+Created_tmp_tables)*100% #高於10%的話,就需要注意，適當 調高 tmp_table_size ，但是不能設置太大,因為它是每個 session 都會分配的, 可能會導致 OOM
Handler_commit#內部交語句數。
Handler_read_first #索引中第一條記錄被讀的次數。如果較高,它表明服務器正執行大量全索引掃 ; 例如,SELECT id FROM table,假定 id 有索引。
Handler_read_key #根據索引讀取某一行的請求次數，例如：select … where id = 1024;
Handler_read_last #order by倒序讀總次數
Handler_read_next #按照索引順序讀下一行的請求數。如果你用范圍約束或如果執行索引掃描來查詢索引列，該值增加。
例如：select * from t where id = 1024 order by id limit 5; 先read-key 然后4條是read-next
Handler_read_prev，例如倒序：select id from t where id = 1024 order by id DESC limit 5;往回讀增加4
Handler_read_rnd #根據固定位置讀一行的請求數。如果你正執行大量查詢並需要對結果進行排序該值較高，說明可能使用了大量需要MySQL掃描整個表的查詢或沒有正確使用索引。例如select * from t limit 1000,1; 數據庫層面邏輯讀
Handler_read_rnd_next #在數據文件中讀下一行的請求數。如果你正進行大量的表掃描，該值會較高。通常說明你的表索引不正確或寫入的查詢沒有利用索引。例如根據非索引列排序后再讀取多少條記錄（甚至發生基於磁盤的臨時文件進行排序，先從數據庫取到數據，再進行二次排序 select * from t order by non_key_col limit 100;
Handler_read_rnd&Handler_read_rnd_next沒有利用索引應該重點關注下。
如果懷疑某些SQL效率比較差：
flush status;#先將session 值清空
select xxx； #show status like 'handler_read%';
Innodb_buffer_pool_pages_data #在innodb buffer_pool中有多少個page用來緩存熱點數據的，與InnoDB status的Database pages是同一個意思
Innodb_buffer_pool_pages_dirty #表示用來緩存臟頁的page 數量
Innodb_buffer_pool_pages_free #沒有用到的page數量
Innodb_buffer_pool_pages_total #page總數
Innodb_buffer_pool_read_requests #InnoDB已經完成的邏輯讀請求數。（Innodb所有讀操作的次數）
Innodb_buffer_pool_reads# 讀操作不能從Innodb buffer pool中完成讀取，需要從磁盤中讀取數據的次數。
Innodb_buffer_pool_wait_free #innodb buffer pool不夠用了等待把熱點數據或臟頁的buffer pool釋放次數，該參數大於0比較嚴重
Innodb_buffer_pool_write_requests #一共發生的寫請求次數
Innodb_data_writes #實際物理寫次數
Innodb_data_read #從啟動到現在已經讀取的數據數量（字節）
Innodb_data_written #從啟動到現在已經寫入的數據量（字節）。
Innodb_log_waits #我們必須等待的時間，因為redo日志緩沖區太小，我們在繼續前必須先等待對它清空。
所有帶wait關鍵字都需要引起注意。
鎖：
Innodb_row_lock_current_waits #當前等待行鎖的行數。
Innodb_row_lock_time #從啟動到現在，行鎖定花費的總時間，單位毫秒。
Innodb_row_lock_time_avg #行鎖定的平均時間，單位毫秒。
Innodb_row_lock_time_max #行鎖定等待的最長時間，單位毫秒（一般建議設置為10秒）。這個值太大的話，可以考慮調低 innodb_lock_wait_timeout 值
Open_tables #當前正在用打開表空間文件，打開表的數量。如果當前1個表被並發10個線程訪問，每個線程打開次數都算1.
Open_table_definitions #被緩存的.frm文件數量，一般該值就是表的數量。
table-open-cache，table-definition-cache #如果表cache不夠大，需要關閉歷史表才可以打開新表。
flush tables #把正在打開的表關閉，這種操作會產生mdl鎖，盡量不要操作。備份時的FTWRL也是將所有表重新打開一遍
Opened_tables #歷史總共打開次數，如果Opened_tables較大，table_open_cache 值可能太小。
no-auto-rehash #如果表太多，客戶端沒使用該參數，每次打開都會統計表信息。
Queries #已經發送給服務器的查詢的個數，通常指DML
Questions #發送到服務器的請求次數。
和性能有關：
Select_full_join #沒有使用索引的聯接的數量。如果該值不為0,你應仔細檢查表的索引，可以查慢日志。
Select_scan #對一個表進行完全掃描的聯接的數量
Slow_queries #查詢時間超過 long_query_time秒的查詢的個數
Sort_merge_passes #對一個結果進行排序時，又不能基於索引排序，需要多次 遞進排序才能得到最終結果。排序算法已經執行的合並的數量，每次合並都要加1。如果這個變量值較大，應考慮增加sort_buffer_size系統變量的值，盡量不要產生基於磁盤的臨時文件。
default_tmp_storage_engine #5.6開始可以強制定義產生的臨時表使用引擎
Table_locks_immediate #立即獲得的表的鎖的次數，絕大多數指的是myisam引擎，innodb 發生dml時做DDL操作也會發生表鎖。
Table_locks_waited #不能立即獲得的表的鎖的次數。如果該值較高，並且有性能問題，你應首先優化查詢，然后拆分表
Threads_cached #當前緩存了多少個線程
Threads_connected #當前正在打開的連接的數量。
Threads_created #創建用來處理連接的線程數。如果Threads_created較大，你可能要增加thread_cache_size值。緩存訪問率的計算方法Threads_created/Connections。
Threads_running #激活的（非睡眠狀態）線程數
innodb_thread_concurrency #innodb內部可以允許並發的數量，設置為邏輯CPU數量即可。