冗長的SQL Server查詢將消耗你的CPU

問題

只要看看資料管理和關係型資料庫管理系統規則，就發現關係型資料庫是使用一個合理層級的並發來維護資料和當支援資料管理行為例如備份、成批清除、改變資料結構等等時的最合適的方法。

一個問題是在傳統應用程式中程式設計語言的不同。SQL(結構化查詢語言 (SQL))語言是一個聲明性語言，在大多數公司裡，它成為了用於描述“我需要什麼”和“從哪裡擷取”的“資料語言”。OOP(物件導向編程)語言成為了全世界R&D(研究和開發)公司的開發人員最普遍採用的語言。那麼我們怎樣彌補這個差距呢?

專家解答

這兩個趨勢使得需要一個彌補這個差距的“橋”，它是通過將請求從物件導向語言翻譯成SQL來彌補的。在大多數情況下，DAL(資料訪問層)是用來描述以一種集中方式管理所有這些“資料拼接任務”的機制的。

資料庫供應商(Microsoft、Oracle、IBM等等)因其對SQL的特別喜愛而提供了眾多私人命令，在DAL中的翻譯就需要支援許多選項。而最後的結果是執行有時會失去內嵌到引擎中的效能最佳化。這使得許多這樣的DAL以一種非常直接的方式被執行，它將這個請求分解成許多小段，它們各自被翻譯成相應的SQL語句並建立將要象徵性地進行這項工作的“SELECT…FROM…WHERE…”條件從句。

“機器編寫的SQL語句”有時會是很長的文本語句。在32位和64位系統上，包含SQL語句的字串長度是定義為65,536 *網路資料包大小。預設的網路資料包大小為4096，所以SQL語句文本限制為256MB。

我懷疑長文字查詢(遠小於256MB)將會對伺服器的CPU造成負擔。所以我在這篇文章中進行測試和公布。在這篇文章裡，我將介紹介紹一下內容：

證明長文字查詢將會消耗你的CPU。

給出關於在一個中等大小伺服器上預計的實際消耗的理解。

具有2GB RAM和4 x 10,000 RPM磁碟的雙核CPU。

測試表特徵

為了測試，我將建立一個有200，000行記錄的表(叫做t1000)。這個表有許多不同的資料類型，因為我認為這可以合理地表現生產環境中的一個普通表。這個表的特徵包括：

一個單獨的integer欄位作為主鍵(預設為蔟索引)。

一個varchar欄位。

一個類比額外1KB資料的char欄位。

五個用來建立WHERE條件從句中長文字查詢的integer欄位。