Bug #32198 Comparison of DATE with DATETIME still not using indexes correctly

Submitted: 8 Nov 2007 21:03 Modified: 19 Dec 2007 5:19
Reporter: Dave Costantino Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Data Types Severity:S2 (Serious)
Version:5.0.50, 5.0.52-BK OS:Linux
Assigned to: Sergey Petrunya CPU Architecture:Any
Tags: regression

[8 Nov 2007 21:03] Dave Costantino
Description:
When comparing DATEs with DATETIMEs, MySQL 5.0.50 does not appear to use indexes properly. This results in extremely poor performance when compared with previous versions such as 5.0.30.

Note that I previously reported this issue as bug #29031.  It does not appear to have been fixed, even though it was marked as duplicate and supposedly fixed a few releases back.

How to repeat:
Create a table with some DATE values:

CREATE TABLE `test1` (
  `id` int(11) NOT NULL auto_increment,
  `dateval` date default NULL,
  PRIMARY KEY  (`id`),
  KEY `dateval` (`dateval`)
) ENGINE=MyISAM AUTO_INCREMENT=173 DEFAULT CHARSET=latin1;

INSERT INTO `test1` VALUES
(1,'2007-01-01'),(2,'2007-01-02'),(3,'2007-01-03'),(4,'2007-01-04'),
(5,'2007-01-05'),(6,'2007-01-06'),(7,'2007-01-07'),(8,'2007-01-08'),
(9,'2007-01-09'),(10,'2007-01-10'),(11,'2007-01-11');

Run EXPLAINs on a simple select against a DATE range, then against a select for the
corresponding DATETIME range:

Date:

mysql> explain select * from test1 where dateval >= '2007-01-01' and dateval <=
'2007-01-02';
+----+-------------+-------+-------+---------------+---------+---------+------+------+----
---------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows |
Extra       |
+----+-------------+-------+-------+---------------+---------+---------+------+------+----
---------+
|  1 | SIMPLE      | test1 | range | dateval       | dateval | 4       | NULL |    2 |
Using where |
+----+-------------+-------+-------+---------------+---------+---------+------+------+----
---------+
1 row in set (0.00 sec)

DateTime:

mysql> explain select * from test1 where dateval >= '2007-01-01 00:00:00' and dateval <=
'2007-01-02 23:59:59';
+----+-------------+-------+------+---------------+------+---------+------+------+--------
-----+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra  
    |
+----+-------------+-------+------+---------------+------+---------+------+------+--------
-----+
|  1 | SIMPLE      | test1 | ALL  | dateval       | NULL | NULL    | NULL |   11 | Using
where |
+----+-------------+-------+------+---------------+------+---------+------+------+--------
-----+
1 row in set (0.00 sec)

In the second example you can see that it is doing a full scan, and not using the index.
For large data sets this is very slow.

If I try this on a 5.0.30 server, I see consistent and correct results in both cases.

Suggested fix:
DateTime to Date conversions should use indexes when possible..
[11 Nov 2007 11:58] Valeriy Kravchuk
Thank you for a problem report. Verified just as described with latest 5.0.52-BK. I think, it is a bug, as this page, http://dev.mysql.com/doc/refman/5.0/en/type-conversion.html, does NOT say anything specific about DATETIME to DATE conversion. This:

"If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed."

does NOT apply, as we have a DATE column that is compared to DATETIME constant. So, constant should be converted to column's type, and then index will be used.
[13 Nov 2007 4:53] Valeriy Kravchuk
Bug #32002 was marked as a duplicate of this one.
[12 Dec 2007 14:37] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/39782

ChangeSet@1.2595, 2007-12-12 17:35:52+03:00, sergefp@mysql.com +4 -0
  BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
  - Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable
[13 Dec 2007 10:39] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/39880

ChangeSet@1.2595, 2007-12-13 13:38:22+03:00, sergefp@mysql.com +4 -0
  BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
  - Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable
[14 Dec 2007 8:14] Bugs System
Pushed into 5.0.54
[14 Dec 2007 8:17] Bugs System
Pushed into 5.1.23-rc
[14 Dec 2007 8:20] Bugs System
Pushed into 6.0.5-alpha
[19 Dec 2007 5:19] Paul DuBois
Noted in 5.0.54, 5.1.23, 6.0.5 changelogs.

For comparisons of the form date_col OP datetime_const (where OP is
=, <, >, <=, or >=), the comparison is done using DATETIME values,
per the fix for Bug#27590. However that fix caused any index on
date_col not to be used and compromised performance. Now the index is
used again.
[12 Mar 2010 5:51] bhushan uparkar
I am using mysql 5.0.77 , but I am seeing this problem again.
======
mysql> select version();
+---------------+
| version()     |
+---------------+
| 5.0.77-10-log | 
+---------------+
#
CREATE TABLE `test2` (
  `id` int(11) NOT NULL auto_increment,
  `dateval` datetime default NULL,
  PRIMARY KEY  (`id`),
  KEY `dateval` (`dateval`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=latin1;
#
INSERT INTO `test2` VALUES (1,'2007-01-01'),(2,'2007-01-02'),(3,'2007-01-03'),(4,'2007-01-04'), (5,'2007-01-05'),(6,'2007-01-06'),(7,'2007-01-07'),(8,'2007-01-08'), (9,'2007-01-09'),(10,'2007-01-10'),(11,'2007-01-11');
#
 explain select * from test2 where dateval > '2007-01-01' and dateval < '2007-01-02' \G*************************** 1. row ***************************           id: 1  select_type: SIMPLE
        table: test2
         type: index
possible_keys: dateval
          key: dateval
      key_len: 9
          ref: NULL
         rows: 11
        Extra: Using where; Using index
[24 Jun 2013 8:13] Dimitri Vanoverbeke
Same issue it seems on a mysql 5.0.77

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.079 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.