mysql performance_schema 初探:
mysql 5.5 版本 新增了一個性能優化的引擎: PERFORMANCE_SCHEMA
這個功能默認是關閉的:
須要設置參數: performance_schema 才能夠啓動該功能,這個參數是靜態參數,只能寫在my.cnf 中
不能動態修改。
先看看有什麼東西吧:
mysql> use performance_schema;
Database changed
mysql> show tables ;
+----------------------------------------------+
| Tables_in_performance_schema |
+----------------------------------------------+
| cond_instances |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| mutex_instances |
| performance_timers |
| rwlock_instances |
| setup_consumers |
| setup_instruments |
| setup_timers |
| threads |
+----------------------------------------------+
17 rows in set (0.00 sec)
這裏的數據表分爲幾類:
1) setup table : 設置表,配置監控選項。
2) current events table : 記錄當前那些thread 正在發生什麼事情。
3) history table 發生的各類事件的歷史記錄表
4) summary table 對各類事件的統計表
5) 雜項表,亂七八糟表。
setup 表:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME |
+-------------------+
| setup_consumers |
| setup_instruments |
| setup_timers |
+-------------------+
setup_consumers 描述各類事件
setup_instruments 描述這個數據庫下的表名以及是否開啓監控。
setup_timers 描述 監控選項已經採樣頻率的時間間隔
這個要多說一點 目前 performance-schema 只支持 'wait' 時間的監控,代碼樹上 wait/ 下的函數均可以監控到。
文檔上說了只有 'wait' 事件的檢測,有沒有其餘的選項呢?
看看源代碼:
static row_setup_timers all_setup_timers_data[COUNT_SETUP_TIMERS]=
{
{
{ C_STRING_WITH_LEN("wait") },
&wait_timer
}
};
THR_LOCK table_setup_timers::m_table_lock;
int table_setup_timers::update_row_values(TABLE *table,
const unsigned char *,
unsigned char *,
Field **fields)
{
Field *f;
longlong value;
DBUG_ASSERT(m_row);
for (; (f= *fields) ; fields++)
{
if (bitmap_is_set(table->write_set, f->field_index))
{
switch(f->field_index)
{
case 0: /* NAME */
my_error(ER_WRONG_PERFSCHEMA_USAGE, MYF(0));
return HA_ERR_WRONG_COMMAND;
case 1: /* TIMER_NAME */
value= get_field_enum(f);
if ((value >= FIRST_TIMER_NAME) && (value <= LAST_TIMER_NAME))
*(m_row->m_timer_name_ptr)= (enum_timer_name) value;
else
return HA_ERR_WRONG_COMMAND;
break;
default:
DBUG_ASSERT(false);
}
}
}
return 0;
}
代碼裏寫死了,只有 'wait' 一個值,不排除之後的版本會增長新的關鍵字,但至少目前就只有一個啦。
而且這個表的name 字段是不容許修改的的。 下面的修改的方法裏沒有作任何處理,涉及到name字段的修改,直接報錯。
mysql> SELECT * FROM setup_timers;
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
只有 timer_name 能夠update 這是一個enum 字段。
性能事件表:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%current';
+----------------------+
| TABLE_NAME |
+----------------------+
| events_waits_current |
+----------------------+
記錄當前正在發生的等待事件,這個表是隻讀的表,不能update ,delete ,可是能夠truncate
具體字段是什麼意思就本身去查doc 了,這裏不說了。
性能歷史表:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND (TABLE_NAME LIKE '%history' OR TABLE_NAME LIKE '%history_long');
+---------------------------+
| TABLE_NAME |
+---------------------------+
| events_waits_history |
| events_waits_history_long |
+---------------------------+
這些表與前面的性能表的結構是一致的, history 表只保留每一個線程(thread) 的最近的10個事件, history_long 記錄最近的10000個事件。
新事件如表,若是舊錶滿了,就會丟棄舊的數據,標準的先進先出(FIFO) 這倆表也是隻讀表,只能truncate
事件彙總表:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%summary%';
+----------------------------------------------+
| TABLE_NAME |
+----------------------------------------------+
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_summary_by_event_name |
| file_summary_by_instance |
+----------------------------------------------+
按照相關的標準對進行的事件統計表,
events_waits_summary_global_by_event_name 在mysql5.5.7 之前叫: EVENTS_WAITS_SUMMARY_BY_EVENT_NAME
表也是隻讀的,只能turcate
performance schema instance 表:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%instances';
+------------------+
| TABLE_NAME |
+------------------+
| cond_instances |
| file_instances |
| mutex_instances |
| rwlock_instances |
+------------------+
記錄各類等待事件涉及到的實例 : 主要是3類: cond (容器? ) mutex (互斥鎖) ,rwlock (讀寫鎖)
這表是隻讀的。
亂七八糟表:
mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | NULL | NULL | NULL |
| MICROSECOND | 1000000 | 1 | 585 |
| MILLISECOND | 1035 | 1 | 738 |
| TICK | 101 | 1 | 630 |
+-------------+-----------------+------------------+----------------+
這個表式只讀表,記錄了事件採樣頻率的設定,咱們前面說的setup_timer 表的timer_name 只能區這4箇中一個。
mysql> SELECT * FROM threads;
+-----------+----------------+----------------------------------------+
| THREAD_ID | PROCESSLIST_ID | NAME |
+-----------+----------------+----------------------------------------+
| 0 | 0 | thread/sql/main |
| 1 | 0 | thread/innodb/io_handler_thread |
| 16 | 0 | thread/sql/signal_handler |
| 23 | 7 | thread/sql/one_connection |
| 5 | 0 | thread/innodb/io_handler_thread |
| 12 | 0 | thread/innodb/srv_lock_timeout_thread |
| 22 | 6 | thread/sql/one_connection |
這個表記錄了系統裏當前存在的各類線程。
下面就是 涉及到performance_schema的各個系統參數了:
mysql> SHOW VARIABLES LIKE 'perf%';
+---------------------------------------------------+---------+
| Variable_name | Value |
+---------------------------------------------------+---------+
| performance_schema | ON |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
| performance_schema_max_file_classes | 50 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | 10000 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | 1000000 |
| performance_schema_max_rwlock_classes | 30 |
| performance_schema_max_rwlock_instances | 1000000 |
| performance_schema_max_table_handles | 100000 |
| performance_schema_max_table_instances | 50000 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | 1000 |
+---------------------------------------------------+---------+
涉及到系統狀態的參數:
mysql> SHOW STATUS LIKE 'perf%';
+------------------------------------------+-------+
| Variable_name | Value |
+------------------------------------------+-------+
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
+------------------------------------------+-------+
如何使用這個,來診斷數據庫性能問題呢 ? 且聽下回分解!javascript