仔細檢查查詢結果的最佳方法是在大表上
當您在大表之間編寫 SQL 查詢時，當結果表超過 2000 行時，有什麼好方法可以檢查您是否有正確的查詢？
不幸的是，您的問題過於籠統和廣泛，無法在這裡回答。這將是情境性的，取決於您要查詢的內容。這與檢查其他任何內容沒有什麼不同，例如您的應用程式碼是否正常工作。您需要分析輸出的結果，看看它是否對您要完成的工作有意義。您使用特定數據集的次數越多，您就越親密，並且對事物的外觀有更好的直覺感覺。所以時間和練習是關鍵。
我不確定您是說您的查詢是 2,000 多行程式碼，還是您的結果集是 2,000 多條記錄。對於前者，類似的原則適用於數據庫開發，就像正常應用程序開發和程式一樣。您不應該有一個 2,000 行程式碼長的查詢，甚至不應該有一個僅由這麼多行程式碼組成的實體（例如過程或函式）。如果你這樣做了，那麼查詢的設計就是糟糕的形式並且實現很差。相反，事情可能可以被簡化、重構、更巧妙地編寫，並分解為邏輯上分解程式碼片段的單個實體。
對於後者，2000行數據無論如何都不算多，抽查有效的話應該可以分析出來。
我假設您在談論臨時SELECT 查詢，而不是視圖或報告。視圖和報告（報告基礎的查詢）最好由受控的測試套件進行驗證。受控測試套件還將驗證 SQL UPDATE 和 DELETE 查詢。
如果情況很複雜，您可能必須為臨時查詢建構測試套件。
說了這麼多，驗證臨時查詢的最佳方法是詢問領域專家。使用者告訴您他們需要回答哪些業務問題；你寫SQL；領域專家會告訴您您的 SQL 是否返回了正確的行。（使用者可能是領域專家。）
過去，我是支持多地區訴訟的數據庫的數據庫設計師。一天，一位律師問我有多少未決事項。簡單直接的答案，只計算一張表中的行數，是錯誤的答案。嗯，從技術上講，這是正確的答案，但它缺乏細微差別。值得注意的是，很少有人對開放物質**的定義感興趣。
相反，每個感興趣的群體都有一個或多個與他們正在做的工作直接相關的公開問題的定義。有很多組。
IIRC，在 10 年左右的時間裡，我確定了 19 種不同的開放問題定義。我絕對無法確定查詢返回了正確的行。只有在該特定訴訟中具有豐富經驗的律師或律師助理才能判斷我提供的數據是否正確回答了“有多少未決事項？”這個問題。
領域專家是您的朋友。