On Wed, Jan 7, 2009 at 9:17 AM, David Giragosian wrote:
> On 1/7/09, Jim Lyons wrote:
>>
>> There are other factors. If a table is completely fixed in size it makes
>> for a faster lookup time since the offset is easier to compute. This is
>> true, at least, for myisam tables. All books on tun
On 1/7/09, Jim Lyons wrote:
>
> There are other factors. If a table is completely fixed in size it makes
> for a faster lookup time since the offset is easier to compute. This is
> true, at least, for myisam tables. All books on tuning that I have read
> have said the CHAR makes for more effici
There are other factors. If a table is completely fixed in size it makes
for a faster lookup time since the offset is easier to compute. This is
true, at least, for myisam tables. All books on tuning that I have read
have said the CHAR makes for more efficient lookup and comparison that
VARCHAR.
On Wed, Jan 7, 2009 at 2:26 PM, Richard Heyes wrote:
> I still think a CHAR field would be faster than a VARCHAR because of
> the fixed row length (assuming every thing else is fixed). Perhaps
> someone from the MySQL list could clarify...?
Say that your column length goes up to 2000 bytes, but
>>So where's the advantage of VARCHAR ?
>
> Less space on disc = less data retrieved from disc = faster data
> retrieval - sometimes. If you have small columns, a small number of
> rows, or both, then char columns may be faster. If you have large
> columns of varying actual length, lots of rows, or
