Rechercher dans le manuel MySQL

26.19.1 Query Profiling Using Performance Schema

Inhoudsopgave

The following example demonstrates how to use Performance Schema statement events and stage events to retrieve data comparable to profiling information provided by SHOW PROFILES and SHOW PROFILE statements.

The setup_actors table can be used to limit the collection of historical events by host, user, or account to reduce runtime overhead and the amount of data collected in history tables. The first step of the example shows how to limit collection of historical events to a specific user.

Performance Schema displays event timer information in picoseconds (trillionths of a second) to normalize timing data to a standard unit. In the following example, TIMER_WAIT values are divided by 1000000000000 to show data in units of seconds. Values are also truncated to 6 decimal places to display data in the same format as SHOW PROFILES and SHOW PROFILE statements.

  1. Limit the collection of historical events to the user that will run the query. By default, setup_actors is configured to allow monitoring and historical event collection for all foreground threads:

    1. mysql> SELECT * FROM performance_schema.setup_actors;
    2. +------+------+------+---------+---------+
    3. | HOST | USER | ROLE | ENABLED | HISTORY |
    4. +------+------+------+---------+---------+
    5. | %    | %    | %    | YES     | YES     |
    6. +------+------+------+---------+---------+

    Update the default row in the setup_actors table to disable historical event collection and monitoring for all foreground threads, and insert a new row that enables monitoring and historical event collection for the user that will run the query:

    1. mysql> UPDATE performance_schema.setup_actors
    2.        SET ENABLED = 'NO', HISTORY = 'NO'
    3.        WHERE HOST = '%' AND USER = '%';
    4.  
    5. mysql> INSERT INTO performance_schema.setup_actors
    6.        (HOST,USER,ROLE,ENABLED,HISTORY)
    7.        VALUES('localhost','test_user','%','YES','YES');

    Data in the setup_actors table should now appear similar to the following:

    1. mysql> SELECT * FROM performance_schema.setup_actors;
    2. +-----------+-----------+------+---------+---------+
    3. | HOST      | USER      | ROLE | ENABLED | HISTORY |
    4. +-----------+-----------+------+---------+---------+
    5. | %         | %         | %    | NO      | NO      |
    6. | localhost | test_user | %    | YES     | YES     |
    7. +-----------+-----------+------+---------+---------+

  2. Ensure that statement and stage instrumentation is enabled by updating the setup_instruments table. Some instruments may already be enabled by default.

    1. mysql> UPDATE performance_schema.setup_instruments
    2.        SET ENABLED = 'YES', TIMED = 'YES'
    3.        WHERE NAME LIKE '%statement/%';
    4.  
    5. mysql> UPDATE performance_schema.setup_instruments
    6.        SET ENABLED = 'YES', TIMED = 'YES'
    7.        WHERE NAME LIKE '%stage/%';

  3. Ensure that events_statements_* and events_stages_* consumers are enabled. Some consumers may already be enabled by default.

    1. mysql> UPDATE performance_schema.setup_consumers
    2.        SET ENABLED = 'YES'
    3.        WHERE NAME LIKE '%events_statements_%';
    4.  
    5. mysql> UPDATE performance_schema.setup_consumers
    6.        SET ENABLED = 'YES'
    7.        WHERE NAME LIKE '%events_stages_%';

  4. Under the user account you are monitoring, run the statement that you want to profile. For example:

    1. mysql> SELECT * FROM employees.employees WHERE emp_no = 10001;
    2. +--------+------------+------------+-----------+--------+------------+
    3. | emp_no | birth_date | first_name | last_name | gender | hire_date |
    4. +--------+------------+------------+-----------+--------+------------+
    5. |  10001 | 1953-09-02 | Georgi     | Facello   | M      | 1986-06-26 |
    6. +--------+------------+------------+-----------+--------+------------+

  5. Identify the EVENT_ID of the statement by querying the events_statements_history_long table. This step is similar to running SHOW PROFILES to identify the Query_ID. The following query produces output similar to SHOW PROFILES:

    1. mysql> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
    2.        FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%10001%';
    3. +----------+----------+--------------------------------------------------------+
    4. | event_id | duration | sql_text                                               |
    5. +----------+----------+--------------------------------------------------------+
    6. |       31 | 0.028310 | SELECT * FROM employees.employees WHERE emp_no = 10001 |
    7. +----------+----------+--------------------------------------------------------+

  6. Query the events_stages_history_long table to retrieve the statement's stage events. Stages are linked to statements using event nesting. Each stage event record has a NESTING_EVENT_ID column that contains the EVENT_ID of the parent statement.

    1. mysql> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
    2.        FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=31;
    3. +--------------------------------+----------+
    4. | Stage                          | Duration |
    5. +--------------------------------+----------+
    6. | stage/sql/starting             | 0.000080 |
    7. | stage/sql/checking permissions | 0.000005 |
    8. | stage/sql/Opening tables       | 0.027759 |
    9. | stage/sql/init                 | 0.000052 |
    10. | stage/sql/System lock          | 0.000009 |
    11. | stage/sql/optimizing           | 0.000006 |
    12. | stage/sql/statistics           | 0.000082 |
    13. | stage/sql/preparing            | 0.000008 |
    14. | stage/sql/executing            | 0.000000 |
    15. | stage/sql/Sending data         | 0.000017 |
    16. | stage/sql/end                  | 0.000001 |
    17. | stage/sql/query end            | 0.000004 |
    18. | stage/sql/closing tables       | 0.000006 |
    19. | stage/sql/freeing items        | 0.000272 |
    20. | stage/sql/cleaning up          | 0.000001 |
    21. +--------------------------------+----------+

Zoek in de MySQL-handleiding

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-query-profiling.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

  1. Bekijk - html-document Taal van het document:en Manuel MySQL : https://dev.mysql.com/

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.

Inhoudsopgave Haut