对不起，你连 MySQL 的 Delete 都不会！

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

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

假设现在有一张表，需要删除前 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 来进行删除。

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

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

： » 对不起，你连 MySQL 的 Delete 都不会！