SQL與測試資料
讓冗長 SQL 的條件與 JOIN 更易閱讀
使用工具
日誌出現長 SQL 時，先問它想取什麼。不斷橫向捲動容易漏看括號與 JOIN 條件。格式化讓結構清楚，便於按順序閱讀，但易讀不等於正確；工具不連接資料庫，也不執行 SQL。
按子句拆開虛構訂單查詢
選 PostgreSQL 格式化範例，可更容易找到大寫的 SELECT、FROM、LEFT JOIN、WHERE、ORDER BY。按回傳欄位、起點表、連接表、保留行、排序依次閱讀。這是虛構表，不必在真實資料庫執行。
select o.id,o.total,c.name from orders o left join customers c on c.id=o.customer_id where o.status='paid' and (o.total>=1000 or o.priority=true) order by o.id;保留原 SQL 對比。大寫和換行不是修正邏輯，資料表欄位存在、權限、結果筆數需要資料庫上下文。格式化成功不代表語意驗證或可執行。
確認 AND、OR 的作用範圍
範例要求 paid，且金額至少 1000 或 priority 為 true。去括號後按一般優先順序，priority 訂單可不論是否 paid 都被包含。格式化能顯示分組但不知道業務意圖，可用小額已付、大額未付、優先未付等虛構列推演。
JOIN 的 ON 與 WHERE 要分別讀。WHERE 要求右表值時可能篩掉 LEFT JOIN 未匹配列，不能只憑名字認定左列全保留。移動條件可能改變含義，應作為 SQL 修改審核而非格式化。
選擇方言不等於遷移 SQL
應選擇輸入來源的 PostgreSQL、MySQL 或 SQLite 方言。把 MySQL 當 PostgreSQL 格式化不會翻譯函數、型別、引用和日期行為。遇到不支援語法，先核對原方言，不要只為了成功而隨便切換。
日誌可能附時間、識別和耗時，應先確認 SQL 本文範圍，勿把字面值中的換行或引號當裝飾刪掉。參數單獨記錄時，先核對映射，不要急著手拼一個看似完整的敘述。
同名參數出現兩次時
佔位符轉換可分別輸入 SQL 與參數 JSON。兩個 :id 轉 PostgreSQL 時都是 $1；問號形式按每次出現需要參數，因此映射值重複兩次。不能只複製 SQL 卻沿用舊參數順序。
SELECT * FROM users WHERE id = :id OR manager_id = :id
Arguments: {"id":7}
PostgreSQL: id = $1 OR manager_id = $1
Question: id = ? OR manager_id = ? → [7, 7]轉換器會區分一般字串、註解與參數，但不是完整方言剖析器。PostgreSQL 的 ? 也可作運算子，因此問號輸入受限。複雜特有語法還應核對資料庫和驅動官方文件。
讀懂後決定下一步檢查
筆數過多查條件和連接，值不對查參數與 NULL，慢則需執行計畫和資料上下文。格式化不量測耗時、索引或鎖，也不證明變快，只提供更易調查的文字。
共用時將個人或秘密資料換成虛構值，同時保持相關結構。資料庫執行是另一項需授權的步驟。先讀子句和括號，再核對參數，能在考慮執行前明確問題。
SQL 易讀之後，再思考結果列數
JOIN 清楚後應問每個訂單對應另一表幾列。鍵不唯一時所謂單一顧客可能放大列數。格式化不讀表結構資料，不能驗證基數。先查哪裡增列，不要直接加 DISTINCT 隱藏；格式化只是讓調查更容易。
LEFT JOIN 可空側欄位上的 WHERE 條件可能刪掉未符合列，ON 與 WHERE 之間移動不是外觀變化。利用清晰結構，用少量虛構資料先寫預期結果。工具不會搬條件或執行，資料庫驗證仍是另行限定權限的工作。
可讀不等於更快，因為未提供索引、列數、統計與計畫。應分開報告格式化與保持結果的已驗證最佳化，後者需目標資料庫計畫和實測。大寫關鍵字或換行不是效能證據。