原因是老板要跟人談合作，不想讓合作方進后臺看到訂單量，恰好這部分訂單也是沒有用處了還可以釋放空間，豈不美哉？
需要說明因為業務關系，也有其他平臺對接到我們平臺進行同步訂單，
操作中遇到了兩個難點：
第一種方式：
直接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表，
只能等到第二波流量穩定的時候再重新操作了，
總結：這是我資料庫基礎不扎實導致的錯誤.
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/282164.html
標籤：其他
上一篇：mysql匯入mdf檔案