11 messages in com.mysql.lists.win32RE: Performance Issues
FromSent OnAttachments
Lee Leahu21 Feb 2002 17:02 
Arjen Lentz21 Feb 2002 19:29 
Pete French22 Feb 2002 02:26 
Arjen Lentz22 Feb 2002 03:05 
Pete French22 Feb 2002 03:17 
Pete French22 Feb 2002 03:23 
Alex Speed22 Feb 2002 03:32 
Lee Leahu22 Feb 2002 08:30 
Januski, Ken22 Feb 2002 13:16 
Arjen Lentz24 Feb 2002 19:57 
Arjen Lentz24 Feb 2002 20:01 
Subject:RE: Performance Issues
From:Januski, Ken (kjan@phillynews.com)
Date:02/22/2002 01:16:00 PM
List:com.mysql.lists.win32

Hi,

I've been following this thread as a learner rather than someone who can shed much light on how to optimize sql. And I've learned quite a bit. But I do wonder about your use of grep. I use grep quite a bit but have often found that sometimes using perl can be quicker. Is there any possibility that grep is also slowing things down?

Ken

-----Original Message----- From: Lee Leahu [mailto:le@ricis.com] Sent: Friday, February 22, 2002 11:31 AM To: Arjen Lentz Cc: win@lists.mysql.com Subject: Re: Performance Issues

Hi Arjen!

Thank you for the heads up on the text columns. My boss when on to further explain that the database server does searching (like grep) on the text fields, and binary compares on the varchar, char, int fields.

What datatype do you recomend for the DECIMAL(n,n) types? Would double or float work?

I picked up a copy of Mascon and used that to change my types, along with a perl script I wrote to find the maximum length of data in a given field.

At 21:30 2002-02-21, you wrote:

Regarding types.... - You'll want to change all those TEXT columns into CHAR (or VARCHAR); that is, as long as you're sure they're <= 255 chars. - The columns that are DECIMAL(n,0) should be declared as a type of INT. Depending on their max range: TINYINT UNSIGNED (for 0-255), SMALLINT UNSIGNED (for 0-65535), MEDIUMINT or INT. For a quick but less than optimal fix, you can make 'em all just plain INT.

And indexes... Do you realise that right now the server has to scan through the entire table to find the records? You'll need indexes on orders.custid, principl.id, customer.id

There's way more to say about the used types, making fields not NULL, the fact that it's not very economic to do searches/joins on string columns, but.... the above hints should already help you get a useable result.

You posted the output of some EXPLAIN statements... but just a "EXPLAIN SELECT * FROM table". That won't tell you anything. EXPLAIN is used to see how the server will process your REAL queries. So you stick the word EXPLAIN in front of the real query, and then look at the output. It will tell you in which order the tables are joined, and whether (and in what way) indexes are being used. Doing joins where an index can't be used will always be slow.