tag:blogger.com,1999:blog-12753102.post1950938750245138389..comments2024-03-18T03:44:29.957-04:00Comments on Ben's Journal: MySQL Optimization: A Bit Of KvetchingBen Simonhttp://www.blogger.com/profile/09833753747177544979noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-12753102.post-54132125810643324032007-11-30T15:28:00.000-05:002007-11-30T15:28:00.000-05:00I added in the results of explain above.The union ...I added in the results of explain above.<BR/><BR/>The union does great. It's just that tricky OR that kills it. Pesky boolean operator.<BR/><BR/>There is a primary ID on the table, and the name is also defined with an index.Ben Simonhttps://www.blogger.com/profile/09833753747177544979noreply@blogger.comtag:blogger.com,1999:blog-12753102.post-44810950004013557742007-11-30T08:52:00.000-05:002007-11-30T08:52:00.000-05:00"And those queries above UNION'ed scan, say, 20 ro..."And those queries above UNION'ed scan, say, 20 rows, why should: [...] scan 55,000 rows?!"<BR/><BR/>Ben, did you actually TRY running explain on those two queries UNIONed together, or were you just speaking set-logic-ese?<BR/><BR/>If you didn't literally run a UNION of those queries, would you mind doing that? <BR/><BR/>I could do it myself, but if you've still got your 55000-row table laying around in the same mysql instance, it would be an easier and more useful comparison.<BR/><BR/>That's pretty messed up, though, that the OR condition caused a full table scan. Was a primary key defined?spugbraphttps://www.blogger.com/profile/16847742411835463316noreply@blogger.com