Dr. Frank Ullrich wrote:
>>To be honest, the vast majority of database installations experience
>>problems in performance caused by poor query and schema design,
>>bad application logic or grossly underspecified hardware. A change in
>>the number of files used to store the data is extremely unlikely
>>to resolve these problems given all other variables in the environment
>>What does everyone else think?
>You're so right.
>Almost every day I find myself hammering on database developers that
>'there should be an index' , 'that index should not be used', 'the join
>order is wrong', 'the app designer should be punished', 'don't use a
>function around an indexed column (unless you use Oracle and have
>function-based indexes)', 'know your data to be able to write the right
>queries and to be able to help the poor optimizer to do a good job',
>'test concurrency, test scalability, test realistically' and so on ...
>But that's the funny thing: when everything is done and deployed and
>__slow__ then 'the database is so slow, do something (immediately!)'.
The part about helping out the optimizer rings especially true for me.
One one box I take care of:
SELECT message FROM syslog WHERE date1 > '2003-12-01' AND message LIKE
Execution time: 20.85 seconds
SELECT message FROM syslog FORCE INDEX(date1, message) WHERE date1 >
'2003-12-01' AND message
Execution time: 0.25 seconds
On that topic, how have all the veteran MySQL users found the optimizer
compared to the other offerings out there?
I remember various interviews with Monty asking questions along the
lines of "What's the most interesting thing to do
in DB development" and similar have almost always been answered with
"Getting an optimizer to actually optimize queries