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

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

美妙的周五

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

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

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

抓住那只bug

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

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

获取明天之前登录的用户列表的SQL如下：

SELECT u.email, log.user_idFROM `user` uLEFT JOIN `log_user_active` log ON u.user_id = log.user_idWHERE log.`log_dtime` <1634567890LIMIT 0 , 30

这只是一个简略的SQL查问，并没有什么高精尖、简单的查问为什么这么慢？因为log_user_active的数据量最大，所以猜测应该是log_user_active表出了问题，为了排查起因，我把SQL又简化了下，去掉了JOIN间接简化为：

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

经执行，这个语句花了将近1秒。。。如果多人同时拜访，MySQL不解体才怪。

此时，应该确信是这个表出问题无疑了，然而字段log_dtime明明建设了索引，怎么还这么慢呢？

通过各种百度，终于发现问题所在：因为log_dtime设计的是char类型。如果想让它走索引，查问的时候，值必须要加引号，阐明这是个字符串，否则是不会走索引的。我的数据凑巧都是数字组成（工夫戳），查问的时候也没有刻意去加引号，导致查问的时候不走索引。

这就是问题所在了，于是进行如下尝试：

尝试1：

SQL的值加上引号

如上图，果然极快。

然而这样的话，须要改好多代码，我想想还是尝试下办法2吧。

尝试2：

果决将数据表构造log_dtime设计为INT型，如图：

再次执行SQL：

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

相应后果晋升N倍：

至此，问题处理完毕。

总结

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

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

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