MySQL Usage Data
Enable Extract Usage Metrics in the MySQL integration's Advanced settings to populate the resource Usage tab and standard EQL usage fields for discovered tables and views. The option is disabled by default. See MySQL setup.
Metrics and coverage
total_read_queries_14d, total_read_queries_30d, total_read_queries_60d
Read-query counts from retained statement digests whose bounds can be assigned to the window.
distinct_users_14d, distinct_users_30d, distinct_users_60d
Distinct MySQL users attributed to retained, timestamped history-long statements in the window.
last_accessed_at
Latest retained read digest's LAST_SEEN.
query_count, distinct_users
Legacy unwindowed metrics. query_count falls back to table I/O read operations when digest counts are unavailable; those operations are not query executions.
Query counts include read sources of SELECT, WITH, INSERT ... SELECT, and CREATE TABLE ... SELECT statements. User counts deduplicate by MySQL username, not by connection or application user. Window boundaries are evaluated in UTC.
Permissions
In addition to the catalog permissions in the setup guide, the integration user needs SELECT on these Performance Schema tables. A MySQL administrator can grant access as follows, adapting the account name and host to the integration user:
GRANT SELECT ON performance_schema.table_io_waits_summary_by_table TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.events_statements_summary_by_digest TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.events_statements_history_long TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.events_statements_current TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.threads TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.setup_consumers TO 'euno_reader'@'%';
GRANT SELECT ON performance_schema.setup_instruments TO 'euno_reader'@'%';The crawler reads these settings; it does not enable collection or need UPDATE privileges.
Performance Schema configuration
Performance Schema must be enabled on the server (SELECT @@performance_schema returns 1). A MySQL administrator should configure these consumers for both query and user windows:
Query windows require global instrumentation, digest collection, and the listed instruments to be enabled. User windows independently require global and thread instrumentation, current-statement and history-long collection, and the listed instruments to be enabled and timed. The per-thread events_statements_history consumer is not a prerequisite for history-long collection. See MySQL's consumer dependencies and instrument timing settings.
Verify the configuration with SELECT * FROM performance_schema.setup_consumers and SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/%'. MySQL 8.4 normally disables history-long collection; enabling it starts collecting new events. Arrange persistent startup configuration with your administrator because runtime updates do not survive a restart. Consult MySQL's statement event configuration.
Retention and unavailable values
These metrics describe retained evidence, not a guaranteed complete 60-day audit history:
Digests accumulate counts between resets. If a digest spans a window's cutoff, Euno cannot split its count accurately and omits that table's affected window. This is normal on long-running servers. Digests entirely before the cutoff contribute zero; digests entirely inside it contribute their counts.
Server restarts, resets, and digest eviction shorten coverage. Enabling collection does not restore earlier events. Do not reset Performance Schema just to make a window available.
History-long is a bounded event buffer. Busy workloads can overwrite events well before 14 days. User attribution also requires the original connection's thread to still exist, so disconnected users can be absent. Thread/actor filters can further limit coverage.
Statement times are estimated from Performance Schema timers and the crawler's current statement. Missing timing for a table prevents publication of its user windows.
Missing evidence, disabled required collection, or unreadable configuration leaves affected window properties unchanged in Euno. Stored values can therefore describe an earlier crawl. Disabling the integration option also preserves prior metrics.
A published zero means no matching activity in the usable retained evidence. It does not prove that a table had no activity during the entire calendar window. Missing metrics likewise do not mean zero usage. Check source coverage before using these values to decide that a resource is unused.
Access failures, disabled required collection, and relevant unparseable statements appear as non-fatal discovery errors. Unavailable query windows caused by digest bounds do not produce a run warning.
Last updated