Version sans cache

Mise en cache désactivé. Réglage défaut pour cette page : actif (code DEF204)
Si l'affichage est trop lent, vous pouvez désactiver le mode utilisateur pour visualiser la version en cache.

Rechercher dans le manuel MySQL

26.19.1 Query Profiling Using Performance Schema

Table des matières

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. +--------------------------------+----------+

Rechercher dans le manuel MySQL

Traduction non disponible

Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.

Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-performance-schema-query-profiling.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Références

  1. Consulter le document html Langue du document :en Manuel MySQL : https://dev.mysql.com/

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Table des matières Haut