SQL 方言轉換提示詞（MySQL、PostgreSQL、Oracle、SQL Server、Hive / Spark SQL 互轉，標出語義差異）
遷移數據庫、把業務庫的查詢搬到數倉、或者照着別人的 SQL 改到自己的數據庫時用：讓 AI 轉換語法的同時，逐項標出函數、日期處理、空值與字符串比較、分頁、自增等語義差異，避免「語法能跑、結果不對」。
通用大模型 對話模型通用
請把下面的 SQL 從源數據庫轉換為目標數據庫。你是一名同時熟悉這兩種數據庫的數據工程師，最關心的是轉換後結果是否和原來完全一致。 - 源數據庫及版本：[如 MySQL 5.7] - 目標數據庫及版本：[如 PostgreSQL 16] - 待轉換的 SQL（可以是查詢、建表語句、存儲過程）： [粘貼 SQL] - 涉及的表結構（如果轉換依賴字段類型）： [表結構] 輸出： 1. 轉換後的 SQL，放在代碼塊中，保留原有註釋。 2. 改動對照表：位置 | 原寫法 | 新寫法 | 原因。 3. 語義差異檢查（只列出這段 SQL 實際涉及的項，逐一說明是否會導致結果不同）： - 日期與時間：日期函數、格式化字符串、時區處理、日期相減的結果單位； - 字符串：拼接方式、空字符串與空值是否被視為相同、大小寫和尾部空格的比較規則、字符集與排序規則； - 空值：聚合、排序時空值的位置、COALESCE 等函數的差異； - 數值：整數除法是否截斷、四捨五入函數的行為、精度； - 分組：源數據庫是否允許 SELECT 中出現未分組的列，目標數據庫是否允許； - 分頁、取前 N 行、自增主鍵、序列、布爾類型、引號與標識符大小寫； - 隱式類型轉換在兩邊是否一致。 4. 需要人工確認的地方：兩種數據庫行為不同、無法確定原 SQL 意圖時，列出選項而不是自行決定。 5. 驗證建議：給出用來比對新舊結果的查詢（例如對比行數、關鍵字段彙總值、抽樣記錄）。 不要編造目標數據庫不存在的函數；拿不準某個函數在目標版本中是否可用時，標註「需在目標版本驗證」。
高亮處換成你自己的內容：[如 MySQL 5.7]、[如 PostgreSQL 16]、[粘貼 SQL]、[表結構]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[源數據庫] 和 [目標數據庫] 一定要寫版本號，同一個數據庫不同版本支持的語法差別很大（比如窗口函數、JSON 函數）。涉及字段類型的轉換（尤其是日期和字符串），把表結構也貼上。
常見坑：
- MySQL 在寬鬆模式下允許 SELECT 中出現沒有參與分組的列，遷到 PostgreSQL 會直接報錯；更麻煩的是原 SQL 返回的其實是「任意一行」的值，需要和業務確認原本想要哪一行。
- Oracle 把空字符串當作空值處理，遷到其他數據庫後，原本
IS NULL能查到的數據可能查不到了。 - 整數相除：有的數據庫得到小數，有的直接截斷為整數，比例、佔比類的計算最容易因此出錯。
追問技巧：轉換完成後，在兩邊各跑一次驗證查詢，把結果差異貼回去，問「這些差異由哪一處語義不同造成」。
示例輸出
示例，僅供參考（MySQL 5.7 轉 PostgreSQL 16，節選）
sql
SELECT u.city,
STRING_AGG(DISTINCT u.name, ',') AS names, -- 原為 GROUP_CONCAT
TO_CHAR(MAX(o.created_at), 'YYYY-MM') AS last_ym, -- 原為 DATE_FORMAT(..., '%Y-%m')
COALESCE(SUM(o.amount), 0) AS total -- 原為 IFNULL
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.city;| 原寫法 | 新寫法 | 原因 |
|---|---|---|
GROUP_CONCAT(DISTINCT name) | STRING_AGG(DISTINCT name, ',') | 函數名不同；注意 MySQL 有預設長度上限，會截斷結果，PostgreSQL 不截斷 |
SELECT u.city, u.level ... GROUP BY u.city | 刪除 u.level | PostgreSQL 不允許未分組的列，需確認 原本想取哪個 level |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～