Rechercher dans le manuel MySQL

26.19.1 Query Profiling Using Performance Schema

Inhaltsverzeichnis

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

Suchen Sie im MySQL-Handbuch

Deutsche Übersetzung

Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.

Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.

Vielen Dank im Voraus.

Dokument erstellt 26/06/2006, zuletzt geändert 26/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/mysql-rf-performance-schema-query-profiling.html

Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.

Referenzen

  1. Zeigen Sie - html-Dokument Sprache des Dokuments:en Manuel MySQL : https://dev.mysql.com/

Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.

Inhaltsverzeichnis Haut