_記憶中窺見
分庫分表是比較靠後的優化手段，因為成本比較高。
遇到數據庫瓶頸:
- 首先考慮sql優化，這是最簡單的方法。對現有系統基本沒有影響。
- 其次就是考慮數據庫的讀寫分離，這也是相對簡單的方法。在數據庫層面進行配置，系統層面只需要調整一下獲取數據庫連接的邏輯。讀數據時即可以獲取主庫連接，也可以獲取從庫連接。寫數據時只獲取主庫連接。
- 再考慮增加緩存層。將數據緩存到緩存中，當再次訪問時不再從數據庫獲取。一般緩存層對系統是透明的，基本對系統本身沒有影響。但是引入緩存，也引入了相應的需要考慮的問題，比如雪崩，命中率，分佈式緩存等
- 還有一種非技術手段，就是改需求。引起性能問題的原因是否是需求不合理？或者需求太複雜？是否可以簡化需求？此方法對系統的影響也相對較小。
- 最後才考慮分庫分表。優先分庫，因為相對分表更簡單。將對應的表移動到新庫，調整系統獲取數據庫連接的邏輯。這裡需要考慮要移動哪些表，在提高性能的前提下，首先儘量避免分佈式事務。
- 最最後，考慮分表。分表的主要原因是單表數據量太大。分表又分縱切和橫切。縱切就是按列切，比如用戶表，常用信息為基本信息表，其它信息為詳情表。橫切就是按行切，比如一億數據量的表切分為十張一千萬的表。這裡就涉及數據該存放到哪張表，或從哪張表裡取。分表後又可以分庫，來進一步優化。
- 如果涉及到分佈式事務，又要考慮如何保證分佈式事務。理論方面2pc，3pc，paxos，cap，base。對應的中間件的使用。
對系統的設計和優化不是人云亦云，需要根據實際的場景來進行處理。
架構思維
1.優化SQL加索引
2.業務是否可以垂直拆分，業務拆分了可以分庫
3.業務單邊數據量還是大，是否可以把一些字段獨立出去，表垂直拆分。水平拆分表可以按時間，或者id的has值進行拆分
4.分庫分表必然帶來很多問題，比如關聯查詢，聚合等操作，可以嘗試下NewSQL，業務不再關心分庫分表操作了。國內開源實現有TiDB，可以瞭解下，NewSQL應該是未來的趨勢。
可以關注我，後面分享一些存儲方面的文章。
淺析架構
只是其中一個手段，還有讀寫分離，表路由，集群，TOP SQL優化
迦境兒童犛牛奶
阿里就是這麼幹的
