The PERFORMANCE SCHEMA development continues

Now that mysql 5.5 is GA, development for the performance schema continues in the mysql-trunk code base. A lot of projects have been completed already, which are worth mentioning.

New table io instrumentation

Table io is now instrumented. As the performance instrumentation is located in the MySQL layer and not inside the storage engine, this instrumentation is de facto available to all storage engines, with zero code change.

New table lock instrumentation

Table locks are also instrumented. It is a nice complement to table io, and can be enabled or disabled independently from table io. Not all table waits are io problems, some are also contention caused by locks ... and there is now a way to observe that.

New stages instrumentation

Major execution phases of a statement, called stages, are now instrumented. This instrumentation is critical to identify which part of the execution path (parser, acl, locking, optimizer, runtime, etc) takes time.

New statements instrumentation

Statements themselves are now instrumented. As statements are what an application sends to the server, this is the instrumentation that makes the most sense to application developers. Now, once a statement is found to be "too slow", the lower level instrumentation like stage and waits can be used to see why.

New filtering options

A DBA may not want to monitor every single user session from every single application from every single host at once. Instrumentation for each session (or thread) can be turned on of off independently (TABLE performance_schema.threads, column INSTRUMENTED). Rules in the new table performance_schema.setup_actors can be used to instrument selectively traffic per user, per host, or per user+host.

Likewise, with table io and table lock instrumentation, a DBA may not want to instrument every single table in the database at once, but only instrument a subset of tables. Rules in the new tables performance_schema.setup_objects can be used for that.

Marc Alff, Oracle.