关于mysql:一次事故我对MySQL时间戳存char10还是int10有了全新的认识

35次阅读

共计 1137 个字符,预计需要花费 3 分钟才能阅读完成。

摘要:char 类型字段想走索引的话,必须用引号括起来。如果是工夫戳等类型的纯数字,倡议还是存为 int 型吧。

本文分享自华为云社区《一次事变,我对 MySql 工夫戳存 char(10) 还是 int(10) 有了全新的意识》,原文作者:奔四码农。

美妙的周五

周五的晚上,一切都是那么美妙。

然而,10 点多的时候,经营小哥哥忽然通知我后盾打不开了,我怀着一颗“有什么大不了的,预计又是他不会连 wifi”的情绪,自信的关上了网址,果然,真打不开了。

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

抓住那只 bug

通过我周密的排查,发现是一个“获取明天之前登录的用户”接口调用重大超时:

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

获取明天之前登录的用户列表的 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 不解体才怪。

此时,应该确信是这个表出问题无疑了,然而字段 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 型吧。

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

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0