一、數據庫性能瓶頸-IO瓶頸
第一種：磁盤讀IO瓶頸，熱點數據太多，數據庫緩存放不下，每次查詢會產生大量的IO，降低查詢速度
第二種：網絡IO瓶頸，請求的數據太多，網絡帶寬不夠
二、數據庫性能瓶頸-CPU瓶頸
第一種：SQl問題：如SQL中包含join,group by, order by，非索引字段條件查詢等，增加CPU運算的操作->SQL優化，建立合適的索引，在業務Service層進行業務計算（不建議在數據庫中對數據進行操作）。
第二種：單表數據量太大，查詢時掃描的行太多，SQl效率低，增加CPU運算的操作。
選擇性處理，沒有一勞永逸的方案。需要結合業務的訴求來支持。某一個業務支持的查詢快，側重於去做查詢額。某一塊業務要求增刪改要快，側重於做增傷改的提高性能。
增刪改查四項；
兩大項： 讀取【查詢】和寫入【增刪改】。
三、數據庫操作二八原則
數據庫二八原則：80%的數據庫操作是查詢，20%的數據庫操作是增刪改；
結合業務，有限解決查詢的問題，讓跟多的服務器來承擔查詢功能。
讀寫分離：把數據庫的寫入【增刪改】，讀取【查詢】分開處理。查詢操作佔大部分。獨立出來讓更多
的服務器參與查詢。
1、主從庫之間，參與做主從複製的數據表的結構必然一致
2、主從庫，保存的數據量也算是一致
3、通過數據庫的【日誌】、【快照】來恢復
4、必然不是通過Sql語句~
5、數據同步—必然有延遲~~【有解決方案~】
四、讀寫分離的四種方式
1、快照發布：發佈服務器按預定的時間間隔向訂閱服務器發送已發佈數據的快照。
2、事務發佈【比較常見的，實時性會好些，也會延遲】：在訂閱服務器收到已發佈數據的初始快照後，發佈服務器將事務流式傳輸到訂閱服務器。
3、對等發佈：對等發佈支持多主複製。發佈服務器將事務流式傳輸到拓撲中的所有對等方。所有對等節點可以讀取和寫入更改，且所有更改將傳播到拓撲中的所有節點。
4、合併發佈：在訂閱服務器收到已發佈數據的初始快照後，發佈服務器和訂閱服務器可以獨立更新已發佈數據。更改會定期合併。Microsoft SQL Server Compact Edition 只能訂閱合併發佈
五、配置實操和注意事項
1、參與發佈訂閱的數據庫表必須包含主鍵
2、只能在局域網內做發佈訂閱
3、如果使用SqlServer代理，則必須設置代理爲自動啓動
4、發佈快照的文件夾必須要共享、權限放開
快照發布配置
事務發佈配置
對等發佈配置
要求：
1、數據表必須有主鍵--有住建才能參與數據同步
2、需要開啓Sql Server Browser 和 Sql Server 代理
