Marc Van Olmen wrote:
> Jay,
>
> thx for writing this down.
No problem at all, any time!
> because SELECT PRY_INDEX
> FROM T_PROPERTY
> ORDER BY PRY_EXPORT_CITY
>
> is super fast: 0.0074
> I was hoping for more progress....
Cool. see below.
> I have a few other ideas on how to optimize this
> query most of the ideas are based on keeping an
> extra table with the sorting order seperate etc..
> so insert is more expensive... also will try out a
> few other database on how they behave in this kind
> of situtation, I tested openbase and that one is
> slower. Also gonna test postgressql just out of
> curiosity I don't have time now but in a week or
> so...
The best thing you can do to increase the efficiency of your queries, IMHO, is to trim the table definitions down to the absolute minimum you can. First off, change your CHAR(xx) to VARCHAR(xx) for the longish fields, and stop using so many NULLable fields. Separate off NULLable fields into its own table (see my earlier post) and trim the field data types down as much as possible...
Also, consider using MyISAM instead of InnoDB unless you are actually utilizing the transactional components of InnoDB... InnoDB is fast, but because of the extra effort expended to ensure the transactional consistency, can sometimes be slower than MyISAM. If you stay with InnoDB, you can ignore my comment about the CHAR/VARCHAR thing, because InnoDB treats them the same way. However, *do* consider changing your VARCHAR(1624) fields to the TEXT data type, which will store a pointer to the text instead the actual data (in most cases).
> thx again, will defintely buy a copy of your book
> for all your efforst.
:)
Jay Pipes
Community Relations Manager, North America, MySQL Inc.
Got Cluster?
http://www.mysql.com/cluster
Personal:
http://jpipes.com