On Friday 09 November 2001 12:23 am, Steve Meyers wrote: > Tables with variable length rows can get ugly if not optimized > frequently. We had one which was taking 2.5 sec to do an indexed query, > and when we optimized the table it dropped to .2 sec. > > But as long as you keep your tables optimized, variable length rows can > be faster. The main efficiency concern, though, is the size of your > indexes. MySQL keeps your indexes in memory, so smaller indexes are > better. That is why it is best to use hash values when indexing long > character strings (or even fairly short ones). A 32-bit hash value of a > 20-character field takes 1/5 the space. That means five times as much > key can be in memory at once. > > Hope that makes sense... > > Steve Meyers > Makes great sense to me, many thanks. I have often seen varchar used (on many DBs), and often wondered if it was just an easy way out. Most of what I am doing are of transactional nature vs. large char storage. For example, email addy, I've made as varchar(40). However, in light of this thread, I'll just make them char(40) and keep my indices int and bigint. The space savings and additional watchdogging for optimization, in my case do not warrant varchar (IMO).
Many thanks. :-) --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
