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
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 DTrace User Guide.
MySQL 5.6 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