The DTrace probes in the MySQL server are designed to provide information about the execution of queries within
MySQL and the different areas of the system being utilized during that process. The organization and triggering
of the probes means that the execution of an entire query can be monitored with one level of probes (
query-done) but by monitoring other
probes you can get successively more detailed information about the execution of the query in terms of the locks
used, sort methods and even row-by-row and storage-engine level execution information.
The DTrace probes are organized so that you can follow the entire query process, from the point of connection from a client, through the query execution, row-level operations, and back out again. You can think of the probes as being fired within a specific sequence during a typical client connect/execute/disconnect sequence, as shown in the following figure.
Global information is provided in the arguments to the DTrace probes at various levels. Global information, that
is, the connection ID and user/host and where relevant the query string, is provided at key levels (
query-exec-start). As you go deeper
into the probes, it is assumed either you are only interested in the individual executions (row-level probes
provide information on the database and table name only), or that you will combine the row-level probes with the
notional parent probes to provide the information about a specific query. Examples of this will be given as the
format and arguments of each probe are provided.
For more information on DTrace and writing DTrace scripts, read the
MySQL 5.7 includes support for DTrace probes on Solaris 10 Update 5 (Solaris 5/08) on SPARC, x86 and x86_64
platforms. Probes are also supported on Mac OS X 10.4 and higher. Enabling the probes should be automatic on
these platforms. To explicitly enable or disable the probes during building, use the
-DENABLE_DTRACE=0 option to CMake.