一 簡介：今天我們講講如何利用5.7的sys新庫進行問題的排查
二 描述
1 Sys庫所有的數據源來自：performance_schema和information_schema。目標是把performance_schema的把復雜度降低，讓DBA能更好的閱讀這個庫里的內容。讓DBA更快的了解DB的運行情況。
2 mysql對於系統性能和sql語句狀態的收集是非常少的,基本排查手段都要靠經驗判斷,5.7的sys特性能周期性的收集系統狀況和sql的狀態,有利於DBA更好的對問題進行判斷,集成了視圖,本身不存儲數據
三 具體sql語句應用
一 IO相關
1查看表訪問量前10top信息
select table_schema,table_name,sum(io_read_requests+io_write_requests) io from schema_table_statistics group by table_schema,table_name order by io desc limit 10;
2 查看文件訪問量前10top信息
select file,avg_read+avg_write as avg_io from io_global_by_file_by_bytes order by avg_io desc limit 10;
3 查看具體表的操作類型延遲統計
select * from schema_table_statistics where table_schema ='' and table_name=''(增刪查改操作延時)
4 慢查詢掃描全表
select * from schema_tables_with_full_table_scans（最新的全表掃描相關信息）
5 通過mysql線程 ID 來跟算
1 iotop定位具體的mysql線程 獲得線程的PID
2 select name,type,thread_id,processlst_id from performance_schema.threads where thread_os_id='PID'; ->一般用戶導致的調研的線程就是one_connections
3 select * from sys.processlist where processlist_id='' 或者直接show processlist過濾
小結 可以代替pt-iopfile工具,直接查詢非常方便定位IO問題
二 內存相關
select * from innodb_buffer_stats_by_table
select * from innodb_buffer_stats_by_schema
1 分別從庫和表角度分析占用內存比,分析內存問題
select event_name, SUM_NUMBER_OF_BYTES_ALLOC from pefromance_schema.memory_summary_by_thread_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 20;
2 從線程角度分析內存占用
event_name | SUM_NUMBER_OF_BYTES_ALLOC |
+-------------------------------------------+---------------------------+
| memory/sql/Filesort_buffer::sort_keys | 13942381710536 |
| memory/memory/HP_PTRS | 5413962191080 |
| memory/sql/thd::main_mem_root | 1095525347280 |
| memory/mysys/IO_CACHE | 471119309576 |
注意點:1 mysql默認是無法查詢到相關內存數據的,需要打開數據收集,具體執行語句
UPDATE setup_instruments SET ENABLED = 'YES',TIMED = 'YES' where NAME like '%memory%';
2 配置文件添加
performance_schema=1
performance_schema_instrument='%=on'
三 等待操作
1 select * from waits_global_by_latency（事件等待）
2 select * from innodb_lock_waits （鎖等待,未來information的相關表將被廢棄）
四 應用程序角度
select * from host_summary order by (file_io_latency,total_connections,current_memory)
小結 這個視圖可以從內存 IO,sql執行延遲等角度綜合進行排查,定位具體的應用主機
五 總結
1 定位具體的host,user,schema,table,DML操作 能幫你快速的解決大多數問題
2 從用戶和系統內存兩方面來分析內存問題
3 缺少cpu級別的信息收集,比較遺憾