Performance Schema
AdvancedPerformance Schema instruments the server to collect metrics on query execution, lock waits, I/O, and memory allocation — low overhead, high-detail insight without external tooling.
Overview
The Performance Schema (P_S) is MySQL's built-in instrumentation layer — a special database that collects real-time metrics on server internals with minimal overhead (typically < 5% CPU). It tracks query execution statistics, lock wait events, I/O latency per table and file, memory allocation, and thread activity. The sys schema (introduced in MySQL 5.7) provides convenient views over Performance Schema tables with human-readable formats. The most valuable use cases: finding the top N slowest queries, identifying tables causing most lock waits, diagnosing I/O hotspots, and detecting sessions holding locks that block others.
Top slow queries with statement_analysis
The sys.statement_analysis view (or performance_schema.events_statements_summary_by_digest) aggregates all query executions by normalized query digest — showing total calls, average latency, max latency, rows examined per row sent (inefficiency ratio), and whether the query uses a full table scan or a temporary table.
-- Top 10 slowest queries by average latency (sys schema)
SELECT
query,
exec_count,
avg_latency,
max_latency,
rows_examined_avg / NULLIF(rows_sent_avg, 0) AS rows_per_sent,
full_scan,
tmp_tables,
tmp_disk_tables
FROM sys.statement_analysis
ORDER BY avg_latency DESC
LIMIT 10;
-- Raw Performance Schema query (more detail)
SELECT
DIGEST_TEXT,
COUNT_STAR AS exec_count,
ROUND(AVG_TIMER_WAIT / 1e9, 2) AS avg_ms,
ROUND(MAX_TIMER_WAIT / 1e9, 2) AS max_ms,
SUM_ROWS_EXAMINED,
SUM_ROWS_SENT,
SUM_NO_INDEX_USED AS full_scan_count
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 10;Lock waits and blocking sessions
Performance Schema tracks lock wait events in detail. The sys.innodb_lock_waits view (MySQL 5.7+) shows blocking and waiting transactions with the blocking query and session. Use it to identify sessions holding locks for long periods and causing widespread blocking.
-- Find current lock waits (blocking and blocked sessions)
SELECT
r.trx_id AS waiting_trx,
r.trx_mysql_thread_id AS waiting_thread,
r.trx_query AS waiting_query,
b.trx_id AS blocking_trx,
b.trx_mysql_thread_id AS blocking_thread,
b.trx_query AS blocking_query,
TIMESTAMPDIFF(SECOND, r.trx_wait_started, NOW()) AS wait_seconds
FROM information_schema.innodb_trx r
JOIN information_schema.innodb_trx b
ON r.trx_wait_started IS NOT NULL
AND b.trx_id IN (
SELECT blocking_trx_id
FROM performance_schema.data_lock_waits
);
-- Simpler sys schema view (MySQL 5.7.9+)
SELECT * FROM sys.innodb_lock_waits;
-- Kill a blocking session
KILL 42; -- thread_id from blocking_thread above
-- Tables with most lock wait time
SELECT object_schema, object_name, count_star, sum_timer_wait/1e12 AS wait_s
FROM performance_schema.table_lock_waits_summary_by_table
ORDER BY sum_timer_wait DESC LIMIT 10;I/O analysis and table statistics
Performance Schema tracks I/O at file and table level. Use table_io_waits_summary_by_table to find tables with the most I/O activity — high rows_read with low rows_written suggests a scan-heavy read workload that needs better indexing. Use file_summary_by_instance for per-datafile I/O latency to identify I/O hotspots at the storage level.
-- Tables with most I/O (identify hotspots)
SELECT
object_schema,
object_name,
count_read,
count_write,
count_fetch,
ROUND(sum_timer_read / 1e12, 3) AS read_s,
ROUND(sum_timer_write / 1e12, 3) AS write_s
FROM performance_schema.table_io_waits_summary_by_table
WHERE object_schema NOT IN ('mysql', 'sys', 'performance_schema')
ORDER BY sum_timer_read + sum_timer_write DESC
LIMIT 10;
-- File-level I/O latency
SELECT
file_name,
count_read, count_write,
ROUND(sum_timer_read / 1e12, 3) AS read_s,
ROUND(sum_timer_write / 1e12, 3) AS write_s
FROM performance_schema.file_summary_by_instance
ORDER BY sum_timer_read + sum_timer_write DESC
LIMIT 10;
-- Memory usage per component
SELECT
event_name,
current_alloc,
high_alloc
FROM sys.memory_global_by_current_bytes
LIMIT 20;Key Points to Remember
- 1Performance Schema collects real-time metrics with < 5% CPU overhead — enabled by default since MySQL 5.7
- 2sys.statement_analysis aggregates queries by digest — showing avg/max latency, full_scan, tmp_disk_tables per query pattern
- 3rows_examined / rows_sent ratio > 100 indicates a query scanning far more rows than it returns — missing index candidate
- 4sys.innodb_lock_waits shows blocking and waiting transactions with the blocking query — use KILL to unblock
- 5table_io_waits_summary_by_table identifies tables with the most I/O, guiding index additions and denormalisation decisions
- 6Always reset statistics before profiling: CALL sys.ps_truncate_all_tables(FALSE) or TRUNCATE specific summary tables
Interview Questions
Sign in to ask AriaWhat is the MySQL Performance Schema and how does it differ from EXPLAIN?
How would you find the top 5 slowest query patterns executed over the last hour in MySQL?
What does a high rows_examined / rows_sent ratio in statement_analysis indicate?
How would you identify which session is blocking other transactions from making progress?
How would you use the Performance Schema to identify an I/O hotspot causing disk saturation?
Ask Aria about Performance Schema
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.