美好的周五
周五的早晨，一切都是那么美好。
然而，10点多的时候，运营小哥哥突然告诉我后台打不开了，我怀着一颗“有什么大不了的，估计又是（S）（B）不会连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型吧。
愉快的周末，又向我招手了。
