我們不斷的拆分schema，說了為了下一步的分庫做準備，但是由此帶來的代價也是顯而易見的，我們的分散式事務在不斷的增多。我們期望利用分散式事務來保證資料的一致性，但是其帶來的影響也是不容忽視的。
摘錄他人語
分散式事務提供的ACID保證是以損害系統的可用性、效能與可伸縮性為代價的。只有在參與分散式事務的各個資料庫例項都能夠正常工作的前提下，分散式事務才能夠順利完成，只要有一個工作不正常，整個事務就不能完成。這樣，系統的可用性就相當於參加分散式事務的各例項的可用性之積，例項越多，可用性下降越明顯。從效能和可伸縮性角度看，首先是事務的總持續時間通常是各例項操作時間之和，因為一個事務中的各個操作通常是順序執行的，這樣事務的響應時間就會增加很多；其次是一般Web應用的事務都不大，單機操作時間也就幾毫秒甚至不到1毫秒，一但涉及到分散式事務，提交時節點間的網路通訊往返過程也為毫秒級別，對事務響應時間的影響也不可忽視。由於事務持續時間延長，事務對相關資源的鎖定時間也相應增加，從而可能嚴重增加了併發衝突，影響到系統吞吐率和可伸縮性。
如此這般，我們當初分庫的目的是為了緩解主庫的壓力，解決熱點資源鎖的問題，以期這些問題解決後，能夠提高系統的吞吐率。但是當我們schema分離，大量使用分散式事務的時候，新的問題來了，事務時間增長，系統的響應可能仍然無法提高，還有一個就是每個事務節點都可能成為瓶頸，畢竟是一根繩子上的蚱蜢，一個有問題，大家一樣的都是死翹翹。我們的目的沒有達到，反而是增加了DBA的工作量。
如果大家一定要使用分散式事務，請仔細想想如下問題
1. 這步操作一定得在事務當中嗎？這步操作如果沒完成或者失敗了，值得回滾整個事務嗎？難道沒有優雅的補償措施或者容錯措施？
2. 分散式事務涉及到的點，必須的這麼多？必須得實時的操作這一大串？不能通過通知類操作去精簡掉某些點？
3. 在發起分散式事務之後，你是不是做了事務無關的操作，儘管這些操作跟事務無關？（如，讀取資料、計算、等使用者返回訊息、等其他模組的呼叫返回等等）要知道事務應該儘快結束。
4. 你沒有把一些讀操作也算在事務裡面了吧？這是很容易犯的錯誤，你在事務中Enlist了一個select 操作。
5. 你的操作，某些步驟可以等全部操作完成之後再執行.這類操作具有明顯的通知類特點。通知類操作是說，我給你一個通知，並且我保證通知到了你；你必須吃下這個通知，並且保證處理成功，但是你不必我一通知你你就處理。這樣的操作很明顯可以用另外一個任務去搞。
原則是，儘量縮短事務時間。