在傳統的編碼的過程中，往往是在資料庫由於抗不住伺服器的壓力，或者是IO達到瓶頸之後，必須用到分庫的時候，才採用讀寫分離的方案，個人認為讀寫分離的作用遠不止此。今天，根據博主我作為程式猿的經驗，來和大家分享一下資料庫讀寫分離帶來的優點。
一，讀寫分離帶來的擴充套件性更強
在我們編碼的過程中，隨著專案的業務增多，必然會致使業務介面越來越多，介面越多，帶來的維護成本就相對較高，如果沒有對應文件的記錄，即使作為研發人員的我們，都很大可能忘記那些介面有那些功能，那些介面被呼叫過多少次。
以上就很可能帶來一個很嚴重的問題，舉例說明：在學校考試成績管理系統中，我寫了100個select介面，10個insert介面，10個update介面，10個delete介面，分別對應不同業務需求，這些介面被呼叫的次數無限，隨著伺服器的壓力增加，需要對部分查詢介面（查詢最新的成績等）進行最佳化，最開始的常見的查詢方式可能是按照直接在資料庫中查詢時間最新的成績記錄，進行返回，最佳化的方案為給最新的成績記錄打一個標記。可是，後續的插入，修改，刪除介面，都需要更新標記，如此多的介面，在沒有文件的情況下，維護起來基本不可能，此時要怎麼辦呢？
二，讀寫分離方便管理
按照資料庫的常用介面，由於功能的特定性，增，刪，改可以歸為一類，查可以單獨歸為一類，採用讀寫分離的資料庫設計，在業務呼叫起來更加規範，相對於增刪查改一起，粒度較小，更容易管理。
而且寫介面容易對資料造成影響，寫文件的時候可能需要重點記錄，讀取介面由於不會影響資料，相對好管理一點，博主一向的原則是重點記錄寫介面，能複用的不增加介面。
在傳統的編碼的過程中，往往是在資料庫由於抗不住伺服器的壓力，或者是IO達到瓶頸之後，必須用到分庫的時候，才採用讀寫分離的方案，個人認為讀寫分離的作用遠不止此。今天，根據博主我作為程式猿的經驗，來和大家分享一下資料庫讀寫分離帶來的優點。
一，讀寫分離帶來的擴充套件性更強
在我們編碼的過程中，隨著專案的業務增多，必然會致使業務介面越來越多，介面越多，帶來的維護成本就相對較高，如果沒有對應文件的記錄，即使作為研發人員的我們，都很大可能忘記那些介面有那些功能，那些介面被呼叫過多少次。
以上就很可能帶來一個很嚴重的問題，舉例說明：在學校考試成績管理系統中，我寫了100個select介面，10個insert介面，10個update介面，10個delete介面，分別對應不同業務需求，這些介面被呼叫的次數無限，隨著伺服器的壓力增加，需要對部分查詢介面（查詢最新的成績等）進行最佳化，最開始的常見的查詢方式可能是按照直接在資料庫中查詢時間最新的成績記錄，進行返回，最佳化的方案為給最新的成績記錄打一個標記。可是，後續的插入，修改，刪除介面，都需要更新標記，如此多的介面，在沒有文件的情況下，維護起來基本不可能，此時要怎麼辦呢？
二，讀寫分離方便管理
按照資料庫的常用介面，由於功能的特定性，增，刪，改可以歸為一類，查可以單獨歸為一類，採用讀寫分離的資料庫設計，在業務呼叫起來更加規範，相對於增刪查改一起，粒度較小，更容易管理。
而且寫介面容易對資料造成影響，寫文件的時候可能需要重點記錄，讀取介面由於不會影響資料，相對好管理一點，博主一向的原則是重點記錄寫介面，能複用的不增加介面。