不靈活應用程序的 SQL Server 優化/配置
我負責監督使用 SQL Server 作為其後端儲存解決方案的應用程序。不幸的是，該應用程序沒有應該如何使用 RDBMS 的概念，並且似乎主要像使用 NoSQL 解決方案一樣使用它。應用程序最需要的是獲取和儲存單個記錄，並且不使用任何外鍵來保證數據完整性。
正如預期的那樣，這種出色的設計會導致性能相當差，因為將 RDBMS 扔到只需要磁碟上散列式方案的問題上就像在蚊子上使用大砲一樣。但是很遺憾，我無法修改該軟體，因為它是第三方的。
我已經看到許多提示，它們很高興告訴我應該使用更有效的查詢，但這根本不是一種選擇。SQL Server 似乎主要受 CPU 限制，大部分數據似乎也記憶體在記憶體中。有沒有一種方法可以優化/配置 SQL 處理來自此應用程序的請求的方式？（整個 SQL Server 實例僅供應用程序使用。）或者，是否有另一種解決方案，其行為類似於 SQL Server，但在處理簡單查詢時的速度類似於 NoSQL？SQL Server 是否有某種單程序模式使得鎖定記錄變得不必要？
我應該試一試任何現成的想法嗎？
更新： 因此，在對帶有自動生成的游標準備、執行、提取等的跟踪進行了大量處理之後，看起來大部分時間在關注的特定應用程序特性中都浪費在填充表上，只有第一行實際上是提取的。這實際上似乎是應用程序編寫方式的一個常見問題。
由於游標後面的選擇語句對數據進行排序，因此游標不能有效地使用動態計劃。最終，應用程序試圖獲取的數據是下一個記錄，其中
field A = document_id下一個field B值大於先前尋求的field B值。當然，這是游標的典型應用——如果應用程序以典型的方式使用游標的話。我正在尋找再次聯繫供應商，因為這……很糟糕。我認為他們更有可能彈出一個簡單的兩行已經存在的修復程序。因此，我希望生成一個更有效的查詢版本（仍然使用游標，具有相同的客戶端語義“給我下一條記錄，k？”）。我不確定如何在 TSQL 中製定這樣的查詢，因為我給出的所有內容都會導致掃描，即使使用我認為有用的索引也是如此。（真的，應該只需要一個 b-tree 搜尋，但不知何故，我似乎無法到達那裡。）
我們都去過那裡。沒有的人總有一天會遇到這種情況！
有一種處理第三方恐怖軟體的教科書方法：
- 證明有問題。辨識並記錄瘋狂的查詢和數據訪問模式。
- 向供應商提供您的問題證據。如果您可以證明查詢的重寫表明改進是可能的，那麼供應商就很難忽視您的擔憂。
- 如果您沒有收到供應商聯繫人的回复，請升級。如果你不能發出足夠多的聲音讓別人聽到，也許你的 CTO 可以。
- 如果您在沒有任何成功的情況下達到第 4 步，您可能會犧牲卵泡或註意到最初的灰色跡象。這是第三方開發負責人的巫毒娃娃可以緩解一天的壓力的地方。帶有公司標誌的飛鏢是一種可接受的選擇。
回到現實世界，我們有哪些實用的方法：
- 用鐵把它殺死。說起來總是讓我很痛苦，但有時將硬體扔到問題上可能是最快、最便宜、風險最低的解決方案。
- 了解根本原因。執行與完全在您控制之下的系統相同的分析。確定最頻繁的查詢，即 CPU 最高、讀取次數最多、持續時間最長的查詢，查看 tempdb 使用情況，分析計劃記憶體（在這些場景中經常出現單次使用的即席查詢）。
- 索引。Database Tuning Advisor (DTA) 是一種有用的工具，可用於分析您幾乎無法控制的工作負載。特別是，它可以發現索引視圖的候選者和缺失的多列統計資訊，這可能並不明顯。
- 計劃指南。如果您發現可以重新制定執行計劃的查詢，計劃指南為您提供了一種在不修改源查詢的情況下強制執行該計劃的方法。