十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
本篇内容介绍了“MySQL中误用insert into select实例分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
磁县网站制作公司哪家好,找创新互联建站!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作,到程序开发,运营维护。创新互联建站从2013年开始到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联建站。
事情的起因
公司的交易量比较大,使用的数据库是 MySQL,每天的增量差不多在百万左右,公司并没有分库分表,所以想维持这个表的性能只能考虑做数据迁移。
同事李某接到了这个任务,于是他想出了这两个方案:
先通过程序查询出来,然后插入历史表,再删除原表。
使用 insert into select 让数据库 IO 来完成所有操作。
第一个方案使用的时候发现一次性全部加载,系统直接就 OOM 了,但是分批次做就过多 IO 和时间长,于是选用了第二种方案,测试的时候没有任何问题,开开心心上线,然后被开除。
先来看第一个方案,先看伪代码:
// 1、查询对应需要迁移的数据
List
再来看看第二个方案,到底发生了啥?
为了维持表的性能,同时保留有效数据,经过商量定了一个量,保留 10 天的数据,差不多要在表里面保留 1kw 的数据。
所以同事就做了一个时间筛选的操作,直接 insert into select ... dateTime < (Ten days ago)...
爽极了,直接就避免了要去分页查询数据,这样就不存在 OOM 啦。还简化了很多的代码操作,减少了网络问题。
为了测试,还特意建了 1kw 的数据来模拟,测试环境当然是没有问题啦,顺利通过。
考虑到这个表是一个支付流水表,于是将这个任务做成定时任务,并且定在晚上 8 点执行。
晚上量也不是很大,自然是没有什么问题,但是第二天公司财务上班,开始对账,发现资金对不上,很多流水都没有入库。
最终排查发现晚上 8 点之后,陆陆续续开始出现支付流水插入失败的问题,很多数据因此丢失。
最终定位到了是迁移任务引起的问题,刚开始还不明所以,白天没有问题,然后想到晚上出现这样的情况可能是晚上的任务出现了影响,最后停掉该任务的第二次上线,发现没有了这样的情况。
复盘
问题在哪里?为什么停掉迁移的任务之后就好了呢?这个 insert into select 操作到底做了什么?
我们来看看这个语句的 explain:
如果全表扫描,我们这个表这么大,是不是意味着迁移的时间会很长?假若我们这个迁移时间为一个小时,那是不是意味着就解释了我们白天没有出现这样问题的原因了。但是全表扫描是最根本的原因吗?
我们不妨试试,一边迁移,一边做些的操作,还原现场。最终还是会出现这样的问题。
得出结论:全表扫描导致了这次事故的发生。这样做就解决了发生的问题,但是做为陆陆续续开始失败这个就不好解释了。
原因
在默认的事务隔离级别下:insert into a select b 的操作 a 表示直接锁表,b 表是逐条加锁。这也就解释了为什么出现陆续的失败的原因。
在逐条加锁的时候,流水表由于多数是复合记录,所以最终部分在扫描的时候被锁定,部分拿不到锁,最终导致超时或者直接失败,还有一些在这加锁的过成功成功了。
为什么测试没有问题?
在测试的时候充分的使用了正式环境的数据来测试,但是别忽视一个问题,那就是测试环境毕竟是测试环境,在测试的时候,数据量真实并不代表就是真实的业务场景。
比方说,这个情况里面就少了一个迁移的时候,大量数据的插入这样的情况。最终导致线上 Bug。
解决办法
既然我们避免全表扫描就可以解决,我们避免它就行了。想要避免全表扫描,对 where 后面的条件做索引,让我们的 select 查询都走索引即可。
insert into 还能用吗?回答是:当然可以。
“mysql中误用insert into select实例分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!