MySQL 接入 Amoeba 代理六大避坑指南：從事務不支持到 SQL 規範強制

Amoeba 定位

基於 XML 配置、SQLJEP 解析的 MySQL 分庫分表中間件，較官方 MySQL Proxy（Lua 腳本）配置更簡單，但功能有明顯邊界。

六大核心限制與應對

1. ❌ 不支持事務
   任何 BEGIN/COMMIT/ROLLBACK、SET AUTOCOMMIT=0 會被屏蔽/報錯。
   ✅ 應對： 業務邏輯移至存儲過程（單庫內事務），或應用層補償事務（TCC/Saga），或升級支持事務的中間件。官方規劃未來支持。
2. ❌ 不支持跨庫 JOIN / ORDER BY
   分片鍵不同庫的表無法 JOIN，跨分片排序會將數據拉取到中間件內存合併，極其消耗資源。
   ✅ 應對： 設計階段避免跨分片 JOIN；必須跨庫查詢時，應用層分批查詢後內存合併（小數據量）。
3. ⚠️ INSERT 必須顯式列出列名
   分片規則依賴 SQL 解析提取分片鍵值。
   ❌ INSERT INTO t VALUES (1, 'a'); — 無法識別分片鍵。
   ✅ INSERT INTO t (id, name) VALUES (1, 'a'); — 可解析 id 路由。
   ✅ 強制開發規範： 所有 DML 必須寫全列名。
4. ❌ 不支持分庫分表
   僅支持**分 MySQL 實例**（Schema 級），不支持單實例內分表。
   ✅ 應對： 規劃實例拆分而非表拆分，或選用 ShardingSphere/MyCat 等支持表級分片的中間件。
5. ❌ 不支持大結果集查詢
   單次查詢返回 > 10 萬行會導致中間件 OOM、響應超時。
   ✅ 應對： 業務禁止無分頁全量查詢；大數據導出走mysqldump或應用分批游標讀取。
6. ⚠️ SQL 寫法強制規範
   ① FROM 後若非子查詢，**嚴禁帶括號**：FROM (t1) ❌ → FROM t1 ✅。
   ② 表/列名與關鍵字/函數名衝突，**強制反引號**：SELECT `order` FROM `group`;。
   ③ 建議所有標識符統一加反引號，避免版本升級新增保留字衝突。

選型建議

• 簡單讀寫分離、分庫路由、無事務、無跨庫 JOIN、SQL 可控 → Amoeba 輕量可用。
• 需分表、事務、跨庫查詢、異構數據源、可視化運維 → ShardingSphere / MyCat / Vitess。