一次线上事故,让我对MySql的时间戳存char(10)还是int(10)有了全新的认识
美好的周五
周五的早晨,一切都是那么美好。
然鹅,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型吧。
愉快的周末,又向我招手了。
一次线上事故,让我对MySql的时间戳存char(10)还是int(10)有了全新的认识相关推荐
- “���”引发的线上事故
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章 最近遇到了一起依赖升级 + 异常数据引发的线上事故,教训惨痛,本文 ...
- RPC的超时设置,一不小心就是线上事故
来自:IT人的职场进阶 上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨 ...
- 醉了,RPC 超时设置也能引起线上事故!
上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结 ...
- 同时设置超时时间_刚入职的小菜鸡,设错了RPC超时,搞了个线上事故
上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结 ...
- 程序员惊魂 12 小时:“���”引发线上事故
作者 | 饶全成 来源 | 码农桃花源(ID:CoderPark) 最近遇到了一起依赖升级 + 异常数据引发的线上事故,教训惨痛,本文对此进行回故和总结. 背景 起因是我们使用的服务框架版本比较老,G ...
- RPC 的超时设置,一不小心就是线上事故!
作者 | 骆俊武 来源 | IT人的职场进阶(ID:BestITer) 上面这张监控图,对于服务端的研发同学来说再熟悉不过了.在日常的系统维护中,『服务超时』应该属于监控报警最多的一类问题. 尤其在微 ...
- 线上事故的善后——事故通告
在我们的日常工作中,出现线上事故是难免的,而作为项目最后一环的测试,往往首当其冲:"测试怎么没测出来?"是人们首先想到的.于是出于这种先入为主的想法,测试往往会承担过量的责任.而作 ...
- 【Linux服务器开发系列】一场redis线上事故引发的思考丨redis持久化 rdb和aof丨redis主从复制
一场redis线上事故引发的思考 1. 事故背景介绍 2. redis持久化 rdb和aof 3. redis主从复制 4. 解决方案详解 [Linux服务器开发系列]一场redis线上事故引发的思考 ...
- 线上事故应该由谁来承担?
前不久线上发生了一个事故,主线是这样的,XX 平台对接了 web 端和手机终端,一个伸手不见五指的夜晚,web 端出现了问题,SRE 发现故障后迅速发起了 oncall 机制,建立了作战室.一个小时后 ...
最新文章
- 【iOS官方文档翻译】UICollectionView与UICollectionViewFlowLayout
- “请给我一个五彩斑斓的黑”,只需一行命令就能让AI画画,OpenAI的Dall-E被大神复现...
- quartz集群调度机制调研及源码分析---转载
- 32位微处理器的虚拟技术,是“坑爹”么!
- docker rabbitmq_Docker部署RabbitMQ集群
- SqlServer 对 数据类型 text 的操作
- 什么是clearfix?
- plc通信程序 c语言,三菱PLC编程口通信C语言源代码(3)
- 【 js 基础 】Javascript “继承”
- Splay模板 1.0
- html5 颜色对应8进制,十进制字体颜色html代码参照表 rgb值颜色查询对照表
- 详解 欧拉角与四元数
- Arcgis10.8中将三维的高程点转换为二维的高程点
- 一篇全面的CSS布局学习指南 [译]
- Python 圆的周长和面积计算
- 超级鹰解决点触验证码
- Excel 2010 VBA 入门 066 读取其他工作簿的数据
- 小米Note4、小米8、一加6刷机(三方rec+rom+root)
- C++ 11 后一些便捷用法
- ognl表达式系列1--OgnlContext
热门文章
- 在vSphere 6.x vSAN数据存储上使用Oracle RAC(2121181)
- 批处理中的使用问题记录
- 架构设计:文件服务的设计与实现
- Docker学习总结(51)——为什么不建议把数据库部署在 Docker 容器内的7大原因?
- Java基础学习总结(92)——Java编码规范之排版、注释及命名
- Java基础学习总结(30)——Java 内存溢出问题总结
- Myeclipse学习总结(4)——Eclipse常用开发插件
- Windows学习总结(5)——【IIS建站】Windows10怎么打开站点服务?
- Jquery学习总结(1)——Jquery常用代码片段汇总
- 2.Hadoop HDFS 安装配置