Hi!The part about helping out the optimizer rings especially true for me. One one box I take care of:
--cut
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 remain fixed.
What does everyone else think?
--cut
(sigh)
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!)'.
Regards, Frank.
SELECT message FROM syslog WHERE date1 > '2003-12-01' AND message LIKE 'sshd%username';
Execution time: 20.85 seconds
SELECT message FROM syslog FORCE INDEX(date1, message) WHERE date1 > '2003-12-01' AND message
LIKE 'sshd%username';
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
really well."
Regards,
Chris
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
