JJB Blog » mysql

There is something very strange about the MySQL forums

John — Thu, 01 Mar 2007 19:59:52 +0000

Is it just me, or is there not a single section for discussing actual MySQL queries? It seems that all the query discussion ends up in the newbie section.

Am I right?

INNER JOIN syntax

John — Sun, 21 Jan 2007 09:09:28 +0000

It’s too bad that ON (column = column) comes after and not before INNER JOIN table, because if it came before it would make for much cuter code formatting:

[sql]
SELECT DISTINCT $columns
FROM
$this->comments
ON (comment_post_ID = post_id) INNER JOIN
$this->post2cat
ON (category_id = cat_ID) INNER JOIN
$this->categories
WHERE
blog = ‘$blog’ AND
$criteria
[/sql]

SQL CHALLENGE

John — Fri, 19 Jan 2007 09:38:55 +0000

Arrrrre you readyyyyy— for an es Q elllllllll— CHALLENGE!!!!!

I have a user table, let’s say with name and zipcode. I can do the following successfully:

Select a random user with SELECT * FROM users ORDER BY RAND(UNIX_TIMESTAMP()) LIMIT 1
Select all users, with only 1 from each zipcode, using SELECT * FROM users GROUP BY zipcode update: I simplified this as per Danny’s suggestion below

The only problem is, in case 2, it’s always the same user per-zipcode. I want to randomize which in the grouping gets pulled out. I would prefer that the solution not involve joining the table on itself, although if I don’t find another solution I will probably whip up the self-join solution just for fun.

Everything you need to know about designing MySQL InnoDB primary keys

John — Sun, 22 Oct 2006 18:53:12 +0000

There are two aspects of how MySQL/InnoDB use a table’s primary key on the file system that have important ramifications for the key’s design:

The primary key determines the order in which the data is physically stored in the main data file, aka “the clustered index”. Another way of saying this: the main data file is a B-tree index that directly contains all of a table’s columns, and the key on this B-tree is the primary key. This can result in one less I/O operation (compared to MyISAM) on many queries.
The primary key is what is used to associate all of a table’s indexes with the main data file. So the primary key is replicated in every row of every index.

How to design your InnoDB primary keys:

Do explicitly define a primary key, and make it numeric. If no primary key is specified, or a non-numeric column is used as a primary key, InnoDB will used its own internal auto-incremented row ID to link between the main data table and the other indexes. This row ID is 6 bytes. The biggest numeric type in MySQL, BIGINT, is 8 bytes, and the next smallest type, INT, is 4 bytes. So not only is this “hidden” row ID an entire extra redundant column, it is also bigger than the data type that would be used in the vast majority of cases where a primary key is explicitly specified. Furthermore, when InnoDB falls back to using this internal row ID, the rows in the main data file are ordered by insertion order instead of your primary key, rendering InnoDB’s clustering behavior useless, and adding an entire extra I/O operation on some queries. This is a big loss.
As alluded to above, the primary key should be sequential. Because the structure of the data on the disk is dictated by the primary key, it should be sequential, to avoid extremely expensive I/O on writes (when the B-Tree has to be reorganized), and to take advantage of the native clustering.
The primary key should be as small as possible. Because the primary key is replicated in every entry of every index, designing the primary key to be as small as possible impacts the efficiency of all the indexes.

Using these 3 simple guidelines on a well-designed schema, InnoDB can perform at its full potential.

Above I mentioned that the primary key is stored in every row of every index. This includes the entire contents of a multi-column primary key. In a future article I will discuss scenarios/designs that can take advantage of this behavior.