Kommentarer till Stupid SQL optimization http://bitcomplex.se/webbutveckling/stupid-sql-optimization/ better living through transparency Fri, 30 Dec 2011 10:47:00 +0000 hourly 1 http://wordpress.org/?v=3.3 Av: Lloyd Watkin http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-95 Lloyd Watkin Thu, 09 Sep 2010 16:35:00 +0000 http://bitcomplex.se/?p=299#comment-95 You seem to be using date always, why not make it the second key in the index and make `item_id` the last one, that way no need to include ` You seem to be using date always, why not make it the second key in the index and make `item_id` the last one, that way no need to include `

]]> Av: Eli http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-96 Eli Thu, 09 Sep 2010 16:35:00 +0000 http://bitcomplex.se/?p=299#comment-96 Any reason you didn't just use the 'USE INDEX' or 'FORCE INDEX' parameters to your query to tell MySQL the index you wanted? It's always worked for me in the past when it wasn't behaving. Docs: http://dev.mysql.com/doc/refman/5.1/en/index-hints.html Any reason you didn’t just use the ‘USE INDEX’ or ‘FORCE INDEX’ parameters to your query to tell MySQL the index you wanted? It’s always worked for me in the past when it wasn’t behaving.

Docs:
http://dev.mysql.com/doc/refman/5.1/en/index-hints.html

]]> Av: bitcomplex http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-98 bitcomplex Thu, 09 Sep 2010 14:41:00 +0000 http://bitcomplex.se/?p=299#comment-98 Since MySQL stops using the remainder of the index as soon as it find a range the where clause would never be able to use the item_id part of the index. Since MySQL stops using the remainder of the index as soon as it find a range the where clause would never be able to use the item_id part of the index.

]]> Av: bitcomplex http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-97 bitcomplex Thu, 09 Sep 2010 14:37:00 +0000 http://bitcomplex.se/?p=299#comment-97 It used the correct (and only) index to begin with. It just couldn't use more than the first part/column of it. It used the correct (and only) index to begin with. It just couldn’t use more than the first part/column of it.

]]> Av: Rad http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-94 Rad Tue, 07 Sep 2010 19:54:00 +0000 http://bitcomplex.se/?p=299#comment-94 that's why I personally prefer either ProgrSQL or even MSSQL over MySQL. In respect to the case - have you checked your execution plan and statistics? Cheers! that’s why I personally prefer either ProgrSQL or even MSSQL over MySQL.
In respect to the case – have you checked your execution plan and statistics?
Cheers!

]]> Av: bitcomplex http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-60 bitcomplex Sat, 04 Sep 2010 08:50:00 +0000 http://bitcomplex.se/?p=299#comment-60 Simply because we do not have to, since we managed to fix it this way. ;) No actually, the index mentioned is only a part of a larger covering index. Having two covering indices on the same table would be puhing it a bit. The table uses enough disc space as it is with Xkk rows to begin with. And it's growing constantly. Simply because we do not have to, since we managed to fix it this way. ;)
No actually, the index mentioned is only a part of a larger covering index. Having two covering indices on the same table would be puhing it a bit. The table uses enough disc space as it is with Xkk rows to begin with. And it’s growing constantly.

]]> Av: bitcomplex http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-93 bitcomplex Sat, 04 Sep 2010 08:50:00 +0000 http://bitcomplex.se/?p=299#comment-93 Simply because we do not have to, since we managed to fix it this way. ;) No actually, the index mentioned is only a part of a larger covering index. Having two covering indices on the same table would be puhing it a bit. The table uses enough disc space as it is with Xkk rows to begin with. And it's growing constantly. Simply because we do not have to, since we managed to fix it this way. ;)
No actually, the index mentioned is only a part of a larger covering index. Having two covering indices on the same table would be puhing it a bit. The table uses enough disc space as it is with Xkk rows to begin with. And it’s growing constantly.

]]> Av: Johan Sölve http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-59 Johan Sölve Sat, 04 Sep 2010 08:41:52 +0000 http://bitcomplex.se/?p=299#comment-59 The MysQL query optimizer is a bit dumb at times. But why not just add another index without item_id? The MysQL query optimizer is a bit dumb at times. But why not just add another index without item_id?

]]> Av: Johan Sölve http://bitcomplex.se/webbutveckling/stupid-sql-optimization/#comment-92 Johan Sölve Sat, 04 Sep 2010 08:41:00 +0000 http://bitcomplex.se/?p=299#comment-92 The MysQL query optimizer is a bit dumb at times. But why not just add another index without item_id? The MysQL query optimizer is a bit dumb at times. But why not just add another index without item_id?

]]>