一次事故,我对MySql时间戳存char(10)还是int(10)有了全新的认识

举报
奔四码农 发表于 2021/05/28 15:31:34 2021/05/28
【摘要】 char类型字段想走索引的话,必须用引号括起来。如果是时间戳等类型的纯数字,建议还是存为int型吧。

美好的周五

周五的早晨,一切都是那么美好。

0.jpg


然而,10点多的时候,运营小哥哥突然告诉我后台打不开了,我怀着一颗“有什么大不了的,估计又是(S)(B)不会连wifi”的心情,自信的打开了网址,果然,真打不开了。

2.jpg


这是存心让我过不好周末呀!

抓住那只bug

经过我缜密的排查,发现是一个“获取今天之前登录的用户”接口调用严重超时:

3.jpg

这个接口其实调用的数据表不多,在mysql只读取了1张表,表结构如下:

6.jpg

获取今天之前登录的用户列表的SQL如下:

SELECT u.email, log.user_id
FROM `user` u
LEFT JOIN `log_user_active` log ON u.user_id = log.user_id
WHERE log.`log_dtime` <1634567890
LIMIT 0 , 30

这只是一个简单的sql查询,并没有什么高精尖、复杂的查询为什么这么慢?由于log_user_active的数据量最大,所以猜想应该是log_user_active表出了问题,为了排查原因,我把SQL又简化了下,去掉了JOIN直接简化为:

SELECT log.user_id
FROM `log_user_active`
WHERE `log_dtime` <1551784072
LIMIT 0 , 30

经执行,这个语句花了将近1秒。。。如果多人同时访问,MySql不崩溃才怪。

7.png

此时,应该确信是这个表出问题无疑了,但是字段log_dtime明明建立了索引,怎么还这么慢呢?

经过各种百度,终于发现问题所在:由于log_dtime设计的是char类型。如果想让他走索引,查询的时候值必须要加引号,说明这是个字符串,否则是不会走索引的。我的数据恰巧都是数字组成(时间戳),查询的时候也没有刻意去加引号,导致查询的时候不走索引。

这就是问题所在了,于是进行如下尝试:

尝试1:

SQL的值加上引号



如上图,果然极快。

但是这样的话,需要改好多代码,我想想还是尝试下方法2吧。

尝试2:

果断将数据表结构log_dtime设计为INT型,如图:



再次执行SQL:

SELECT log.user_id
FROM `log_user_active`
WHERE `log_dtime` <1551784072
LIMIT 0 , 30

相应结果提升N倍:



至此,问题处理完毕。

总结

char类型字段想走索引的话,必须用引号括起来。如果是时间戳等类型的纯数字,建议还是存为int型吧。

一次事故,我对MySql时间戳存char(10)还是int(10)有了全新的认识


愉快的周末,又向我招手了。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。