> So there is no magic bullet that indexes everything so it works well with > any given query? Does it help to index each field by itself for general > queries and then I guess you index combinations of fields that will be > used together in a WHERE clause? >
Nope, no magic bullet... Indexes speed up selects and sometimes updates, but slow down inserts, deletes, and sometimes updates (for updates it depends on the query and the data, since it can use an index but may also have to update an index). So don't use them where they're not needed. Most data has only a few ways that it is viewed. I probably wouldn't add an index that would only be used once a month :) > Does ORDER BY use indexes too? Would this need an index by md5 and mime or > md5, mime, and path? > > SELECT * from files WHERE md5 = 'blah' AND mime = 'blah' ORDER BY path; > In that case, I think the index across all three, in that order, would help (from what I know of the how MySQL is supposed to work). > Guess I'll hafta work on it. My memory is limited to 32M on this > development machine but I figure the more the development machine sucks > then the faster the code should run on the end server if the code runs > okay on the dev box. :) > Sometimes the biggest difference between dev and live isn't the box it's running on, it's the amount and types of concurrent queries. That can make a huge difference, especially on MyISAM tables. --------------------------------------------------------------------- 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
