使用mysql查詢id，解析分布式主鍵MongoDB？

可以的。

全局唯一 ID

有些同學可能會有疑問，MySQL 數據庫本身就有自增長的主鍵，為什么還需要別的組件協助生成呢？

如果是單臺 MySQL 數據庫的話，當然是用本身的自增長序列就可以了，但是如果我們做了分庫分表之后呢？比如用戶表 userTable 數據量達到了 4000 萬，單表有些吃力，我們將 userTable 拆成兩張表保存到兩個 MySQL 數據庫中；這時候如果再使用數據庫本身的自增序列，倒是也不會有錯，每一個表內的主鍵不會重復，但是表和表比較的話，主鍵 ID 可能會發生重復；這時候就需要使用組件或者算法，生成全局唯一 ID 了。

MongoDB ObjectId

MongoDB 的 ObjectId ，也是可以用于全局唯一 ID 的。

{"_id": ObjectId("5d47ca7528021724ac19f745")}

MongoDB 的 ObjectId 共占 12 個字節，其中：

3.2 之前的版本（包括 3.2）：4 字節時間戳 + 3 字節機器標識符（機器 ID） + 2 字節進程 ID + 3字節隨機計數器；

3.2 之后版本：4 字節時間戳 + 5 字節隨機值 + 3 字節遞增計數器；

其中時間戳字節可以保證毫秒級唯一，節機器標識符考慮到了分布式，字節進程 ID 保證了同一臺服務器運行多個實例時的唯一性，字節遞增計數器保證了同一個時間點內 ID 的唯一性。

優缺點

不管是老版本還是新版本，MongoDB 的 ObjectId 至少都可以保證集群內的唯一，我們可以搭建一個全局唯一 ID 生成的服務，利用 MongoDB 生成 ObjectId 并對外提供服務（MongoDB 的各語言驅動都實現了 ObjectId 的生成算法）。

優點：MongoDB 的性能不錯，可以使用集群部署，保證其高可用；ID 內自帶一些含義，比如時間戳，必要的時候可以進行反解；

缺點：和數據庫一樣，需要引入對應的組件/軟件，增加了系統的復雜度；最關鍵的是，這兩種方案都意味著生成全局唯一 ID 的系統（服務），會成為一個單點，在軟件架構中，單獨就意味著風險；如果這個服務出現問題，那么所有依賴于這個服務的系統都會崩潰掉。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。