Professional Documents
Culture Documents
Home
About
Submit
Search
<S> //webdevelopmentstuff
ready-to-use resources, tutorials, tips and many other web development related stuff
Knowledges
Licences
Resources
www.webdevelopmentstuff.com changed to www.webdevstuff.com
1/5
1/29/2015
Fred says:
July 29, 2009 at 4:51 am
unix_timestamp(art.StartDate) = unix_timestamp(now())
will NEVER use the fields index,
because the date is calculated/converted.
The indexed field must be pure,
for instance, if you have an indexed datetime field and do date comparison with it, it wont uses the index on that field.
You should rewrite it as:
art.StartDate >= current_date
art.ExpiryDate >= current_date
or if its a DateTime
art.StartDate >= now()
art.ExpiryDate >= now()
If you really need some calculation to be done, then you must rewrite the condition such that the indexed field is pure and the condition is not and can
be computed before the index is used
For instance:
DATE_SUB(CURRENT_DATE,INTERVAL 30 DAY) <= art.ExpiryDate;
== (constant <= field)
is faster than:
CURRENT_DATE <= DATE_ADD(art.ExpiryDate,INTERVAL 30 DAY);
== (constant <= computed(field))
Also, you are using two fields to be ordered by which are not "explicitly" being stated in your SELECT uncomputed
Normally you should never uses *,
except for debugging, if you upgrade your schema, then your application logic may break.
Did you try EXPLAIN SELECT ?
2.
Teddy says:
July 30, 2009 at 9:05 am
I absolutely understand what you are writing about, Fred. But in this case Ive just pasted whole statement as it was originaly writen by the authors of
that software. I realize that there are more deficiencies, but this one was used for demonstration purposes only. Nevertheless, I appreciate your
comment, Im sure it will be helpfull for all readers.
http://www.webdevstuff.com/119/optimizing-mysql-importance-of-join-order.html
2/5
1/29/2015
3.
Tobias J says:
August 9, 2009 at 9:26 am
Do you proof read your articles?
If so, you should have someone else do it for you.
Good topic though.
4.
Teddy says:
August 9, 2009 at 11:20 am
Why? Is there something wrong with it?
5.
6.
Henry says:
April 24, 2010 at 5:45 pm
Join order does not matter in MYSQL. The optimizer does a quite good job at figuring out the best join order. Do you have indexes on the columns
you are using in the join condition? If not, MySQL has no data to use for choosing the best join order and seems to just use the same order as used in
the query. I did not consider
such a case as you usually have those indexes to get those such queries done
in a reasonable time.If MySQL gets the join order wrong although there are indexes, try to run OPTIMIZE TABLE on the tables to get up to date
statistics.
7.
Mojtaba says:
April 25, 2010 at 2:04 pm
Great. I was in trouble by the same problem and your article helped me very much.
Thank you in advance.
8.
Jan K says:
October 4, 2011 at 2:29 pm
Hello Teddy,
thank you very much for your article which has been very helpful to me.
I did not know about the STRAIGHT_JOIN command in MySQL. I had written down my joins in the best order, used indexes and multiple join
conditions to decrease the number of rows, and wondered why the execution time was still so long until I read, that the tables can be put into the
wrong order by MySQL.
After that I added STRAIGHT_JOIN to my command and voila the execution time decreased from 2 minutes to 2 seconds
Thank you so much.
Greetings from Germany.
9.
10.
http://www.webdevstuff.com/119/optimizing-mysql-importance-of-join-order.html
3/5
1/29/2015
11.
Geza says:
August 27, 2012 at 10:08 pm
It was also useful for me, not for a performance issue, but because I wanted to keep the order of the records in my first table while attaching some
information from other tables. STRAIGHT_JOIN did that for me.
Thanks!
P.S. I dont know if you did that, but you couldve helped the company and yourself by giving them your improvements, and negotiating some benefit
theyd give you in return. Hmm?
12.
Jarred says:
January 29, 2013 at 8:36 pm
Holly s**t! I spent several days trying to optimize one of the query which joins one large table multiple times. This query took longer than 30 minute!!!
And what finally helped? It was enough to add STRAIGHT_JOIN and the query takes only 5 seconds! Many thanks for this tip!
13.
Piemol says:
May 15, 2013 at 2:21 pm
Thanks for sharing your solution!
My query executed in 75 seconds,
the EXPLAIN showed me the tables were joined in reverse order, while the ORDER BY needed only columns from the first table in the query.
Adding STRAIGHT_JOIN to the query resulted in a execution time of 0,08 seconds, yes I can optimize my queries, and yes, mysql can be wrong
sometimes
Categories
Resources
CMS Software
Code Bytes
Frameworks
Funny
Graphics
Libraries
Templates
Web Applications
Knowledges
How-To
News
References
Standards
Tools
Tutorials
Licences
Academic Free
Apache Licence
BSD Licence
CC Licence
Commercial Stuff
Free Stuff
GPL
LGPL
MIT Licence
Open Source
Other License
Uncategorized
Tag Cloud
ajax asp browsers charts colors css dhtml dom drupal e-commerce ecma editors effects extension flash fonts graphs html icons javascript
joomla jquery layout mambo mysql online oscommerce performance photo photoshop php plugin programming prototype ruby security
social sql video w3c wordpress xhtml xml youtube zencart
Recent Posts
Best Particles for Websites Landing Pages
http://www.webdevstuff.com/119/optimizing-mysql-importance-of-join-order.html
4/5
1/29/2015
http://www.webdevstuff.com/119/optimizing-mysql-importance-of-join-order.html
5/5