MySQL Workbench is a handy administrative tool. Workbench provides server status information, client connection data, the best user admin interface, a browser for system variables, access to data export, an import/restore function, access to system logs, option file editing, performance reports, and startup/shutdown switch.

This is a snapshot of the dashboard on a laptop running a few very simplequeries.

In the past I have either used the CLI or tools like PHPMyAdmin. Well, the CLI is often victim to my poor typing skills and PHPMyAdmin is not always installed when I need it. But if I can connect via the CLI, I can connect with Workbench.

The …

Today’s contradiction:

MySQL has server variables named new and old.

The new variable can be set per-session and globally, and is dynamic. The old variable is not dynamic, and only global in scope. Both default to FALSE in MySQL 5.1.

According to the manual, the new variable:

was used in MySQL 4.0 to turn on some 4.1 behaviors, and is retained for backward compatibility.

That same page notes the following about the old variable:

when old is enabled, it changes the default scope of index hints to that used prior to MySQL 5.1.17. That is, index hints with no FOR clause apply only to how indexes are used for row retrieval and not to resolution of ORDER BY or GROUP BY clauses.

That’s right — the …

Do you have_community_features? I do!

SHOW GLOBAL VARIABLES LIKE 'have_community_features';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| have_community_features | YES   |
+-------------------------+-------+
1 row in set (0.00 sec)

I am pretty sure this is one of those variables that MySQL has put in as an unused placeholder, but for now, it is not even documented as unused (as are table_lock_wait_timeout, http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html, and a Google search restricted to the site dev.mysql.com turns up only one match, …

The unsung heroes of InnoDB are the logfiles. They are what makes InnoDB automatic crash recovery possible.

Database administrators of other DBMS may be familiar with the concept of a “redo” log. When data is changed, affected data pages are changed in the innodb_buffer_pool. Then, the change is written to the redo log, which in MySQL is the InnoDB logfile (ib_logfile0 and ib_logfile1). The pages are marked as “dirty”, and eventually get flushed and written to disk.

If MySQL crashes, there may be data that is changed that has not been written to disk. Those data pages were marked as “dirty” in the innodb_buffer_pool, but after a MySQL crash the innodb_buffer_pool no longer exists. However, they were written to the redo log. On crash recovery, MySQL can read the redo log (InnoDB log files) and apply any changes that were not written to disk.

That is the basic functionality of the InnoDB log files. Given this, …