MySQL執行時系統表生成的相關資料的使用
innodb_buffer_pool已佔用記憶體的明細資訊，可以按照庫\表的維度來統計
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;
SELECT
database_name,
SUM(compressed_size)/1024/1024 AS allocated_memory,
SUM(data_size)/1024/1024 AS data_memory,
SUM(is_hashed)*16/1024 AS is_hashed_memory,
SUM(is_old)*16/1024 AS is_old_memory
FROM
(
SELECT
case when INSTR(TABLE_NAME,'.')>0 then replace(SUBSTRING(TABLE_NAME,1,INSTR(TABLE_NAME,'.')-1),'`','')
else 'system_database' end as database_name,
case when INSTR(TABLE_NAME,'.')>0 then replace(SUBSTRING(TABLE_NAME,INSTR(TABLE_NAME,'.')+1),'`','')
ELSE 'system_obj' END AS table_name,
if(compressed_size = 0, 16384, compressed_size) AS compressed_size,
data_size,
if(is_hashed = 'YES',1,0) is_hashed,
if(is_old = 'YES',1,0) is_old
FROM information_schema.innodb_buffer_page
WHERE TABLE_NAME IS NOT NULL
) t
GROUP BY database_name
ORDER BY allocated_memory DESC
LIMIT 10;庫\表的讀寫統計，邏輯層面的熱點資料統計 目標表是performance_schema.table_io_waits_summary_by_table，某些文章上說是邏輯IO，其實這裡跟邏輯IO並無關係，這個表中的欄位含義是基於表，讀寫的到的行數的統計。 至於真正的邏輯IO層面的統計，筆者目前還有不知道有哪個可用的系統表來查詢。 這個庫可以很清楚地看到這個表中的統計結果是怎麼計算出來的。
基於表的讀寫的行的次數統計，這是一個累計值，單純的看這個值本身，個人覺得意義不大，需要定時收集計算差值，才具備參考意義。
以下按照庫級別統計表的讀寫情況。
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;
SELECT
database_name,
IFNULL(cast(sum(total_read) as signed),0) AS total_read,
IFNULL(cast(sum(total_written) as signed),0) AS total_written,
IFNULL(cast(sum(total) AS SIGNED),0) AS total_read_written
FROM
(
SELECT
substring(REPLACE(file, '@@datadir/', ''),1,instr(REPLACE(file, '@@datadir/', ''),'/')-1) AS database_name,
count_read,
case
when instr(total_read,'KiB')>0 then replace(total_read,'KiB','')/1024
when instr(total_read,'MiB')>0 then replace(total_read,'MiB','')/1024
when instr(total_read,'GiB')>0 then replace(total_read,'GiB','')*1024
END AS total_read,
case
when instr(total_written,'KiB')>0 then replace(total_written,'KiB','')/1024
when instr(total_written,'MiB')>0 then replace(total_written,'MiB','')
when instr(total_written,'GiB')>0 then replace(total_written,'GiB','')*1024
END AS total_written,
case
when instr(total,'KiB')>0 then replace(total,'KiB','')/1024
when instr(total,'MiB')>0 then replace(total,'MiB','')
when instr(total,'GiB')>0 then replace(total,'GiB','')*1024
END AS total
from sys.io_global_by_file_by_bytes
WHERE FILE LIKE '%@@datadir%' AND instr(REPLACE(file, '@@datadir/', ''),'/')>0
)t
GROUP BY database_name
ORDER BY total_read_written DESC;TOP SQL 統計
可以按照執行時間，阻塞時間，返回行數等等維度統計top sql。
另外可以按照時間篩選last_seen，可以統計最近某一段時間出現過的top sql
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;
SELECT
schema_name,
digest_text,
count_star,
avg_timer_wait/1000000000000 AS avg_timer_wait,
max_timer_wait/1000000000000 AS max_timer_wait,
sum_lock_time/count_star/1000000000000 AS avg_lock_time ,
sum_rows_affected/count_star AS avg_rows_affected,
sum_rows_sent/count_star AS avg_rows_sent ,
sum_rows_examined/count_star AS avg_rows_examined,
sum_created_tmp_disk_tables/count_star AS avg_create_tmp_disk_tables,
sum_created_tmp_tables/count_star AS avg_create_tmp_tables,
sum_select_full_join/count_star AS avg_select_full_join,
sum_select_full_range_join/count_star AS avg_select_full_range_join,
sum_select_range/count_star AS avg_select_range,
sum_select_range_check/count_star AS avg_select_range,
first_seen,
last_seen
FROM performance_schema.events_statements_summary_by_digest
WHERE last_seen>date_add(NOW(), interval -1 HOUR)
ORDER BY
max_timer_wait
-- avg_timer_wait
-- sum_rows_affected/count_star
-- sum_lock_time/count_star
-- avg_lock_time
-- avg_rows_sent
DESC
limit 10;
需要注意的是，這個統計是按照MySQL執行一個事務消耗的資源做統計的，而不是一個語句，筆者一開始懵逼了一陣子，舉個簡單的例子。
參考如下，這裡是迴圈寫個資料的一個儲存過程，呼叫方式就是call create_test_data(N)，寫入N條測試資料。
比如call create_test_data(1000000)就是寫入100W的測試資料，這個執行過程耗費了幾分鐘的時間，按照筆者的測試例項情況，avg_timer_wait的維度，絕對是一個TOP SQL。
但是在查詢的時候，始終沒有發現這個儲存過程的呼叫被列為TOP SQL，後面嘗試在儲存過程內部加了一個事物，然後就順利地收集到了整個TOP SQL.
因此說performance_schema.events_statements_summary_by_digest裡面的統計，是基於事務的，而不是某一個批處理的執行時間的。
CREATE DEFINER=`root`@`%` PROCEDURE `create_test_data`(
IN `loopcnt` INT
)
LANGUAGE SQL
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
-- START TRANSACTION;
while loopcnt>0 do
insert into test_mrr(rand_id,create_date) values (RAND()*100000000,now(6));
set loopcnt=loopcnt-1;
end while;
-- commit;
END
另外一點比較有意思的是，這個系統表是為數不多的支援truncate的，當然它在內部，也是在不斷收集的一個過程。
執行失敗的SQL 統計
一直以為系統不會記錄執行失敗的\語法錯誤的SQL，後面才發現，這些資訊，MySQL會完整地記錄下來
這裡會詳細記錄執行錯誤的語句，包括最終執行失敗（超時之類的），語法錯誤，執行過程中產生了警告之類的語句。用sum_errors>0 or sum_warnings>0去performance_schema.events_statements_summary_by_digest篩選一下即可。
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;
select
schema_name,
digest_text,
count_star
from performance_schema.events_statements_summary_by_digest
where sum_errors>0 or sum_warnings>0
Index使用情況統計
基於performance_schema.table_io_waits_summary_by_index_usage這個系統表，其統計的維度同樣是“按照某個索引查詢返回的行數的統計”。
可以按照哪些索引使用最多\最少等情況進行統計。
不過這個統計有一個給人潛在一個誤區：
count_read,count_write,count_fetch,count_insert,count_update,count_delete統計了某個索引上使用到索引的情況下，受影響的行數，sum_timer_wait是累計在該索引上等待的時間。
如果使用到了該索引，但是沒有資料受影響（就是沒有DML語句的條件沒有命中資料），將count_***不會統計進來，但是sum_timer_wait會統計進來
這就存在一個容易受到誤導的地方，這個索引明明沒有命中過很多次，但是卻產生了大量的timer_wait，索引看到類似的資訊，也不能貿然刪除索引。
等待事件統計
MySQL資料庫中的任何一個動作，都需要等待（一定的時間來完成），一共有超過1000個等待事件，分屬不懂的類別，每個版本都不一樣，且預設不是所有的等待事件都啟用。
個人認為等待事件這個東西，僅做參考，不具備問題的診斷性，即便是再優化或者低負載的資料庫，累計一段時間，某些事件仍舊會積累大量的等待事件。
這些事件的等待事件，不一定都是負面性的，比如事物的鎖等待，是在併發執行過程中必然會生成的，這個等待事件的統計結果，也是累計的，單純的看一個直接的值，不具備任何參考意義。
除非定期收集，做差值計算，根據實際情況，才具備參考意義。
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ; SELECT SUBSTRING_INDEX(NAME, '/', 1) as wait_type,COUNT(1) FROM performance_schema.setup_instruments GROUP BY 1 ORDER BY 2 DESC; SELECT event_name, count_star, sum_timer_wait FROM performance_schema.events_waits_summary_global_by_event_name WHERE event_name != 'idle' order by sum_timer_wait desc limit 100;
最後，需要注意的是，
1，MySQL提供的諸多的系統表（檢視）中的資料，單純的看這個值本身，因為它是一個累計值，個人覺得意義不大，尤其是avg_***，需要結合多方面的綜合因素，做參考使用。
2，任何系統表的查詢，都可能對系統性能的本身造成一定的影響，不要再對系統可能產生較大負面影響的情況下做資料的統計收集。
參考：
http://blog.woqutech.com/
https://www.cnblogs.com/cchust/p/5061131.html
耐克的廣告，竟然是這麼的煽情
你能從一片空白裡，看到可能嗎？
有些人要看到證據，等有人做到了才敢出手。
但那些第一個行動的人，他們等過嗎？
他們直接出手，不管有沒有人做到過。
你能從一片空白裡，看到可能嗎？
不等別人，出手即證明。