where为什么直接使用字符串判断时间,执行速度还快一些

cloudphoenix 2019-07-14 12:08:32
CREATE_TIME字段时datetime类型,这个表30万数据,执行了0.303秒
SELECT CREATE_TIME from repay_plan
where CREATE_TIME>'2019-05-31 00:00:00'
ORDER BY REPAY_ID desc limit 10000;

而相应的cast和str_to_date 都用了0.342秒
SELECT CREATE_TIME from repay_plan
where CREATE_TIME>cast('2019-05-31 00:00:00' as datetime)
ORDER BY REPAY_ID desc limit 10000;
str_to_date function

SELECT CREATE_TIME from repay_plan
where CREATE_TIME>str_to_date('2019-05-31 00:00:00','%Y-%m-%d %H:%i:%S')
ORDER BY REPAY_ID desc limit 10000;
...全文
145 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
AHUA1001 2019-07-16
  • 打赏
  • 举报
回复
估计您的数据量不大,不要纠结这样的问题。你可以增大数据量,再试试看。
勇敢牛牛_ 2019-07-14
  • 打赏
  • 举报
回复
因为其他两个都用了转换函数啊,调用函数也需要时间呀。
b445208977 2019-07-14
  • 打赏
  • 举报
回复
搞不好是CREATE_TIME加了索引,然后用函数的话没有走索引
勇敢牛牛_ 2019-07-14
  • 打赏
  • 举报
回复
隐式转换后类型是timestamp,其他两个转换后是date和datetime,看你原来列定义的是哪个,如果不是timestamp,仍然需要转换
cloudphoenix 2019-07-14
  • 打赏
  • 举报
回复
引用 1 楼 wxgxgp 的回复:
因为其他两个都用了转换函数啊,调用函数也需要时间呀。
字符串转换,只是启用了隐式转换,而且时间字符串的自动转换允许多种格式,这个解析也要时间的吧 我是想知道更深层的原因。

56,679

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧