一次事故,我对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型吧。
愉快的周末,又向我招手了。
相关文章
- abp(net core)+easyui+efcore实现仓储管理系统——EasyUI前端页面框架 (十八)
- 结对编程,到底是双剑合璧还是脚趾抠地?
- 个性化联邦学习算法框架发布,赋能AI药物研发
- 2021年中国DevOps现状调查报告发布!
- 以两种异步模型应用案例,深度解析Future接口
- AI论文解读丨融合视觉、语义、关系多模态信息的文档版面分析架构VSR
- 云图说 | 华为云医疗智能体,智联大健康,AI药物研发
- 带你走进“华为链”
- Vue组件间的传值五大场景,你造吗?
- 初学者入门知识图谱必看的能力:推理
- 带你探索CPU调度的奥秘
- 鸿蒙轻内核定时器Swtmr:不受硬件和数量限制,满足用户需求
- 云图说|云上应用监控神器——应用性能监控APM2.0
- 带你了解弯曲文本检测算法的两种思路:区域重组和像素分割
- 带你认识MindSpore量子机器学习库MindQuantum
- 论文解读丨Zero-Shot场景下的信息结构化提取
- CWE发布2021年最危险的25种软件缺陷
- AI开发者十问:10分钟了解AI开发的基本过程
- 队列Queue:任务间的消息读写,安排起来~
- 云图说|ROMA演进史:一个ROMA与应用之间不得不说的故事