當數(shù)據(jù)庫扼住系統(tǒng)性能咽喉，直接分庫分表能解決嗎？分庫分表是比較靠后的優(yōu)化手段，因為成本比較高。遇到數(shù)據(jù)庫瓶頸:- 首先考慮sql優(yōu)化，這是最簡單的方法。對現(xiàn)有系統(tǒng)基本沒有影響。- 其次就是考慮數(shù)據(jù)庫的

當數(shù)據(jù)庫扼住系統(tǒng)性能咽喉，直接分庫分表能解決嗎？

分庫分表是比較靠后的優(yōu)化手段，因為成本比較高。

遇到數(shù)據(jù)庫瓶頸:

- 首先考慮sql優(yōu)化，這是最簡單的方法。對現(xiàn)有系統(tǒng)基本沒有影響。

- 其次就是考慮數(shù)據(jù)庫的讀寫分離，這也是相對簡單的方法。在數(shù)據(jù)庫層面進行配置，系統(tǒng)層面只需要調(diào)整一下獲取數(shù)據(jù)庫連接的邏輯。讀數(shù)據(jù)時即可以獲取主庫連接，也可以獲取從庫連接。寫數(shù)據(jù)時只獲取主庫連接。

- 再考慮增加緩存層。將數(shù)據(jù)緩存到緩存中，當再次訪問時不再從數(shù)據(jù)庫獲取。一般緩存層對系統(tǒng)是透明的，基本對系統(tǒng)本身沒有影響。但是引入緩存，也引入了相應的需要考慮的問題，比如雪崩，命中率，分布式緩存等

- 還有一種非技術(shù)手段，就是改需求。引起性能問題的原因是否是需求不合理？或者需求太復雜？是否可以簡化需求？此方法對系統(tǒng)的影響也相對較小。

- 最后才考慮分庫分表。優(yōu)先分庫，因為相對分表更簡單。將對應的表移動到新庫，調(diào)整系統(tǒng)獲取數(shù)據(jù)庫連接的邏輯。這里需要考慮要移動哪些表，在提高性能的前提下，首先盡量避免分布式事務。

- 最最后，考慮分表。分表的主要原因是單表數(shù)據(jù)量太大。分表又分縱切和橫切?？v切就是按列切，比如用戶表，常用信息為基本信息表，其它信息為詳情表。橫切就是按行切，比如一億數(shù)據(jù)量的表切分為十張一千萬的表。這里就涉及數(shù)據(jù)該存放到哪張表，或從哪張表里取。分表后又可以分庫，來進一步優(yōu)化。

- 如果涉及到分布式事務，又要考慮如何保證分布式事務。理論方面2pc，3pc，paxos，cap，base。對應的中間件的使用。

對系統(tǒng)的設計和優(yōu)化不是人云亦云，需要根據(jù)實際的場景來進行處理。