类型隐式转换致使的？No，并非

本文做者：叶金荣，知数堂联合创始人，MySQL DBA课程讲师。Oracle MySQL ACE，MySQL布道师。有多年MySQL及系统架构设计经验，擅长MySQL企业级应用、数据库设计、优化、故障处理等。

疑似类型隐式转换一例

有群友提了下面这样的问题

请教个隐式转换的问题：
SELECT count(*) FROM test WHERE time >= 2019-05-17;
time列是datetime类型，
这条SQL的执行结果是至关于 where 1, 这个是什么缘由呢？

SQL执行有个warnings：
Warning | 1292 | Incorrect datetime value: '1997' for column 'time' at row

从告警信息来看，是把 2019-05-17 作了数学减法运算，获得常量 1997, 
再把常量1997转换为 datetime 类型，再跟time字段作比较。

但用函数 cast(1997 as datetime)，也是一样的告警信息，但结果是 NULL

那么该SQL是否能够等价为：
SELECT count(*) FROM test WHERE time >= NULL

这个SQL结果会是0，由于跟NULL值比较的结果是NULL。

虽然WHERE条件错写成一个算式，但执行时没有报错，只有一个告警信息，

感受仍是由于发生了类型隐式转换，用不到索引，不然不会是全表扫描。

这是个人第一次回复内容

事实上，条件 WHERE time >= 2019-05-17，
的意思是：time >= 1997，这是表达式 2019-05-17 的结算结果。
这个不是类型隐式转换，是你SQL没写对。

咱们看到SQL的执行计划是这样的

对于第二个疑问：为何会走全表扫描计划呢？

个人见解是这样的：首先，上面的SQL条件至关于 WHERE time >= 1997。其次，MySQL认为"1997"不是合法的日期时间类型数据，看到执行计划中有告警

Incorrect datetime value: '1997' for column

所以，time >= 1997 这个条件，就会被当作一个逻辑表达式，由于不是 0（FALSE），也不是 NULL，因此就会被认为是永远为真（TRUE）。也就是说，time列中全部不是FALSE或NULL的值都符合条件。

咱们能够测试确认这个说法：

# 表中dt列是datetime类型，但容许为NULL
[root@yejr.me]> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `c1` int NOT NULL,
...
  `dt` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`c1`),
  KEY `k2` (`dt`)
) ENGINE=InnoDB;


# 查看全部数据
[root@yejr.me]> select * from t1;
+-----+-----+---------------------+
| c1  | ... | dt                  |
+-----+-----+---------------------+
|   2 | ... | NULL                |
|   3 | ... | 2017-11-01 15:44:27 |
|   5 | ... | 2020-02-13 16:02:55 |
+-----+-----+---------------------+
3 rows in set (0.00 sec)


# c1=2的记录中，dt列值为NULL，不符合条件
[root@yejr.me]> select * from t1 where dt >= 1997;
+-----+-----+---------------------+
| c1  | ... | dt                  |
+-----+-----+---------------------+
|   3 | ... | 2017-11-01 15:44:27 |
|   5 | ... | 2020-02-13 16:02:55 |
+-----+-----+---------------------+
2 rows in set (0.00 sec)

很明显，只要表中dt列值不为NULL、不为0（符合日期时间格式的数据也确定不会是0）的数据都会被读取到。

这种状况下，即使dt列有索引，也会由于须要扫描的数据太多，从而优化器认为直接走全表扫描的效率要更好，因此也没法使用索引。

还有个疑问，WHERE条件写成 time >= cast(1997 as datetime) 时会怎样？这种状况下，由于 cast(1997 as datetime) 的结果是 NULL，因此WHERE条件等同于time>= NULL，对NULL的运算是不能这么写的，而应该写成 dt IS NULL 或 t IS NOT NULL才对。因此，这么写的话，这个查询是不会有任何结果的，包括列值为NULL的数据。

最后的小结：

一、写SQL时，WHERE条件值记得老是带上引号，避免发生意想不到的状况。

二、对NULL值的判断，必须是用 IS NULL 或 IS NOT NULL，不能是大小值的判断。另外，WHERE条件中的NULL实际上是能够用到索引的，例如：

[root@yejr.me]> desc select * from t1 where dt is NULL\G
************************ 1. row ************************
           id: 1
  select_type: SIMPLE
        table: t1
   partitions: NULL
         type: ref
possible_keys: k2
          key: k2
      key_len: 5
          ref: const
         rows: 1
     filtered: 100.00
        Extra: Using where

三、除了防范类型隐式转换，还要注意防范字符集隐式转换，具体参考MySQL手册12.2 Type Conversion in Expression Evaluation。