对不起,你连 MySQL 的 Delete 都不会!

SQL herman 249浏览
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog,发送下载链接帮助你免费下载!
本博客日IP超过1800,PV 2600 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog,之前的微信号好友位已满,备注:返现
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领

这个话题有点夸张,但其实也是非常现实的问题。你会增删改查,是不是就会了 MySQL 一个道理。

今天我要说的这个问题是,你会了 MySQL 的 Delete 语法,会写 delete 语句是不是就一定会删数据了?我们先来看一个例子。

你真的会 MySQL 吗?

假设现在有一张表,需要删除前 1 万条数据。有下面三种SQL语句,你会选择哪一个?为什么?

delete from xttblog limit 10000; -- 方案1
delete from xttblog limit 500; -- 方案2,一个会话循环执行 20 次
delete from xttblog limit 500; -- 方案3,连接池开20个连接同时执行

估计很多人会选择方案1吧。因为,一条 SQL 语句能搞定的事,何必拆开呢?而且平时就是这样用的。

问题是方案1你在本地,测试环境用并没什么毛病。但是如果在生产环境用,你想想看,这是不是一个长事务,大事务。会不会阻塞其他的操作?会不会导致系统崩溃?

虽然看起来 SQL 语句没写错。简单、有效、粗暴,但是,事务相对较长,则占用锁的时间较长,会导致其他客户端等待资源时间较长。严重一些的说,这个操作可能会导致其他很多操作超时,继而扩大危害。我们电商系统就发生过一次类似的事情,客服电话瞬间挤爆!

再说方案2,每次删除 500 条数据,看起来实现的比较复杂,但是安全,可靠。串行化执行,将相对长的事务分成多次相对短的事务,则每次事务占用锁的时间相对较短,其他客户端在等待相应资源的时间也较短。这样的操作,同时也意味着将资源分片使用(每次执行使用不同片段的资源),可以提高并发性。

方案3,开一堆线程。人为自己制造锁竞争,加剧并发量。多个事务会对同一行产生锁竞争,消耗cpu资源。CPU 可能会在瞬间飙高。

所以说,不要固执的认为 delete 语句很简单。上面三种方案至于选哪一种方案要结合实际场景,综合考虑各个因素吧,比如表的大小,并发量,业务对此表的依赖程度等。

另外,上面 3 个 delete 语句,我们平时都不常见。而且平时也不应该这样写,删除数据,要先把 id 找出来,再根据 id 来进行删除。

delete 我都不会了

面试的时候出这个题:“假设现在有一张表,需要删除前 1 万条数据?”,你别一下子就把方案1直接拿出来。这样你就死定了,去年我们就有这样的面试题,不少人掉坑里!

其实编程最重要的是思考和思想,而不是写代码!你是否认同?请留言。最后打个小广告,想买极客时间学习课程的请加我微信号:xttblog,所有课程都有返现!

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加QQ1群:135430763(2000人群已满),QQ2群:454796847(已满),QQ3群:187424846(已满)。QQ群进群密码:xttblog,想加微信群的朋友,之前的微信号好友已满,请加博主新的微信号:xttblog,备注:“xttblog”,添加博主微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通!

本文原文出处:业余草: » 对不起,你连 MySQL 的 Delete 都不会!