Bug #47884 | MySQL 5.1.39 failed to use index | ||
---|---|---|---|
Submitted: | 7 Oct 2009 3:24 | Modified: | 29 Jan 2010 16:53 |
Reporter: | Dinh Pham | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S2 (Serious) |
Version: | 5.1.39, 5.1.44, 5.5.99 | OS: | Linux (Linux web2 2.6.18-92.1.18.el5.028stab060.8 #1 SMP Mon Feb 9 21:44:50 MSK 2009 x86_64) |
Assigned to: | CPU Architecture: | Any | |
Tags: | INDEX, MySQL5.1, performance, regression, wrongindex |
[7 Oct 2009 3:24]
Dinh Pham
[7 Oct 2009 3:41]
Valeriy Kravchuk
This bug looks like a regression related to "fix" for bug #28404. See bug #46011 also as yet another example of this regression. The only reason why this may be NOT a duplicate of bug #46011 is the fact that you do not order by PRIMARY KEY here.
[7 Oct 2009 6:36]
Dinh Pham
For "ORDER BY comment_count", yes, I don't have any index on the field "comment_count". I have an index "idx_available_comment" on 2 fields: comment_count, available mysql> explain SELECT clip.id FROM clip -> WHERE clip.available = 1 -> AND clip.created_time >= DATE_SUB(CURDATE(), INTERVAL 1 WEEK) -> AND clip.category_id = 5 -> ORDER BY clip.comment_count DESC -> LIMIT 20\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: clip type: range possible_keys: IDX_POSTEDTIME,idx_available,idx_fav_count,idx_hit_count,idx_available_id,idx_category_id,idx_available_comment,id_category_evailable key: idx_available_comment key_len: 2 ref: NULL rows: 473916 Extra: Using where 1 row in set (0.36 sec) MySQL use the index named idx_available_comment that I don't know what operation it is for.
[7 Oct 2009 6:43]
Dinh Pham
Now I tried to remove the phrase ORDER BY to see if there is any change in MySQL behavior mysql> explain SELECT clip.id FROM clip -> WHERE clip.available = 1 -> AND clip.created_time >= DATE_SUB(CURDATE(), INTERVAL 1 WEEK) -> AND clip.category_id = 5 -> LIMIT 20\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: clip type: ref possible_keys: IDX_POSTEDTIME,idx_available,idx_fav_count,idx_hit_count,idx_available_id,idx_category_id,idx_available_comment,id_category_evailable key: id_category_evailable key_len: 4 ref: const,const rows: 4185 Extra: Using where 1 row in set (0.00 sec) It is OK now. Ref const is used and the correct index is used: id_category_evailable Do you think that new query optimizer in MySQL 5.1.39 have choose wrong execution plan when ORDER BY is present?
[7 Oct 2009 7:39]
Valeriy Kravchuk
Yes, it ORDER BY (+LIMIT maybe) that forces optimizer in recent versions to use index that allows to avoid filesort step. This change in behavior is related to (not entirely correct) fix to bug #28404 we made. This index, KEY `idx_available_comment` (`available`,`comment_count`), is used to find rows where available=1 and then scan them is order of comment_count. This avoids filesort, but in your case optimizer's assumption about filesort as very slow step and something to avoid is totally wrong. Looks like you just have too many rows with available=1 comparing to total number of rows in table. Please, check.
[7 Oct 2009 8:12]
Dinh Pham
> Looks like you just have too many rows with available=1 comparing > to total number of rows in table. Please, check. Yes. Here is the detail: mysql> SELECT COUNT(1) FROM clip WHERE available = 1; +----------+ | COUNT(1) | +----------+ | 461937 | +----------+ 1 row in set (0.22 sec) mysql> SELECT COUNT(1) FROM clip; +----------+ | COUNT(1) | +----------+ | 543357 | +----------+ 1 row in set (0.00 sec) mysql> SELECT COUNT(1) FROM clip WHERE category_id = 5; +----------+ | COUNT(1) | +----------+ | 10558 | +----------+ 1 row in set (0.26 sec) That's reason why I have added an index on 2 fields: category_id and available. This index is used by MySQL 5.0.45 efficiently but not by MySQL 5.1.39 Regarding to the fix to http://bugs.mysql.com/bug.php?id=28404 I can not found any report that it is fixed in http://dev.mysql.com/doc/refman/5.1/en/news-5-1-39.html http://dev.mysql.com/doc/refman/5.1/en/news-5-1-38.html http://dev.mysql.com/doc/refman/5.1/en/news-5-1-37.html http://dev.mysql.com/doc/refman/5.1/en/news-5-1-36.html What should I do now to avoid this regression bug? Thanks
[7 Oct 2009 8:34]
Valeriy Kravchuk
Bug #28404 is NOT yet fixed completely and properly. So, surely there is no fix in 5.1.39. As for immediate solution, just use FORCE INDEX to force proper index usage: SELECT clip.id FROM clip FORCE INDEX(id_category_evailable) WHERE clip.available = 1 AND clip.created_time >= DATE_SUB(CURDATE(), INTERVAL 1 WEEK) AND clip.category_id = 5 ORDER BY clip.comment_count DESC LIMIT 20; I can not easily repeat the problem with recent 5.1.40 and my table. Looks like it depends on very specific data distribution. Can you create similar table with only relevant columns (id, available, created_time, category_id and comment_count) and indexes based on current one and upload compressed dump of it to the issue?
[8 Nov 2009 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[8 Nov 2009 13:11]
Dinh Pham
Hi, I have uploaded my sample data to mediafire.com. It can be reached at http://www.mediafire.com/download.php?ygeyzjict4h I will remove it when you finish downloading. Sample queries SELECT clip.id FROM clip WHERE clip.available = 1 AND clip.created_time >= DATE_SUB(CURDATE(), INTERVAL 8 WEEK) AND clip.category_id = 5 ORDER BY clip.comment_count DESC LIMIT 20; SELECT clip.id FROM clip FORCE INDEX (id_category_evailable) WHERE clip.available = 1 AND clip.created_time >= DATE_SUB(CURDATE(), INTERVAL 8 WEEK) AND clip.category_id = 5 ORDER BY clip.comment_count DESC LIMIT 20; Thanks
[8 Nov 2009 14:12]
Valeriy Kravchuk
I've downloaded the file successfully.
[29 Jan 2010 16:53]
Sveta Smirnova
Thank you for the feedback. Set to "Verified", because bug is repeatable and you don't order by primary key.
[29 Nov 2012 17:27]
Sveta Smirnova
See also bug #67589