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

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

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

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