查詢解析方案選型別只看功能清單MySQL 解析器選型先看業務實際 SQL而不是功能列表。網關、審計和改寫場景通常還要考慮版本跟進、錯誤位置、AST 可修改性、內存行為和許可證這些問題在接入后比“能否解析一條示例 SQL”更容易出成本。建立項目自己的兼容樣本從線上脫敏日志和遷移腳本中抽取語句保留 DDL、CTE、窗口函數、JSON、注釋、預處理參數和異常輸入。每次升級解析器都跑同一批樣本比較成功與失敗、AST 摘要和報錯位置。MySQL 方言版本需在依賴清單中明確不要用“全面兼容”描述。評估四類成本吞吐和分配用目標語言、真實語句長度和并發測試而不是引用第三方跑分。維護確認上游是否持續支持所需版本與安全修復。改寫檢查 AST visitor、格式化輸出和保留注釋的能力改寫后必須重新解析或校驗。集成原生源碼、Go 庫和 Java 關系代數工具的進程模型、許可證和部署復雜度不同。Vitess、TiDB、MySQL 源碼中的解析器以及 Calcite 各有適用位置。前兩者更常用于 Go 生態的網關或工具直接復用 MySQL 源碼會帶來版本綁定Calcite 更適合需要關系代數轉換的服務。具體結論仍應由樣本集和目標版本驗證。最小落地路徑先只解析和分類記錄不支持語法再引入只讀 SQL 的標注或審計。需要重寫時把改寫規則做成可關閉、可測試的獨立層并提供原 SQL、改寫 SQL、解析版本和拒絕原因的審計記錄。不要讓解析器替業務猜測意圖。