Enable performance schema
In MySQL 5.6 after .6 version, performance schema is turned on by default usually binary version of MySQL are supported by default PS, if you use the compiler source installation, when cmake need to use the parameter DWITH_PERFSCHEMA_STORAGE_ENGINE = 1 to support PS Performance Schema is a way to achieve storage engine and therefore you can use the following two methods can be used to determine whether the PS ## check mode. 1 the SELECT * the FROM INFORMATION_SCHEMA.ENGINES the WHERE ENGINE = ' PERFORMANCE_SCHEMA ' \ G ## check mode 2 Show Engines \ G in the MySQL configuration file may be used performance_schema = ON is set automatically enable and initialize the performance schema after performance schema initialization is complete, you can use the same database as normal access performance_schema library.
Configuring performance schema
## ================================================ ============================= ## performance_schema library prefixed to setup a table to store configuration information: setup_actors: configure user latitude monitoring, surveillance default for all users. setup_consumers: Configuring events of the type of consumer that is written to the collection of events which statistics table. setup_instruments: Configure a particular instrument, comprising four major categories: IDLE, Stage / XXX, Statement / XXX, the wait / XXX: setup_objects: configure the monitoring object, the default for mysql, performance_schema information_schema tables and not monitored, while the other DB All tables are monitored. setup_timers: Configure statistical unit of time for each type of instruction. MICROSECOND represent statistical unit is subtle, CYCLE represents the statistical unit is the clock cycle time metrics associated with the CPU clock speed, NANOSECOND represent statistical units are nanoseconds. But no matter what unit of measure adopted in the final statistical tables will be installed for the time to picoseconds. (1 sec = 1000000000000 picoseconds) ## ======================================== ===================================== ## update will take effect immediately after the data in the table setup_consumers, but not persistently saved, so if you need permanent need in the configuration file configuration, such as: [mysqld] #performance_schema performance_schema_consumer_events_waits_current = ON performance_schema_consumer_events_stages_current = ON performance_schema_consumer_events_statements_current = ON performance_schema_consumer_events_waits_history = ON performance_schema_consumer_events_stages_history = ON performance_schema_consumer_events_statements_history = ON existence hierarchy performance_schema_consumer_XX, when the top is disabled, even if the underlying open, still can not take effect. Setup_consumers inside the values in the table there is a hierarchical relationship: LEVEL1: global_instrumentation LEVEL2: thread_instrumentation, statements_digest LEVEL3: events_stages_current, events_statements_current, events_waits_current LEVEL4: events_stages_history, events_statements_history, events_waits_history LEVEL5: events_stages_history_long, events_statements_history_long, events_waits_history_long to _current suffix to store the current event information to _history and _history_long suffix table is stored in the history _current table, _history default store recently waiting tables 10 events, and storing the last 1000 _history_long default wait event number stored table _history waiting for an event may be controlled by the parameters: SHOW the VARIABLES the LIKE ' performance_schema% History% size ' ; ## ========= ================================================== ================== ## when the PS is enabled, not all events are collected, you can view setup_instruments table to see which events are collected. The SELECT * the FROM setup_instruments; Reference: HTTPS: //dev.mysql.com/doc/refman/5.6/en/setup-instruments-table.html for setup_instruments table records, and only when ENABLED ENABLED state are simultaneously activated, the event will not collect setup_instruments Table 4 contains data categories : iDLE, stage / xxx, statement / xxx, wait / . xxx iDLE expressed socket free time, stage class represents the statistics for each stage of the implementation of the statement, of statement class statement dimensions of statistical information, the wait class statistics various wait events, such as IO, mutux, spin_lock, condition and so on. ## ================================================ ============================= ## reference connection: HTTP: // www.cnblogs.com/zhoujinyi/p/5236705. HTML HTTP: // keithlan.github.io/2015/07/17/22_performance_schema/
performance schema objects
## ================================================ ## ============================= cond_instances: waiting condition object instance table records the target condition variables used in the system, OBJECT_INSTANCE_BEGIN targeted memory addresses. ## ================================================ ## ============================= file_instances: file instance table records the file system to open the object file comprises ibdata , redo file, binlog files, user files, tables, open_count display the current number of open files, if not opened again, will not appear in the table. View ## times higher open file the SELECT * the FROM file_instances the ORDER BY OPEN_COUNT DESC LIMIT 10 \ G ## =========================== ================================================== ## mutex_instances: mutex synchronization object instance table records all the records used in the system mutex object, where name is: wait / synch / mutex / * . LOCKED_BY_THREAD_ID show which thread is holding the mutex, if there is no thread holds, is NULL. ## ================================================ ## ============================= rwlock_instances: write lock synchronization object instance table recording system using write lock object all records, where name is the wait / synch / rwlock / *. WRITE_LOCKED_BY_THREAD_ID is being held thread_id of the object, if there is no thread holds, is NULL. READ_LOCKED_BY_COUNT is recorded at the same time how many readers hold the lock. You can know by events_waits_current table, in which threads wait for a lock; which thread holds the lock by rwlock_instances know. rwlock_instances drawback is that only holders of record write lock thread for read lock is powerless. ## ================================================ ## ============================= socket_instances: an active session object instance table recording thread_id, socket_id, ip and port, other may be performed by thread_id table associated with socket_instance, IP-PORT obtain information capable of docking application. event_name mainly includes three types: the wait / IO / socket / SQL / server_unix_socket, unix server listening socket wait / io / socket / sql / server_tcpip_socket, server tcp listening socket the wait / IO / socket / SQL / client_connection, the client socket
performance schema表
## ================================================ ## =============================
the wait related tables 1.events_waits_current: records the events of the current thread waiting 2.events_waits_history: record each thread waits for the most recent 10 events 3.events_waits_history_long: recently recorded all threads events generated 10,000 ## ======================== ================================================== ## ===
stage related tables 1.events_stages_current: records the current thread execution phase in which the 2.events_stages_history: records the current thread execution phase in which the 10 history 3.events_stages_history_long: records the execution of the current thread is located stage 10000 history ## =========================================== ## ================================== the Statement Related table 1.events_statements_current: by thread_id + event_id uniquely determined a record. Statments table only records request top level, SQL statements, or COMMAND, each statement line. event_name form statement / sql / *, or Statement / COM / * 2.events_statements_history 3.events_statements_history_long ## =========================== ================================================== ## connection correlation table 1.users: recording user information connections 2.hosts: recording information on the number of hosts connected 3.accounts: recording information on the number of users connected to hosts ## ============= ================================================== ## ============== the Summary table: Summary table gathered statistics for individual dimensions including dimension tables, statistics index dimension, a dimension session, statements dimension and lock dimensions 1, events_waits_summary_global_by_event_name: by waiting for the event type of polymerization, for each event a record 2, events_waits_summary_by_instance: waiting for the event object according to the polymerization, the same kind of wait event, there may be multiple instances, each instance has a different memory addresses, so event_name + object_instance_begin uniquely identify a record. 3, events_waits_summary_by_thread_by_event_name: each thread and event statistics, thread_id + event_name uniquely identify a record. 4, events_stages_summary_global_by_event_name: by event type of polymerization stages, one for each event record table structure supra. 5, events_stages_summary_by_thread_by_event_name: to stage events and statistics for each thread, the structure of the table above. 6, events_statements_summary_by_digest: polymerization is carried out in accordance with the statement of the event. 7, events_statements_summary_global_by_event_name: polymerization is carried out in accordance with the statement of the event. Table structure above. 8, events_statements_summary_by_thread_by_event_name: polymerization is carried out in accordance with the statement of threads and events, the structure of the table above. 9, file_summary_by_instance: Statistics by event type (physical IO dimension) 10, file_summary_by_event_name: specific document statistics (IO physical dimensions) . 11, table_io_waits_summary_by_table: The wait / io / table / sql / handler, the polymerization of each table I / O operation ( IO logic latitude) 12 is, table_io_waits_summary_by_index_usage: table_io_waits_summary_by_table and similar, according to statistics index dimension 13, table_lock_waits_summary_by_table: table polymerization lock wait events, including internal lock lock and External internal lock function invoked by the SQL layer thr_lock, OPERATION is: Normal the Read, the Read with Shared Locks, the Read High priority, the Read NO INSERT, the Write the allow the Write, the Write Concurrent INSERT, the Write DELAYED, the Write Low priority, the Write Normal External Lock :: external_lock call the storage engine layer through an interface function handler, OPERATION column values: External Read, Write External 14, Summaries Connection table: Account, User, Host 15, socket_summary_by_instance, socket_summary_by_event_name: Socket tables polymerization.