MySQL Bugs: #3694: HANDLER .. READ gives spurious results!

Bug #3694	HANDLER .. READ gives spurious results!
Submitted:	8 May 2004 13:22	Modified:	19 May 2004 21:36
Reporter:	Denis Filimonov	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.0.17	OS:
Assigned to:	Sergey Petrunya	CPU Architecture:	Any

Description:
mysql> handler tmp_post read `userid` = (1031) where attachmentid = 11111; 
+--------+--------+--------------+ 
| postid | userid | attachmentid | 
+--------+--------+--------------+ 
| 100318 |   7152 |        11111 | 
+--------+--------+--------------+ 
1 row in set (0.84 sec) 
------------ 
That is when there is no row matching both KEY and WHERE conditions it returns 
a row which meets WHERE condition only. 
It seems the problems occurs only when a large table involved (this particular 
one has 500,000+ rows), when I tried a tiny table it worked as expected. 

How to repeat:
1. Have a table: 
CREATE TABLE `tmp_post` ( 
  `postid` int(10) unsigned NOT NULL default '0', 
  `userid` int(10) unsigned NOT NULL default '0', 
  `attachmentid` smallint(5) unsigned NOT NULL default '0', 
  PRIMARY KEY  (`postid`), 
  KEY `userid` (`userid`) 
) TYPE=MyISAM; 
 
2. Populate it with lots of records (559524 in the case) 
 
3. Run queries: 
mysql> handler tmp_post open; 
Query OK, 0 rows affected (0.00 sec) 
 
mysql> handler tmp_post read `userid` = (1031) where attachmentid = 11111; 
+--------+--------+--------------+ 
| postid | userid | attachmentid | 
+--------+--------+--------------+ 
| 100318 |   7152 |        11111 | 
+--------+--------+--------------+ 
1 row in set (1.23 sec) 
 
userid is wrong!! 
 
mysql> handler tmp_post read `userid` = (7152) where attachmentid = 11111; 
+--------+--------+--------------+ 
| postid | userid | attachmentid | 
+--------+--------+--------------+ 
| 100318 |   7152 |        11111 | 
+--------+--------+--------------+ 
1 row in set (0.01 sec) 
 
correct! 
 
 

Suggested fix:
Please note the time taken (it does not depend on the order, so cannot be 
explained by caching), it looks like the former (wrong) one perform a full 
table scan when it should return "no records" result.

Verified against 4.0.19; thank you for the report.  Test case to be attached.

Changing Category as this occurs with InnoDB as well.

ChangeSet@1.1836, 2004-05-18 22:59:43+04:00, sergefp@mysql.com
  Fix and test case for BUG#3649.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

ChangeSet@1.1835.1.2, 2004-05-19 02:18:54+04:00, sergefp@mysql.com
  Fix for BUG33649: Post-review fixes 

ChangeSet@1.1835.1.1, 2004-05-18 22:59:43+04:00, sergefp@mysql.com
  Fix and test case for BUG#3649.