Databases
MySQL
performance_schema for per-table write counts, information_schema for routines and structure.
MySQL's useful metadata is split across two schemas with different characters.
information_schema describes structure and is always available;
performance_schema describes activity and is where per-table write counts live —
but its instrumentation is partly off by default and varies by version and distribution.
Where it is enabled, table_io_waits_summary_by_table is the single most useful
view: it gives read and write counts per table since the last server start, which is enough
to establish which tables a pipeline actually touches without reading a single row.
What Decim reads from MySQL
Every item below is read-only, and each is a specific view, endpoint or file rather than a category of access. If something here is unacceptable in your environment, it can be removed from the query catalogue — see the agent for how that works.
| What | From | Why it matters |
|---|---|---|
| Write activity | performance_schema.table_io_waits_summary_by_table | COUNT_INSERT, COUNT_UPDATE, COUNT_DELETE per table |
| Routine bodies | information_schema.ROUTINES | ROUTINE_DEFINITION for procedures and functions |
| Table structure | information_schema.TABLES, COLUMNS | Row estimates, types, and UPDATE_TIME |
| Foreign keys | information_schema.KEY_COLUMN_USAGE | Structural edges |
| Live contention | performance_schema.processlist | Running statements and their state |
| Statement history | events_statements_summary_by_digest | Which statement shapes dominate, and their latency |
| Scheduled events | information_schema.EVENTS | MySQL's own scheduler — frequently overlooked |
Permissions required
Written out in full, because "read-only access" is not a specification. Nothing below grants the ability to write, and row access is requested only on the specific tables you name.
CREATE USER 'decim_agent'@'10.%' IDENTIFIED BY '...';
-- Metadata and instrumentation.
GRANT SELECT ON performance_schema.* TO 'decim_agent'@'10.%';
GRANT PROCESS ON *.* TO 'decim_agent'@'10.%';
GRANT SELECT ON information_schema.* TO 'decim_agent'@'10.%';
-- Reconciliation tables only.
GRANT SELECT ON sales.intake_batch TO 'decim_agent'@'10.%';
GRANT SELECT ON sales.rejected_transactions TO 'decim_agent'@'10.%';
-- PROCESS is needed to see other sessions in the processlist. It is a
-- server-wide grant and reveals running statement text — review it
-- deliberately rather than granting it by habit.What it builds
What this source contributes to the pipeline topology and to the evidence available during an investigation:
- Target nodes and write volumes where performance_schema is instrumented
- Transform nodes from stored routine bodies
- Scheduled work from information_schema.EVENTS
- Structural edges from foreign key metadata
Nodes learned from a definition are marked declared; nodes observed running are marked observed; nodes both declared and observed are verified. Where two sources disagree, the disagreement is recorded as a drift note rather than resolved silently.
Failure modes it surfaces
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it.
| Failure mode | The signal |
|---|---|
| Load wrote nothing | COUNT_INSERT flat across the window |
| Undocumented target | Write counts on a table in no definition |
| Long-running blocking statement | processlist state during the stall |
| Silent scheduled job | An enabled row in EVENTS nobody knew about |
Limits
What this integration cannot tell you. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest blocked.
performance_schemainstrumentation is partly disabled by default and the setup tables must be enabled to get table-level counters- Counters reset on server restart, like every other in-memory statistic
- Aurora and other managed forks expose a subset of performance_schema — verify before relying on a view
Related integrations
- PostgreSQL — pg_stat_user_tables for write activity, pg_proc for function bodies, pg_stat_activity for live blocking.
- SQL Server — Reads catalog metadata, procedure bodies and write activity — the definitions git never sees.
- Apache Airflow — The metadata database holds connections, variables, pools and manual state — none of it in git.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a MySQL pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.