一次事故，我对MySQL时间戳存char(10)仍是int(10)有了全新的认识

摘要：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型吧。

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

点击关注，第一时间了解华为云新鲜技术~