That’s good info. The statement doesn’t say anything about performance, but your points about performance are well-taken. The statement is accurate in that it is the most common form used and it does conserve disk disk space and therefore is more efficient from that perspective. Even though disk space is cheap these days, if you have a large table you may not want to burn up space unnecessarily with columns padded with spaces. It depends upon how variable the length of the data might be. However, if performance is a critical issue and every millisecond is important (it frequently is these days), the CHAR type looks like it has the benefits that you pointed out.

For anyone who wants to learn more about the differences, check out the MySQL page on this topic.

The CHAR and VARCHAR Types

varchar (x) vs char (x)

This is not necessarily all true as it may seem to an average everyday reader. “efficient method” in the above sentence uses two words of great meaning but unclarity. “efficient method” is unclear as how the varchar command is efficient. From a MySql expert and MySql database perspective, what this means in the sentence above is limiting disk space only.

The VARCHAR’s only advantage over the CHAR command is limiting disk space. VARCHAR DOES NOT HAVE THE SPEED OF LOOKUPS AND RESULTSETS AS DOES CHAR DOES!!

TO CONSERVE DISK SPACE USE: varchar (x)
FOR SPEED OF RETREIVING RECORDS USE: char (x)

The only difference between the two is how the data is actually stored. You can still have “variable characters” in the CHAR! It’s just the reason that CHAR is so much more faster because it is padded with spaces. And under the MySqL Engine, this is a good thing. It makes insertion and retrieval much faster. Why? Its because the way MySql runs through all the rows and columns to find specific data. And, if the data is not padded in the field, such as when using the VARCHAR (x) MySql runs slower. Especially when your database grows and grows. Most of the time when DBA’s complain about why their database was fast in the beginning but slowed down after a while. This could very well be the culprit.

So, Disk-space is enormousness now days, and CPU speeds are lighting fast. So its up to you to make the call. But from judging that disk-space is cheap, and CPU’s are faster, I banking on CHAR over VARCHAR to be the winner.

But in today’s world of 2010, and how disk-space is very cheap, I would highly recommend using CHAR inplace of varchar. On a database of millions of records, the look-up and retrieval up records overwhelmingly faster.

If a double in general is accurate down to 15 decimal places, is a field defined as double(14,5) or double(20,15) accurate down to 5 resp. 15 decimals? Do I need to maximize the D part of the double(M,D) definition in order to get accurate numbers?