别不信,你可能连 MySQL 的 Delete 都不会!

第一时间获取技术干货和业界资讯!

别不信,你可能连 MySQL 的 Delete 都不会!

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

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

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

别不信,你可能连 MySQL 的 Delete 都不会!

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

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

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

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

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

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

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

别不信,你可能连 MySQL 的 Delete 都不会!
面试的时候出这个题:“假设现在有一张表,需要删除前 1 万条数据?”,你别一下子就把方案1直接拿出来。这样你就死定了,去年我们就有这样的面试题,不少人掉坑里!
其实编程最重要的是思考和思想,而不是写代码!你是否认同?请留言。最后打个小广告,想买极客时间学习课程的请加我微信号:xttblog,所有课程都有返现!

猜你喜欢

转载自blog.51cto.com/15127565/2666110