MySQL Cluster (NDB) vs SQL Server 同表查詢性能對比：9 分鐘 vs 22 秒的深度反思

測試場景

• 表結構：urllog (ID PK, url VARCHAR(435), create_time DATETIME)，引擎 NDBCLUSTER。
• 數據量：SQL Server 40 萬，導入 MySQL 32 萬。
• 查詢：SELECT url, COUNT(*) cnt FROM urllog GROUP BY url ORDER BY cnt LIMIT 10（MySQL）
  SELECT TOP 10 url, COUNT(*) cnt FROM urllog GROUP BY url ORDER BY cnt（SQL Server）

結果震驚

性能差距 ~25 倍。

根因分析：NDB 架構特性導致

1. 分佈式聚合開銷巨大：GROUP BY 需將所有分片數據拉取到單節點（或協調節點）排序聚合，網絡傳輸 + 序列化/反序列化 成本極高。
2. 無本地索引排序優化：NDB 索引為分佈式 T-Tree/有序索引，ORDER BY cnt 無法利用索引順序，需全量物化排序。
3. 網絡延遲放大：叢集節點間通信（即使本機多進程模擬）引入額外延遲。
4. 並行度受限：單查詢協調節點單線程聚合，無法利用多核並行。
5. SQL Server 優勢：單機共享內存架構，優化器可並行掃描、哈希聚合、Top-N 排序截斷，極其高效。

優化方向（若必須用 NDB）

• 避免大結果集 GROUP BY + ORDER BY，改用應用層分頁聚合或物化視圖預計算。
• 將聚合維度表單獨存放，定時同步計數器（反規範化）。
• 升級至 MySQL Cluster 7.5+，支持並行查詢、適應性查詢本地化。
• 評估是否真正需要 NDB 的「多主寫入+自動分片+零單點故障」，若業務可接受單主，InnoDB + 讀寫分離性能遠優於 NDB。

架構選型啟示

NDB 解決的是「寫入擴展與極高可用」，而非「複雜聚合查詢性能」。OLAP 型聚合查詢應走專用列存（ClickHouse、Doris、StarRocks）或單機 InnoDB 讀副本。不要用錘子拧螺絲——為業務選對架構，而非為架構找業務。