The SQL Editor in MySQL Workbench 6.1 adds a new interface for query results. This addition offers 4 new views to your query results, 2 for the result data itself and 2 for meta-information about the query that was executed.
Query Result Set Grid
The traditional result set grid. Run a SELECT query on a table with a primary key and you can edit the data. You must click the Edit button to enter edit mode.
Note: Until Workbench 6.1.1, the check was being done automatically for every SELECT query, but since that requires extra queries to MySQL, the check is now done on demand.
Result Set Form Editor
The new form editor for result sets comes in handy when you want to closely inspect the fields of each record (specially if it has multi-line text). You can also edit the individual records, if your result set is editable.
Result Set Field Types
Here, you can inspect information about the fields that were returned by the MySQL server in your query results. Similar to the —column-type-info option from the command line client, it will show you the schema and table from where the field comes from and type information.
Performance Schema Statistics
This tab uses data gleaned from the performance_schema (in MySQL 5.6) to gather some key statistics collected about the execution from your query, as collected by the server. To have this tab, you need to have the performance_schema enabled with statement instrumentation.
You can read about the meaning of each item in the MySQL performance_schema documentation, but here’s a summary of some key items:
- Timing: the timing information shown in the Action Output area in Workbench is the query execution time as measured at the client side, so it will include network travel time. But here you also have the timing as instrumented by the server itself. This includes the amount of time waiting for table locks, as a separate value.
- Rows Processed: the number of rows that were evaluated and then generated to be sent back to the client
- Temporary Tables: the number of temporary tables that had to be created for the query to be executed
- Joins per Type: the number of JOINs that were executed for the query, broken down by type. This is similar to the info you’d get from EXPLAIN.
- Sorting: number of data that had to be sorted by the server.
- Index Usage: you can see here whether table scans had to be performed without using an index.
You can disable fetching of this information from the Query -> Collect Performance Schema Stats menu item. You may want to do that if you don’t need the stats, since an extra query has to be executed for every query you run.
