Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code DEF204)Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
Rechercher dans le manuel MySQL
26.9 Performance Schema Tables for Current and Historical Events
For wait, stage, statement, and transaction events, the
Performance Schema can monitor and store current events. In
addition, when events end, the Performance Schema can store them
in history tables. For each event type, the Performance Schema
uses three tables for storing current and historical events. The
tables have names of the following forms, where
xxx indicates the event type
(waits, stages,
statements, transactions):
events_: The “current events” table stores the current monitored event for each thread (one row per thread).xxx_currentevents_: The “recent history” table stores the most recent events that have ended per thread (up to a maximum number of rows per thread).xxx_historyevents_: The “long history” table stores the most recent events that have ended globally (across all threads, up to a maximum number of rows per table).xxx_history_long
The _current table for each event type contains
one row per thread, so there is no system variable for configuring
its maximum size. The Performance Schema autosizes the history
tables, or the sizes can be configured explicitly at server
startup using table-specific system variables, as indicated in the
sections that describe the individual history tables. Typical
autosized values are 10 rows per thread for
_history tables, and 10,000 rows total for
_history_long tables.
For each event type, the _current,
_history, and _history_long
tables have the same columns. The _current and
_history tables have the same indexing. The
_history_long table has no indexing.
The _current tables show what is currently
happening within the server. When a current event ends, it is
removed from its _current table.
The _history and
_history_long tables show what has happened in
the recent past. When the history tables become full, old events
are discarded as new events are added. Rows expire from the
_history and _history_long
tables in different ways because the tables serve different
purposes:
_historyis meant to investigate individual threads, independently of the global server load._history_longis meant to investigate the server globally, not each thread.
The difference between the two types of history tables relates to the data retention policy. Both tables contains the same data when an event is first seen. However, data within each table expires differently over time, so that data might be preserved for a longer or shorter time in each table:
For
_history, when the table contains the maximum number of rows for a given thread, the oldest thread row is discarded when a new row for that thread is added.For
_history_long, when the table becomes full, the oldest row is discarded when a new row is added, regardless of which thread generated either row.
When a thread ends, all its rows are discarded from the
_history table but not from the
_history_long table.
The following example illustrates the differences in how events are added to and discarded from the two types of history tables. The principles apply equally to all event types. The example is based on these assumptions:
The Performance Schema is configured to retain 10 rows per thread in the
_historytable and 10,000 rows total in the_history_longtable.Thread A generates 1 event per second.
Thread B generates 100 events per second.
No other threads are running.
After 5 seconds of execution:
A and B have generated 5 and 500 events, respectively.
_historycontains 5 rows for A and 10 rows for B. Because storage per thread is limited to 10 rows, no rows have been discarded for A, whereas 490 rows have been discarded for B._history_longcontains 5 rows for A and 500 rows for B. Because the table has a maximum size of 10,000 rows, no rows have been discarded for either thread.
After 5 minutes (300 seconds) of execution:
A and B have generated 300 and 30,000 events, respectively.
_historycontains 10 rows for A and 10 rows for B. Because storage per thread is limited to 10 rows, 290 rows have been discarded for A, whereas 29,990 rows have been discarded for B. Rows for A include data up to 10 seconds old, whereas rows for B include data up to only .1 seconds old._history_longcontains 10,000 rows. Because A and B together generate 101 events per second, the table contains data up to approximately 10,000/101 = 99 seconds old, with a mix of rows approximately 100 to 1 from B as opposed to A.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-performance-schema-event-tables.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.
