阿里面试：为什么MySQL不建议使用delete删除数据？

运维dog（卑微状）：开发大佬们，能不能别在代码里直接delete数据库……

开发（高赞状）：我很好奇他们建议使用的什么？drop database？

运维dog（惶恐状）：不不不，那个更可怕好伐……

开发（站起来，离开键盘）：那？u can u up？（潜台词no can no bb）

运维dog（敲了几下键盘）：用update就好了嘛，加个字段做标记，无用数据标记为0……

===================

作为运维dog不好下场评论，以下剧情依据评论区数据整理（虽然有可能表达我的真实想法）……

开发（乜斜眼睛）：不删数据 到时候运行几年表巨大 占空间又在那边BBBBBB

运维dog（鼠标右键）：delete 空间也不释放，水位没下降啊……

另一个开发（敲了敲桌子）：先别管空间了，我代码咋写？主键约束怎么办，删了不能立即插入啊！而且每个查询语句里，都要加个条件delete=0，关键这个字段区分度只有万分之一，加索引白白浪费空间不说，还降低写入效率。

运维dog（犹豫状）：有个东西似乎叫“联合主键”？我记得不是很清楚，不写代码好多年了……

一个被合规耽误的开发：GDPR要求必须在若干天以内删数据怎么办？包括备份数据里也必须删掉。不然的话，用户注销账户，以为delete了，其实update，然后就可以卖信息了？

运维dog（推了推眼镜）：我记得你，你就是昨天让我调一个用户的记录，我调不出来你投诉我的那个，那个用户的数据就被delete了啊，我tmd白被投诉……

被合规耽误的开发（咳咳）：昨天我属实是有点冲动，为了减少办公室恶性事件的发生，我想到个法子，兼顾运维dog要的可溯源而且不至于无法挽回，也兼顾了开发dog对数据库性能的顾虑……等等，你们什么表情？

众人（内心OS：都去做合规了还记得代码？）：请开始您的表演……

被合规耽误的开发：建个his表吧，或者叫backup表也行，即时操作还是update，不要一下子delete了无法挽回，超过一段时间就把数据挪到his表里，冷备起，这样你可以溯源，你不用担心实时表变成巨无霸，你……主键改成联合主键是个好习惯，认了吧！

俩开发（嘲讽状）：合着你不做开发了，就不用管历史查询的时候我要跨表了是吧……

=========1115分割线==========

似乎新增了不少评论，虽然不能继续推进剧情发展，但有人看我就可以编，可劲编，继续编……

转岗HR的开发（端着咖啡路过）：在讨论啥呢，这么热闹……哦，dml数据库啊，这个问题简单，你们都没有仔细读题，题主问的是“阿里面试：为什么MySQL不建议使用delete删除数据？”

俩开发（哼）：你要再出一个合规开发那样跨表的馊主意么？

转岗HR的开发（把咖啡放下，拿起鼠标点了点）：看清楚，我划重点了啊，这是阿里面试问的，面试官希望听到的回答当然是，因为普通MySQL没有阿里云数据库那样随时回档到某个历史时刻的功能啊！俩瓜娃子，只会敲代码，怪不得年年绩效C，不涨工资！

运维dog（若有所思）：是，云数据库可以随时回档，满足溯源，可以随便delete……（把键盘一扔）卧槽，你做了HR整天琢磨这个，合着是在防止我删库跑路是吧？！

转岗HR的开发（讪讪）：哪能呢，最近双十一支付宝刚崩了，运维现在是大爷，轻易不敢惹的。

开发（左边眉毛一挑）：听你在这里胡扯，IT预算够的话，还买什么阿里云MySQL数据库，直接一步到位上阿里云分布式数据库啊！直接连读写分离、分库分表都做好了，要我这样的开发何用，开发才是可以轻易惹的是吧？

另一个开发（右边眉毛一挑）：就是就是，这不是搞了降本增效，你堂堂一个前端开发，为何转岗做了HR，刚才那个堂堂后端开发，为何转岗做了合规？（内心OS：羡慕合规确实门槛很低，这也不行，那也不行，只需说No，绩效就A了……）

转岗HR的开发（正喝着咖啡，咳咳）：咳咳，你们俩，差不多得了，别在这凡尔赛，你还以为合规只要说no就行了，那哥们最近在恶补欧萌和美帝制裁天朝的目录，头都抓秃了……等等，你们什么眼光，以为我这个HR就好做了？TMD这年头都是逼乎等自媒体害的，谈离职补偿一个比一个精，劳动法条款倒背如流，开局一支笔，录音三小时……歪楼了，你们继续聊，我走了……了……

=========1206分割线==========

架构师和转岗测试的开发路过时加入群聊，转岗HR的开发退出群聊的同时分享了全部聊天记录。

转岗测试的开发：这个我熟呀，毕竟我前脚做的DBA开发，后脚刚做的测试。你看看你们自己的聊天记录，一、都已经知道了delete不能真正释放表空间，会造成磁盘空间浪费，（右手把左手手指一根根压下去，屈指可数状）；二、磁盘数据碎片化、性能下降；三、索引稀疏、事务日志膨胀；四、运维dog最关心的数据恢复困难；五、delete锁表啊，我测试的时候稍微多开几个线程，轻松就中奖delete锁表，真TMD深恶痛绝！

开发（撸起袖子）：咋，不服先打一架？我怀疑你在说我，虽然我没有证据。

架构师（招手让慢腾腾没走远的HR回来）：你们打一架，正好超额完成HR的降本增笑KPI？问题我们都基本上看到了，分布式数据库是没预算的，在普通MySQL上怎么解决？解决不好，让HR笑一笑？

转岗HR的开发（满脸堆笑）：架构师大神说笑了，财源什么的，没有没有的事……

运维dog：合规 dog……啊不不不，合规大佬前面说的归档his表方案，虽然确实存在历史查询跨表的坑爹问题，但在这个问题中，确实算是一个很好的解决思路。

架构师：说来听听。

运维dog：一条记录从我们的系统中产生并入库，我们可以引入一个“数据生命周期”的概念来进行管理。首先进入实时表，方便程序做高频访问和修改，异步写入全量表，当然异步时延在不牺牲写入速度的前提下；当删除请求出现的时候，实时表可以直接delete，异步写入删除表。

转岗测试的开发：运维dog此言大善！以我做DBA的经验看，只要删除表和全量表使用同样的索引字段，查询效率受到的影响不大。对于这三个表来说，实时表只存近期数据，本来数量就不大，而全量表和删除表都是新增记录，不存在索引稀疏和磁盘碎片的问题，事务日志也没有膨胀……

开发（点点头）：实时表可以随意delete了，就是有点费磁盘，而且每个写请求进来都是写两次……

架构师（叹口气）：唯二的好处是，确实可以追溯历史记录，而且全量表查询不用跨表了。

运维dog：写数据库不能既要又要啊，我说的这个思路，本质上其实也就是开发自己的程序把分布式数据库的活做了而已，要不架构师大神申请多点IT预算，我们用HR说的方案，直接用分布式数据库，底层不也是这样实现的嘛……

转岗测试的开发：这大约就是合规的代价吧。

=========大约是完了，总不能有人想看腾讯云TDSQL的坑列表吧？==========

=========如果真有，让阿里云给我打点钱，我就列出来==========