有多少次你發現某個查詢對經過清理的資料進行測試時能發揮充分的效能，但只在生產環境中卻只看到它停止一次？由於工作負載和資料量等環境之間的差異，這種情況一直在發生。因為這個原因，你可能會在生產環境中嘗試你的查詢。畢竟，調整生產查詢的最快方法是在生產伺服器上，不是嗎？雖然這是正確，但仍有許多危險等待著那些愚蠢到沒有採取保障措施和協議的人。在本文中，我們將探討在生產環境中測試查詢的一些相關風險。
一些需要考慮的風險
那些這樣做的人要謹記「測試」的要點是你正在測試的東西有可能發生「壞事情」。你可能無法想到任何風險，但那是因為在你執行測試之前，你不知道也不可能知道這些風險是什麼。一些可能發生的壞事情包括：
邏輯資料損壞
INSERT 和 UPDATE 陳述式就其本質而言，它們很可能會使用虛假或格式錯誤的資料建立記錄，或者沒有正確實現引用完整性。此外，不良資料可能會破壞先前經過測試且表現良好的應用程式對資料的邏輯假設。如果應用程式遇到錯誤記錄，它可能會導致「錯誤答案」甚至整個網站崩潰，直到發現損壞並手動修復為止。
效能下降
一個常見的情況是，你的測試應用程式正在執行一個資料表掃描，而你在開發實例中沒有識別該資料表，因為它在測試時只有大約 10,000 筆記錄，而在生產環境中則有 1 億筆記錄。一旦你的應用程式開始對一個或多個核心資料表進行資料表掃描，你的生產資料庫可能會陷入死結，直到你逐個終止查詢。更糟糕的是，一旦你的應用程式用完了所有可用的資料庫連線，你甚至無法在資料庫上打開命令 shell 來終止查詢。
鎖定問題
如果你忘記認可（COMMIT）一個交易，你可能會鎖定一半的資料庫，因為你的資料庫連線集區中有未認可的多陳述式交易。因此，客戶作業可能會超時並隨機鎖死。
最終使用者看到錯誤的資料
不良資料在許多層面上都是一個問題。壞處可以是出售沒有的庫存，也可以是存在沒有密碼的使用者帳戶，這樣你就有可能被駭客入侵。一個相關的問題是忘記刪除測試使用者。由於你可能是唯一知道它們存在的人，因此它們可能會一直在那裡，直到駭客發現你的「test123」使用者的密碼為「password123」。
未知和未定義的風險
還有無數其他災難和毀滅的情況，只是受限於你的想像力或那些喜歡看著我們受苦和掙扎的更高權力者......
總結
千萬不要因為你「理解」你的程式碼就認為壞事不會發生。這個想法的是瘋狂的。你可能會暫時擺脫不好的事，甚至可能很長一段時間。儘管如此，總有一天事情會變壞。當真的發生了，就會變得非常糟糕。
