Archive for October, 2008

MySQL Profiler

The SQL Profiler is built into the database server and can be dynamically enabled/disabled via the MySQL client utility. To begin profiling one or more SQL queries, simply issue the following command:

SET profiling = 1;

Two things happen once you issue this command. First, any query you issue from this point on will be traced by the server with various performance diagnostics being created and attached to each distinct query. Second, a memory table named profiling is created in the INFORMATION_SCHEMA database for your particular session (not viewable by any other MySQL session) that stores all the SQL diagnostic results. This table remains persistent until you disconnect from MySQL at which point it is destroyed.

Read more here – Using the New MySQL Query Profiler.

Fast vs. Quick

I was always wondering what the difference between “quick” and “fast” is.

And it looks like:

  • fast applies to things that move (e.g., “fast horses”, “a fast train”);
  • quick means promptness and the taking of little time (e.g., “a quick dinner”, “quick thinking”).

Also there is another interesting example to understand the difference better:

  • a quick question means that it does not take lots of time to ask and answer;
  • a fast question refers to the talking speed of the enquirer.

MySQL: 6.0’s new utility for backup and restore

Robin Schumacher, MySQL’s Director of Product Management overviews MySQL 6.0’s backup and restore utility.

MySQL 6.0’s backup/restore utility is a completely new tool in the server that allows for backup and restore commands to be issued right from a mysql client command prompt, which means no shelling out to an operating system prompt and/or scripting shell scripts to run a backup.

The syntax in the current alpha release looks like the following:

BACKUP {DATABASE | SCHEMA} { * | db_name [, db_name] ... }
TO 'image_file_name'
[WITH COMPRESSION [COMPRESSION_ALGORITHM [=] algorithm_name]];
 
RESTORE FROM 'image_file_name';

MySQL: how to ignore checking of foreign key constraints for InnoDB tables

There is a session variable FOREIGN_KEY_CHECKS which allows to ignore checking of foreign key constraints for InnoDB tables.

If set to 1 (the default), foreign constraints are checked. If set to 0, they are ignored.
Setting FOREIGN_KEY_CHECKS to 0 also affects data definition statements like DROP TABLE which drops tables that have foreign keys that are referred to by other tables.

Disabling foreign key checking can be useful for reloading InnoDB tables in an order different from that required by their parent/child relationships.

Using session variables:

SET FOREIGN_KEY_CHECKS = 0;
 
SELECT @@FOREIGN_KEY_CHECKS;
 
SET FOREIGN_KEY_CHECKS = 1;