Is there any reason to worry about the column order in a table?

Question

I know you can ALTER the column order in MySQL with FIRST and AFTER, but why would you want to bother? Since good queries explicitly name columns when inserting data, is the

Answer 1

In 2002, Bill Thorsteinson posted on the Hewlett Packard forums his suggestions for optimizing MySQL queries by reordering the columns. His post has since been literally copied and pasted at least a hundred times on the Internet, often without citation. To quote him exactly...

General rules of thumb:

• Primary key columns first.
• Foreign key columns next.
• Frequently-searched columns next.
• Frequently-updated columns later.
• Nullable columns last.
• Least-used nullable columns after more-frequently used nullable columns.
• Blobs in own table with few other columns.

Source: HP Forums.

But that post was made all the back in 2002! This advice was for MySQL version 3.23, more than six years before MySQL 5.1 would be released. And there are no references or citations. So, was Bill right? And how exactly does the storage engine work at this level?

1. Yes, Bill was right.
2. It all comes down to a matter of chained rows and memory blocks.

To quote Martin Zahn, an Oracle-certified professional, in an article on The Secrets of Oracle Row Chaining and Migration...

Chained rows affect us differently. Here, it depends on the data we need. If we had a row with two columns that was spread over two blocks, the query:

SELECT column1 FROM table

where column1 is in Block 1, would not cause any «table fetch continued row». It would not actually have to get column2, it would not follow the chained row all of the way out. On the other hand, if we ask for:

SELECT column2 FROM table

and column2 is in Block 2 due to row chaining, then you would in fact see a «table fetch continued row»

The rest of the article is a rather good read! But I am only quoting the part here that is directly relevant to our question at hand.

More than 18 years later, I gotta say it: thanks, Bill!