https://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597585&idx=1&sn=8479e3d3fc276c639ace540fceb7319e&scene=0#rd

MySQL讀寫分離的最大問題是主從資料同步延遲

MySQL主從延遲一個重要的原因之一是主從複製是單執行緒序列執行。 避免或解決mysql主從延遲:
優化MySQL引數，比如增大innodb_buffer_pool_size，讓更多操作在MySQL記憶體中完成，減少磁碟操作。


使用高效能CPU主機。


資料庫使用物理主機，避免使用虛擬雲主機，提升IO效能。


使用SSD磁碟，提升IO效能。SSD的隨機IO效能約是SATA硬碟的10倍。




垂直分庫最大的挑戰是：不能跨庫join，同時需要對現有程式碼重構。單庫時，可以簡單的使用join關聯表查詢；拆庫後，拆分後的資料庫在不同的例項上，就不能跨庫使用join


SQL最佳實踐，其中一條便是程式中禁用或少用join，而應該在程式中組裝資料，讓SQL更簡單。一方面為以後進一步垂直拆分業務做準備，另一方面也避免了MySQL中join的效能較低的問題。


業務程式碼優化，將實時性要求高的某些操作，使用主庫做讀操作。




Mysql單表資料量越來越大。如訂單表，單表記錄數很快將過億，超出MySQL的極限，影響讀寫效能。




水平分庫面臨的第一個問題是，按什麼邏輯進行拆分。一種方案是按城市拆分，一個城市的所有資料在一個數據庫中；另一種方案是按訂單ID平均拆分資料。按城市拆分的優點是資料聚合度比較高，做聚合查詢比較簡單，實現也相對簡單，缺點是資料分佈不均勻，某些城市的資料量極大，產生熱點，而這些熱點以後可能還要被迫再次拆分。

按訂單ID拆分則正相反，優點是資料分佈均勻，不會出現一個數據庫資料極大或極小的情況，缺點是資料太分散，不利於做聚合查詢。比如，按訂單ID拆分後，一個商家的訂單可能分佈在不同的資料庫中，查詢一個商家的所有訂單，可能需要查詢多個數據庫。針對這種情況，一種解決方案是將需要聚合查詢的資料做冗餘表，冗餘的表不做拆分，同時在業務開發過程中，減少聚合查詢。

ID生成器是整個水平分庫的核心，它決定了如何拆分資料，以及查詢儲存-檢索資料。ID需要跨庫全域性唯一，否則會引發業務層的衝突。此外，ID必須是數字且升序，這主要是考慮到升序的ID能保證MySQL的效能。同時，ID生成器必須非常穩定，因為任何故障都會影響所有的資料庫操作。

我們的ID的生成策略借鑑了Instagram的ID生成演算法。具體方案如下：

• 整個ID的二進位制長度為64位

• 前36位使用時間戳，以保證ID是升序增加

• 中間13位是分庫標識，用來標識當前這個ID對應的記錄在哪個資料庫中

• 後15位為自增序列，以保證在同一秒內併發時，ID不會重複。每個shard庫都有一個自增序列表，生成自增序列時，從自增序列表中獲取當前自增序列值，並加1，做為當前ID的後15位