這是學習筆記的第 1935 篇文章

我們在工作中很容易陷入一個漩渦，那就是因為并發事務選擇了關系型數據庫，因為關系型選擇了MySQL,因為MySQL的業務特點而選擇了對事務降維。

這在大多數場景下算是一件好事，說明我們對于事務的理解算是理性的，除此之外，我認為我們傳統理解上的業務類型就不是非常合理，很多需求如果是基于OLTP和OLAP其實業務場景是很受限的，比如一個論壇業務，你說對事務的要求高嗎， 對于一些日志型，監控型數據的寫入，使用事務也不大有用，而同時它們也不屬于OLAP的業務場景。

簡而言之，不是所有的業務場景需要事務支持，需要根據場景進行方案選擇。

我總結了下面的一些降維策略，供參考。

降維策略1：存儲過程調用轉換為透明的SQL調用

對于新業務而言，使用存儲過程顯然不是一個好主意，MySQL的存儲過程和其他商業數據庫相比，功能和性能都有待驗證，而且在現在輕量化的業務處理中，存儲過程的處理方式太“重”了。

有些應用架構看起來是按照分布式部署的，在數據庫層的調用方式是基于存儲過程，因為存儲過程的調用中內部來保證事務，看起來設計很清晰，但是這樣壓力都在數據庫層面了，以至于數據庫層很容易成為瓶頸，而且難以實現真正的分布式。

所以有一個明確的改進方向就是對于存儲過程的改造，把它改造為SQL調用的方式，可以極大的提高業務的處理效率，在數據庫的接口調用上足夠簡單而且清晰可控。

降維策略2：Drop 操作轉換為可逆的DDL操作

Drop操作是默認提交的，而且是不可逆的，在數據庫操作中都是跑路的代名詞，MySQL層面目前是沒有相應的drop操作恢復功能，除非通過備份來恢復，但是我們可以考慮將Drop操作轉換為一種可逆的DDL操作。

在MySQL中默認是每個表有一個對應的ibd文件，其實可以把drop操作轉換為一個rename操作，即可把文件從testdb遷移到testdb_arch下面，從權限上來說，testdb_arch是業務不可見的，rename操作可以平滑的實現這個刪除功能，如果在一定時間后確認可以清理，則數據清理對于已有的業務流程是不可見的。

降維策略3：Truncate操作轉換為安全的DDL操作

Truncate操作的危害比Drop還要大，我們在第2種策略的基礎上可以把truncate操作轉換為一種較為安全的操作，思路也是通過rename的方式來實現，唯一的差別是這種方式需要額外處理表結構信息。

降維策略4：DDL操作轉換為DML操作

有些業務經常會有一種緊急需求，總是需要給一個表添加字段，搞得DBA和業務同學都挺累，可以想象一個表有上百個字段，而且基本都是name1,name2....name100,這種設計本身就是有問題的，更不用考慮性能了。 究其原因，是因為業務的需求動態變化，比如一個游戲裝備有20個屬性，可能過了一個月之后就增加到了40個屬性，這樣一來，所有的裝備都有40個屬性，不管用沒用到，而且這種方式也存在諸多的冗余。

我們在設計規范里面也提到了一些設計的基本要素，在這些基礎上需要補充的是，在保持有限的字段，如果要實現這些功能的擴展，其實完全可以通過配置化的方式來實現，比如把一些動態添加的字段轉換為一些配置信息。配置信息可以通過DML的方式進行修改和補充，對于數據入口也可以更加動態易擴展。

降維策略5：Delete操作轉換為高效操作

有些業務需要定期來清理一些周期性數據，比如表里的數據只保留一個月，那么超出時間范圍的數據就要清理掉了，而如果表的量級比較大的情況下，這種delete操作的代價實在太高，我們可以有兩類解決方案來把Delete操作轉換為更為高效的方式。

第一種是根據業務建立周期表，比如按照月表，周表，日表等維度來設計，這樣數據的清理就是一個相對可控而且高效的方式了。

第二種方案是使用策略2的思路，比如一張2千萬的大表要清理99%的數據，那么保留的1%的數據我們可以很快根據條件過濾補錄，我們完全可以實現“移形換位”的方式。

降維策略6：Update操作轉換為Insert操作

有些業務中會有一種固定的數據模型，比如先根據id查看記錄是否存在，如果不存在則進行insert操作，如果存在則進行update操作，如果不加事務，在高并發的情況下很可能會因為重復的insert操作導致主鍵沖突的錯誤，我們可以使用insert on duplicate的方式來平滑的過渡，如果記錄存在則進行update操作，但是語句接口都是insert，這樣就可以把insert,update的操作模型統一為insert模型。

總結

以上是生活随笔為你收集整理的存储过程里面的语句实在同一个事务中吗_事务降维的几种策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。