問題
只要看看數據管理和關系型數據庫管理系統規則，就發現關系型數據庫是使用一個合理級別的並發來維護數據和當支持數據管理行為例如備份、成批清除、改變數據結構等等時的最合適的方法。
一個問題是在傳統應用程序中編程語言的不同。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字段。
