分庫分表的常用中間件有哪些？有哪些問題中間件無法提供幫助、只能改寫業(yè)務(wù)代碼的場景？使用了什么中間件？分庫分表的實(shí)現(xiàn)場景和方式有哪些？分表之后，要查詢兩個(gè)表的數(shù)據(jù)要怎么查？分庫分表的優(yōu)缺點(diǎn)是什么？分庫分表業(yè)界有哪些替代方案？（提示：分布式文件系統(tǒng)，因?yàn)榉謳旆直頃?huì)出現(xiàn)降低QPS，比如range查詢失效）為什么做了分庫分表后分頁比較困難了？如果10億數(shù)據(jù)要分表，要怎么分？業(yè)務(wù)怎么切？分庫分表怎么保證數(shù)據(jù)一致性？選的什么分片鍵？什么分片算法？分庫分表后的分布式ID怎么做？（2025年目前為止的?？兔娼?jīng)關(guān)于分庫分表的問題收集）總結(jié)：分布式事務(wù)一致性問題跨節(jié)點(diǎn)關(guān)聯(lián)查詢JOIN問題（解決方案：1.全局表 2.冗余字段 3.建立1：1的ER實(shí)體關(guān)系分片）非分片鍵的查詢問題（1.創(chuàng)建映射表 2.  前綴分片法  3.使用ES搜索引擎（最后才說要抬高立意）全局分布式ID問題（1.UUID 2.雪花算法 3.mysql/Redis 4.美團(tuán)Leaf（1.Leaf-segment 2.Leaf-snowflake）跨庫跨節(jié)點(diǎn)分頁查詢問題（不會(huì)）與朋友合作的開源Go KV項(xiàng)目路過可以的話幫我們點(diǎn)個(gè)star???https://github.com/FinnTew/FincasKV參考面試回答：（吟唱）<strong>面試官：分庫分表后、如何解決跨節(jié)點(diǎn)JOIN查詢問題</strong><span> <code><參考回答：></code></span>  分庫分表后、跨節(jié)點(diǎn) JOIN 查詢會(huì)帶來性能問題。 為了解決這個(gè)問題主要有以下幾種方案：  1. 全局表： 如果是一些數(shù)據(jù)量小、變動(dòng)不頻繁的基礎(chǔ)數(shù)據(jù)（比如權(quán)限表、配置表、商品分類表）可以將它們復(fù)制到每個(gè)數(shù)據(jù)庫節(jié)點(diǎn)。 這樣查詢時(shí)可以直接在本地 JOIN、避免跨庫。 但需要保證全局表的數(shù)據(jù)同步。  2. 冗余字段： 如果經(jīng)常需要 JOIN 某些字段、可以將這些字段冗余存儲(chǔ)到需要查詢的表中。 比如在訂單表中冗余存儲(chǔ)用戶的姓名和地址。 這樣查詢訂單信息時(shí)、就不用 JOIN 用戶表了。 但需要保證冗余字段的數(shù)據(jù)一致性。  3. ER 分片： 如果表之間存在很強(qiáng)的關(guān)聯(lián)關(guān)系、比如訂單表和訂單詳情表、可以按照相同的規(guī)則進(jìn)行分片、保證它們?cè)谕粋€(gè)數(shù)據(jù)庫節(jié)點(diǎn)上。 這樣就可以避免跨庫 JOIN。（ER: 例如將訂單表 和訂單詳情表按照 訂單ID進(jìn)行分片）使用一致性哈希算法、將 訂單ID映射到不同的數(shù)據(jù)庫節(jié)點(diǎn)上。關(guān)鍵： 保證具有相同 訂單ID 的訂單表記錄和訂單詳情表記錄、始終被分配到同一個(gè)數(shù)據(jù)庫節(jié)點(diǎn)上。)<strong>面試官：非分片鍵的字段如何查詢問題</strong><span> <code><參考回答：></code></span>問題背景：我們選擇分片鍵的時(shí)候都是選用查詢場景最多的字段來做分片鍵、但是可能需要查詢非分片鍵下的所有所有數(shù)據(jù)。例如電商用(訂單ID) 做分片但是我們可能會(huì)查詢訂單類型、這些數(shù)據(jù)可能被分到了不同的庫、我們需要聚合所有庫的查詢、然后返回給前端。導(dǎo)致效率低下回答參考方案：<strong>1.關(guān)系映射表：映射關(guān)系表就是存儲(chǔ)待查詢字段和分片鍵映射關(guān)系的一張表、當(dāng)要使用非分片鍵查詢的時(shí)候、先到映射關(guān)系表中查詢字段所對(duì)應(yīng)的所有分片鍵、再根據(jù)分片鍵查詢所有信息。</strong>（例如創(chuàng)建一個(gè)額外的映射表Map、包含 訂單ID 和 訂單類型 的對(duì)應(yīng)關(guān)系。當(dāng)插入新訂單時(shí)、同時(shí)更新這個(gè)映射表。查詢時(shí)先查映射表獲取所有的 訂單ID、再根據(jù) 訂單ID列表查詢分片表?？偨Y(jié)一下就是用映射去查詢我們就可以得到了 缺點(diǎn)是要維護(hù)新的Map 適用于對(duì)實(shí)時(shí)性要求不高的情況）<strong>2.  前綴分片法：利用（訂單ID）的某些特征來決定數(shù)據(jù)存儲(chǔ)在哪個(gè)分片上，并將這個(gè)嵌入到主鍵中。 這樣既可以通過主鍵進(jìn)行分片、又可以通過UID進(jìn)行分片。</strong>（例如在生成 訂單時(shí)，嵌入 用戶ID 的某些特征 例如 用戶ID的最后一位。然后使用包含這個(gè) 訂單ID進(jìn)行分片。這樣既可以通過 訂單分片，也可以通過 用戶ID的特征進(jìn)行路由。優(yōu)點(diǎn)不需要額外的存儲(chǔ)空間 缺點(diǎn)是可能會(huì)產(chǎn)生如果 用戶ID分布不均勻、可能會(huì)導(dǎo)致數(shù)據(jù)傾斜）<strong>3.ES: 將所有訂單數(shù)據(jù)同步到ES中、利用 ES 的全文檢索和聚合分析能力、進(jìn)行多條件查詢</strong><strong>面試官：分庫分表后的分布式ID怎么做？</strong><span> <code><參考回答：></code></span>問題背景：分庫分表后需要一個(gè)唯一ID來標(biāo)識(shí)一條數(shù)據(jù)或消息?；卮饏⒖挤桨福赫f一下各大方案及優(yōu)缺點(diǎn)就行。1. UUID（優(yōu)點(diǎn)本地生成、缺點(diǎn)是16字節(jié)128位存儲(chǔ)成本高以及會(huì)產(chǎn)生頁分裂問題2.雪花算法（優(yōu)點(diǎn)生成性能高、可以根據(jù)業(yè)務(wù)特征分配Bit位、缺點(diǎn)是依賴強(qiáng)時(shí)間回鐘）3.MySQL自增主鍵和Redis的Incr命令（不做探討）3. 分布式ID生成服務(wù)、如美團(tuán)的leaf算法（Leaf-segment和Leaf-snowflake）大家這里可以去看美團(tuán)技術(shù)文章 這里引導(dǎo)一下思路就好<strong>面試官：如果要你選擇一個(gè)分布式ID生成方案你會(huì)選什么</strong><span> <code><參考回答：></code></span>1.如果 對(duì) ID 的有序性有要求、且需要高性能的 ID 生成服務(wù)、我會(huì)優(yōu)先選擇雪花或者 Leaf-snowflake 。 雪花的優(yōu)點(diǎn)是生成速度快、ID 趨勢(shì)遞增、有利于數(shù)據(jù)庫索引的性能優(yōu)化。Leaf-snowflake 在雪花的基礎(chǔ)上、對(duì)時(shí)鐘回?fù)軉栴}進(jìn)行了優(yōu)化2.如果 對(duì) ID 的有序性沒有要求、且可以容忍一定的存儲(chǔ)空間浪費(fèi)、我會(huì)選擇 UUID。 優(yōu)點(diǎn)是本地生成、不需要依賴外部服務(wù)、生成速度快。3.如果 業(yè)務(wù)規(guī)模較大、對(duì) ID 的全局唯一性、高性能和可擴(kuò)展性有較高要求、我會(huì)選擇構(gòu)建一個(gè)專門的分布式 ID 生成服、例如使用 Leaf-segment 算法。 的優(yōu)點(diǎn)是統(tǒng)一管理、方便維護(hù)和擴(kuò)展、可以根據(jù)業(yè)務(wù)需求定制 ID 生成規(guī)則。更新一下CSDN： https://blog.csdn.net/wy990880?type=blog大家copy內(nèi)容背誦就好了在我看來這個(gè)就是點(diǎn)到為止說出自己能知道多少就說多少 不要一點(diǎn)不知道 說多少都是緣分而且我覺得面試官自己也沒做過分庫分表具體的技術(shù)深度大家看看別的