记录实际删除生产环境中千万条订单数据的过程

原因是老板要跟人谈合作，不想让合作方进后台看到订单量，恰好这部分订单也是没有用处了还可以释放空间，岂不美哉？

 

需要说明因为业务关系，也有其他平台对接到我们平台进行同步订单。

 

操作中遇到了两个难点：

第一种方式：

直接delete，因为订单表是用innodb引擎，删除delete实际会把操作写入进undoLog，以及因为有索引的关系，导致Mysqld服务端内存耗尽直接挂了。后面进来的请求都在等待连接，程序也因为无法连接到数据库而崩溃。恰好临近五一劳动节，并发量增大。

程序崩溃后第一时间领导，客服，以及第三方平台的技术都电话Call了过来（懵逼）。

迅速进到服务器直接执行/etc/init.d/mysql restart  ，经过焦灼的几分钟等待，发现一直都重启不了，还是宕机状态。

后面执行 ps aux | grep mysql 看到mysqld 的守护进程还在运行。然后执行 kill -9 [进程Id]。再次执行/etc/init.d/mysql restart 。程序恢复运行。

这个过程导致丢失了部分第三方同步过来的订单数据请求。只能自己同步回去了（尴尬）

 

第二种方式：

1。克隆order表结构生成一个order_new表。
2.然后把之前的order表rename成order_old表（这样别人的订单数据不会插入进来到旧表，相当于停止了）。
3.然后把仅需要的十几万条数据插入到order_new表，
4.然后再把order_new表rename成order表假装无事发生

这样看起来订单表是只保留下来只需要的十几万条数据了，然后就翻车了！！！

order_history表的外键关联到之前order表，在我把order表rename成order_old表以后，外键也跟着变成了order_old，而不是保留之前的order。

然后导致我程序后面创建订单时候因为外键约束原因创建失败，我们平台订票失败，其他平台对接我们的，也同样创建订单失败。

发现问题后因为要保证服务运行，只能硬着头皮迅速直接把order表切回旧表。

导致这个操作过程中的新增的几个订单出问题了，保存到order_new表里。需要同步保存回order_old表里，人家真实付了钱的订单哪敢弄丢呢？（也是只好自己写程序同步回去了尴尬）

过程应该要先把有关order_old表的外键都先去除，然后重建创建order_new外键约束。这样外键就不回关联到order_old表而是order_new表了。

最后再把order_new表rename成order表。

只能等到第二波流量稳定的时候再重新操作了。

 

总结：这是我数据库基础不扎实导致的错误.