类型隐式转换导致的?No,并不是

简介: 类型隐式转换导致的?No,并不是

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


请教个隐式转换的问题:
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的执行计划是这样的

image.png

对于第二个疑问:为什么会走全表扫描计划呢?

我的看法是这样的:首先,上面的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 NULLt IS NOT NULL才对。所以,这么写的话,这个查询是不会有任何结果的,包括列值为NULL的数据。

最后的小结:

  1. 写SQL时,WHERE条件值记得总是带上引号,避免发生意想不到的情况。
  2. 对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
  1. 除了防范类型隐式转换,还要注意防范字符集隐式转换,具体参考MySQL手册12.2 Type Conversion in Expression Evaluation
            </div>
相关文章
|
3天前
|
弹性计算 运维 搜索推荐
三翼鸟携手阿里云ECS g9i:智慧家庭场景的效能革命与未来生活新范式
三翼鸟是海尔智家旗下全球首个智慧家庭场景品牌,致力于提供覆盖衣、食、住、娱的一站式全场景解决方案。截至2025年,服务近1亿家庭,连接设备超5000万台。面对高并发、低延迟与稳定性挑战,全面升级为阿里云ECS g9i实例,实现连接能力提升40%、故障率下降90%、响应速度提升至120ms以内,成本降低20%,推动智慧家庭体验全面跃迁。
|
3天前
|
数据采集 人工智能 自然语言处理
3分钟采集134篇AI文章!深度解析如何通过云无影AgentBay实现25倍并发 + LlamaIndex智能推荐
结合阿里云无影 AgentBay 云端并发采集与 LlamaIndex 智能分析,3分钟高效抓取134篇 AI Agent 文章,实现 AI 推荐、智能问答与知识沉淀,打造从数据获取到价值提炼的完整闭环。
354 91
|
4天前
|
SQL 人工智能 自然语言处理
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
随着生成式AI的普及,Geo优化(Generative Engine Optimization)已成为企业获客的新战场。然而,缺乏标准化流程(Geo优化sop)导致优化效果参差不齐。本文将深入探讨Geo专家于磊老师提出的“人性化Geo”优化体系,并展示Geo优化sop标准化如何帮助企业实现获客效率提升46%的惊人效果,为企业在AI时代构建稳定的流量护城河。
376 156
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
|
4天前
|
域名解析 人工智能
【实操攻略】手把手教学,免费领取.CN域名
即日起至2025年12月31日,购买万小智AI建站或云·企业官网,每单可免费领1个.CN域名首年!跟我了解领取攻略吧~
|
10天前
|
人工智能 自然语言处理 前端开发
Qoder全栈开发实战指南:开启AI驱动的下一代编程范式
Qoder是阿里巴巴于2025年发布的AI编程平台,首创“智能代理式编程”,支持自然语言驱动的全栈开发。通过仓库级理解、多智能体协同与云端沙箱执行,实现从需求到上线的端到端自动化,大幅提升研发效率,重塑程序员角色,引领AI原生开发新范式。
885 156
|
3天前
|
数据采集 缓存 数据可视化
Android 无侵入式数据采集:从手动埋点到字节码插桩的演进之路
本文深入探讨Android无侵入式埋点技术,通过AOP与字节码插桩(如ASM)实现数据采集自动化,彻底解耦业务代码与埋点逻辑。涵盖页面浏览、点击事件自动追踪及注解驱动的半自动化方案,提升数据质量与研发效率,助力团队迈向高效、稳定的智能化埋点体系。(238字)
261 156
|
11天前
|
机器人 API 调度
基于 DMS Dify+Notebook+Airflow 实现 Agent 的一站式开发
本文提出“DMS Dify + Notebook + Airflow”三位一体架构,解决 Dify 在代码执行与定时调度上的局限。通过 Notebook 扩展 Python 环境,Airflow实现任务调度,构建可扩展、可运维的企业级智能 Agent 系统,提升大模型应用的工程化能力。