近期在一個群里，談到關于分布式數據庫在數據庫架構設計上遇到的問題，有很多的吐槽。其核心還是在于分布式數據庫與集中式數據庫的差異所致，不能完全照搬原有的設計。當用戶面對一個新架構的數據庫產品時，是需要考慮很多因素的。本文就是基于之前的實踐，羅列出結構設計中，在分布式數據庫中需要注意的常見問題，并在后面針對這些對主流的分布式數據庫對應能力加以盤點。

1. 開發中遇到的那些坑

1)序列/自增

數據庫序列（Sequence）的核心工作是生成一組唯一的、遞增的數字（或字符），通常用于為數據庫表的主鍵或唯一標識符提供可靠的、自動生成的數值。它在許多數據庫管理系統（如 PostgreSQL、Oracle、DB2）中是一個獨立于表的標準對象，有些數據庫則采用自增列的方式來實現（如MySQL、SQL Server)。序列的主要工作職責：一是提供唯一性保證，這是序列最核心的任務，其通過內部機制（通常是一個計數器），保證每次調用返回的值在當前序列的上下文中是唯一的；二是順序性生成，序列生成的數字默認是連續遞增（或遞減）的，盡管在分布式或高并發場景下可能會出現間隔，但總體上保證數值是單調遞增的；三是高效分配機制，序列提供了一種機制來快速分配唯一值，避免了在應用層生成主鍵的鎖競爭和協調復雜性；四是獨立于事務，序列值的生成通常不依賴于具體的事務提交與否。一旦被調用并獲得一個值，即使該事務隨后回滾，這個值通常也不會被回滾或重用，這確保了值的唯一性不會因事務失敗而受到影響（但也意味著序列值可能有“空洞”）。

在分布式數據庫中使用序列的核心挑戰在于：如何在保證全局唯一性的前提下，解決單點故障、性能瓶頸、順序性與“空洞”、復雜性等問題。例如，如果數據庫采用單個序列生成器，則很容易成為性能瓶頸和單點故障。通常在分布式數據庫中避免采用單一中心點，可采用上述分布式策略（內置分布式序列、分段分配、Snowflake、UUID）或使用高可用的中央協調服務集群（如 etcd），確保序列生成機制本身具有容錯能力。在性能方面則推薦采用預取緩存或其他分布式方案，后者如分段分配、Snowflake、UUID等方式本質上具有更高的擴展性和并發性能。在具體使用上則優先選擇并使用好分布式數據庫內置的主鍵或序列生成機制。如果內置機制不滿足需求或需要自研，則應仔細權衡分段分配、Snowflake類算法、UUID等方案的優缺點（唯一性、有序性、長度、性能、復雜度），特別注意避免單點故障和緩解性能瓶頸（如緩存），并在涉及時間戳的方案中嚴格保障時鐘同步。明確業務對“連續無空洞”的真正需求，通常空洞是可接受的。

2)存儲過程

在分布式數據庫中使用存儲過程，相比單機數據庫引入了更多復雜性和需要特別注意的問題，核心挑戰在于如何管理分布式環境下的數據一致性、事務、性能和復雜性。在一致性和事務方面，分布式事務因存在網絡開銷大，性能差等問題，需在強一致性（延遲高、阻塞風險）和弱/最終一致性（設計復雜）之間權衡選擇。在性能方面，分布式環境下存在網絡延遲、序列化開銷、協調開銷、全局鎖等都可能成為新瓶頸，此外數據分布情況下，跨分片訪問昂貴，也會對性能造成較大影響。在復雜性方面，分片鍵設計、分布式事務監控、跨節點部署/更新、異常調試困難會加大使用復雜性。

總之，在分布式數據庫中使用存儲過程，首先考慮其必要性。建議盡可能將復雜的業務邏輯放在應用層處理，利用其更強大的計算、狀態管理和容錯能力。如果必須使用，也應遵循精簡邏輯，避免復雜業務規則，聚焦核心數據操作。深入理解你所使用的特定分布式數據庫關于存儲過程執行模型、事務支持、分片策略和容錯機制的細節，嚴格遵守其最佳實踐。

3)觸發器

在分布式數據庫中使用觸發器相比單機數據庫存在更多風險和復雜性，其核心挑戰在于 "被動觸發行為的分布式傳播與狀態管理"。一方面，分布式環境下觸發器會存在修改其他分片數據的情況，此時會觸發隱式的跨分片事務或分布式查詢，性能極差且易出錯。如果有級聯情況，則情況會更為復雜且難以調試。

因此，在分布式數據庫中，使用觸發器需要極度謹慎，甚至極力避免。避免使用是第一選擇： 強烈建議重構業務邏輯，將觸發器的功能（如數據同步、審計、復雜校驗、級聯更新）移至應用層顯式實現。 應用層擁有對分布式事務、重試、冪等性和錯誤處理的完全控制能力。其次，如果必須使用，也應遵循觸發器邏輯百分百只操作修改所在同一個分片鍵分區內的數據。嚴格禁止在觸發器內執行任何可能導致訪問或修改其他分片的操作。

4)約束-主鍵

在分布式數據庫中，主鍵的設計不再僅僅是保證唯一性和提供索引效率，它直接決定了數據的物理分布、查詢性能、事務效率和可擴展性。與單機數據庫相比，復雜性顯著增加。一方面，在分布式數據庫中，主鍵與分片鍵存在強關聯，兩者可以不同，但主鍵必須包含分片鍵的所有列。其背后的原因是因為分布式數據庫通過主鍵必須包含分區鍵的約束，使得數據庫能夠通過分片鍵快速定位到具體分片，并在該分片內驗證主鍵唯一性。而且，分片鍵一旦選定，不會輕易修改，更改通常是代價極高的操作。此外，分布式數據庫還需考慮熱點問題，如通過單一或少量分片承載過高負載（寫入/讀取），導致集群性能瓶頸，因而應摒棄單調遞增主鍵在范圍分片的使用，后者會導致所有新數據都寫入最后一個分片（或按范圍分片時的末尾范圍），造成嚴重寫入熱點。通常建議選擇全局唯一但有高散列性的字段作為主鍵為上。

5)約束-外鍵

在分布式數據庫中使用和設計外鍵相比單機數據庫存在本質性差異和重大挑戰。核心矛盾在于 "分布式環境難以高效實現跨節點/分片的強一致性與原子性約束"。單機庫中，外鍵驗證是本地操作（檢查同一實例中的關聯表），開銷可控。在分布式中，外鍵引用的主表和被引用表很可能存儲在不同節點/分片上。這就存在跨分片查詢驗證問題，通常需要向父表所在的分片發送遠程查詢或事務請求。每次約束檢查都可能引入顯著的網絡往返延遲，嚴重拖慢寫入性能（尤其是高頻插入或批量導入）。高效的約束檢查通常需要父表的唯一鍵（主鍵） 在所有節點上有全局索引，這意味著插入父表本身也需要進行跨節點的全局唯一性檢查，而維護全局索引的代價很高。同樣，外鍵約束涉及修改多個表（或多個分片），需要保證原子性。分布式數據庫中，即使單次操作只修改子表的一行，如果該行引用了父表在不同分片上的鍵，該操作也會升級為跨分片事務，如產生級聯操作則更是一場災難。

在分布式數據庫中，極其不推薦使用傳統的外鍵約束，除非業務場景極其簡單且數據庫明確支持并能保證性能可接受。首選方案是在業務邏輯層（應用代碼）顯式地、原子性地管理數據的插入、更新、刪除順序和驗證關聯關系。避免數據庫隱式開銷。可靈活選擇弱一致性模型。如一定要在庫內實現，則可考慮應考慮共位設計，即父表和子表使用相同的分片鍵，則它們通常存儲在同一分片上。此時在同一分片內執行操作，約束檢查變為本地操作，性能大幅提升。因此如果必須使用分布式數據庫的外鍵，務必進行充分的性能測試、設置嚴格約束、禁用級聯操作，并深刻理解特定數據庫的實現機制和限制。分布式系統的核心優勢在于可擴展性和分區容忍性。外鍵約束（尤其是強制強一致性的外鍵）在很大程度上與這些優勢背道而馳，謹慎評估其必要性是所有分布式數據庫設計的必修課。

6)約束-唯一

在分布式數據庫中設計和使用唯一約束面臨的核心挑戰是 “如何在數據分散存儲的背景下高效實現全局唯一性驗證”。與單機唯一性檢查僅需本地查找不同，分布式數據庫中唯一鍵值可能分布在任意節點上，驗證需跨節點通信 和全局狀態協調。這不可避免會受到網絡延遲的影響，并進而影響吞吐量，想象下在高并發或大批量寫入中，唯一性檢查所帶來的性能損耗是巨大的。一般要求唯一約束列必須包含分片鍵，這樣只需在本地分片驗證唯一性（高效單片操作），否則就需要引入全局索引來維護唯一性，但后者也面臨高昂的維護成本。

在分布式數據庫中，唯一性約束優先考慮在應用層實現，這樣可避免這一高昂成本的操作。如必須在數據庫中執行，可通過綁定分片鍵的方式將其轉換為本地操作，降低開銷；拒絕可能的跨分片唯一性約束。

7)全局索引

分布式數據庫中，有本地索引與全局索引的區別。本地索引是指與主表分片一一對應，綁定在一起；全局索引則是獨立于主表分片，可擁有自己的分片策略，可以理解為“另一張表”。全局索引，主要是用于加速非分片鍵查詢的核心機制，但其設計與使用存在顯著挑戰。與本地索引的本質差異在于：數據位置分散性、網絡通信開銷、跨節點事務成本。全局索引因為需要跨節點更新索引條目（遠程寫入），不可避免地引入了分布式事務來保證原子性，進而導致寫入延遲加大，高并發場景全局索引成為瓶頸。

是使用中，分布式數據庫優選使用本地索引，或者通過分片鍵的冗余設計將原本需要全局索引的轉換為本地索引。此外也可以在允許的情況下，采用異步索引機制或干脆使用外部索引引擎來避免此部分開銷。

8)分區

在分布式數據庫中，有兩個容易混淆的概念就是“分片”和“分區”，很多數據庫甚至就是不區分的。一般來說，分布式數據庫中的分片，是指數據庫依據用戶設置的分片規則或系統內置規則將表的數據分布到多個節點上，以實現負載均衡和高并發處理能力。而分區則是一種邏輯概念，即在 SQL 層面定義 Range、List、Hash 等分區策略，從而進一步優化查詢性能、管理大表數據、支持按時間歸檔等場景。分區概念之前在如Oracle數據庫中，其定義更像現在的分片概念，是一種物理存儲上的劃分，只不過不是分布在不同節點，而是在一個節點的不同存儲區域（段）。因此這部分還要看不同數據庫的實現原理是什么，沒有統一之規。

9)分片

分布式數據庫的核心在于數據分片，支持拆分方式越多、數據拆分越均衡對未來等運行效率越有幫助。這里重點關注下數據拆分的自動與手工。隨著分布式數據庫被越來越多的用戶所使用，如何降低用戶選擇使用分布式的門檻成為關鍵。一個核心問題就是是否能實現數據的自動拆分，而不需要人工介入。這里重點對比下兩種策略

1.png

2. 國產分布式產品相關能力對比

圖中有的文字上打了星號，是由于文檔中對此能力有限制性說明，沒有打星號的不代表都支持，只是沒有找到詳細說明。從整體來看，大部分的能力都已經支持，這里可以從幾個維度區分下。針對庫內計算（存儲過程、觸發器），雖然都支持，但很多都不建議使用；針對分布式對象設計（如序列、索引等），有明顯的分布式設計特點，需要注意；針對約束類，大多也意見放在外面解決（特別是外鍵），分布式環境開銷還是偏大；至于分片本身，各家能力差不多，對數據拆分的設計至關重要，完全透明化的設計也有，但效果要分場景來看。上述能力都是從各家的文檔查到的，這里面差異較大，有的就說支持，但沒有詳細說明；有些則比較好，說明支持，但也詳細說明了約束限制和最佳實踐，這對于用戶來說幫助很大。

2.png