阿里雲專家風移「出診」記錄：SQL Server 疑難雜症解決之道（上篇）

授人予魚而不如授人予漁，本系列專題（上篇）為大家推薦了31篇好文，希望可以幫到大家！

「出診」：RDS SQL Server死鎖（Deadlock）

1. RDS SQL Server死鎖（Deadlock）系列之一使用DBCC捕獲死鎖

經常會被客戶問道：「應用程序被死鎖報錯啦？影響很大，到底是哪個進程導致了死鎖發生的啊？怎麼解決啊？怎麼辦呀？」。如何解決呢？

點擊閱讀詳情

2. RDS SQL Server死鎖（Deadlock）系列之二使用Profiler捕獲死鎖

不管是RDS SQL Server還是自建，死鎖的確是一個非常頭疼的問題。這篇文章是以死鎖問題為背景，分享死鎖文章系列之二使用Profiler捕獲死鎖。

點擊閱讀詳情

3. RDS SQL Server死鎖（Deadlock）系列之三自動部署Profiler捕獲死鎖

如何手動部署Profiler來捕獲死鎖以及對死鎖發時場景重現，這篇文章是將這個手動部署的過程自動化話，實現一鍵部署，既快捷方便，又簡單適用。

點擊閱讀詳情

4. RDS SQL Server死鎖（Deadlock）系列之四利用Service Broker事件通知捕獲死鎖

這篇文章介紹一個非常有意思的捕獲死鎖的方法：使用SQL Server Service Broker Event Notification來捕獲死鎖。

點擊閱讀詳情

5. RDS SQL Server死鎖（Deadlock）系列之五利用Extended Events獲取死鎖信息

「在事先沒有任何跟蹤或者監控部署的情況下，阿里雲RDS SQL Server有沒有辦法獲取到歷史死鎖信息，供我們分析？」。Extended Events可以。

點擊閱讀詳情

6. MSSQL - 應用案例 - Event Notification + Service Broker構建死鎖自動收集系統

如何利用Event Notification與Service Broker技術相結合來實現死鎖信息自動收集系統。通過這個系統，我們可以全面把控SQL Server資料庫環境中所有實例上發生的死鎖詳細信息。

點擊閱讀詳情

「出診」：高CPU使用率

1. RDS SQL Server - 最佳實踐 - 高CPU使用率系列之索引缺失

CPU高使用率往往會導致SQL Server服務響應緩慢，查詢超時，甚至服務掛起僵死。本系列文章之一的「索引缺失」就是CPU高使用率的最常見的原因。

點擊閱讀詳情

2. RDS SQL Server - 最佳實踐 - 高CPU使用率系列之二索引碎片

高CPU使用率的原因之一是索引缺失，而「索引碎片」是CPU高使用率的又一常見的原因。解決索引碎片問題是解決SQL Server服務響應緩慢，查詢超時。

點擊閱讀詳情

3. RDS SQL Server - 最佳實踐 - 高CPU使用率系列之數據類型轉換

前兩篇文章討論了導致CPU高使用率的兩個重要原因是索引缺失和索引碎片，本系列文章之三討論數據類型隱式轉換話題。

點擊閱讀詳情

4. RDS SQL Server - 最佳實踐 - 高CPU使用率系列之非SARG查詢

RDS SQL Server客戶遇到最多的一個問題便是高CPU使用率導致導致SQL Server服務響應緩慢，查詢超時，甚至服務掛起僵死。這有非SARG查詢導致CPU的高利用率的解決之道。

點擊閱讀詳情

5. SQL Server - 最佳實踐 - 參數嗅探問題

這篇文章從參數嗅探是什麼，如何產生，表象是什麼，會帶來哪些問題，如何解決這五個方面來探討參數嗅探的來龍去脈。

點擊閱讀詳情

列存儲索引

1. SQL Server 2012列存儲索引技術

MS SQL Server 2012首次引入了列存儲索引（Columnstore Index）來加速數據分析（OLAP）和數據倉庫（Data Warehouse）場景的查詢，它主要是通過將數據按列壓縮存儲的方式來減少查詢對磁碟IOPS開銷和CPU開銷，最終達到提升查詢效率，降低響應時間的目的。當然，列存儲索引也不是一把萬能的鑰匙，在SQL Server 2012版本中它有諸多非常嚴苛限制條件。

這篇文章會從以下幾個方面來介紹列存儲索引：

• 列存儲索引所涉及到的基本概念
• 列存儲索引的結構
• 列存儲索引對查詢性能的影響
• MS SQL Server 2012上列存儲索引的限制
• 解決列存儲索引表只讀問題

點擊閱讀詳情

2. SQL Server 2014聚集列存儲索引

微軟在SQL Server 2012引入了列存儲技術，使得OLAP和Data warehouse場景性能提升10X，並且數據壓縮能力超過傳統表7X。這項技術包含三個方面的創新：列存儲索引、Batch Mode Processing和基於Column Segment的壓縮。但是，SQL Server 2012列存儲索引的一個致命缺點是列存儲索引表會進入只讀狀態，用戶無法更新操作。SQL Server 2014引入了可更新聚集列存儲索引技術來解決列存儲索引表只讀的問題，使得列存儲索引表使用的範圍和場景大大增加。

點擊閱讀詳情

3. SQL Server 2016 列存儲技術做實時分析

數據分析指導商業行為的價值越來越高，使得用戶對數據實時分析的要求變得越來越高。使用傳統RDBMS數據分析架構，遇到了前所未有的挑戰，高延遲、數據處理流程複雜和成本過高。這篇文章討論如何利用SQL Server 2016列存儲技術做實時數據分析，解決傳統分析方法的痛點。

點擊閱讀詳情

4. MSSQL－應用案例－SQL Server 2016基於內存優化表的列存儲索引分析Web Access Log

在日常的網站運維工作中，我們需要對網站客戶端訪問情況做統計、匯總、分析和報表展示，以數據來全面掌控網站運營和訪問情況。當不可預知的意外情況發生時，我們可以快速發現問題以及採取相應的措施。比如：當網站受到黑客攻擊時的流量陡增，又或者是網站某個資源發生意外拋異常等情況。

在提供Web服務的伺服器上，比如IIS、Apache都存在訪問日誌記錄，這篇是文章是以SQL Server 2016基於內存優化表的列存儲索引來分析Apache Web Access Log為例，講解分析網站訪問情況，因此，我們需要解決以下幾個問題：

• Apache Web Access Log格式介紹
• 列存儲索引表結構的設計
• Apache Web Access Log導入到列存儲索引表
• 網站訪問流量統計
• 客戶端主機訪問的分布情況
• 客戶端主機訪問的資源統計
• 異常URI訪問統計
• Response Code分布情況

點擊閱讀詳情

5. SQL Server on Linux列存儲索引

「鳥兒啊，聽說微軟至SQL Server 2012以來，推出了一種全新的基於列式存儲的索引，你去研究看看SQL Server on Linux對這個功能的支持度如何，效率有多大的提升？」。老鳥又迫不及待的開始給菜鳥分配任務。

的確如老鳥所說，從SQL Server 2012開始推出了列存儲索引，這個版本限制頗多，但是它對統計查詢的效率提升又是實實在在的。所以，讓我們來看看SQL Server on Linux列存儲索引對統計查詢的效率提升情況如何。

這裡也順便提一下SQL Server 2012 列存儲索引的限制，比如：

• 非聚集列存儲索引是只讀的，換句話說，基表會變成Read-Only
• 僅支持非聚集列存儲索引
• 只能通過刪除及創建索引的方式重建索引，而不可使用ALTER INDEX命令
• 對應的表不可包含唯一性約束、主鍵約束或外鍵約束

......

點擊閱讀詳情

「出診」：臨時表和表變數

1. SQL Server 表變數和臨時表系列之概念篇

「菜鳥啊，最近我看到阿里雲開發者論壇的資料庫RDS中有人在提SQL Server表變數和臨時表如何選擇的問題，你去深入探討下這個問題吧，解答解答他們的疑惑吧」，老鳥又開始為菜鳥找活幹了。

「鳥哥啊，關於表變數和臨時表使用選擇的問題啊，向來行業里爭論不休，我比較擔心我們的觀點被人家拍磚啊」。

「鳥啊，有爭論才說明這個問題有價值啊，所以我們才更應該去弄清楚，道明白啊」。反正老鳥總會找到合適的理由。

「那好吧，要把這個問題要刨根問底，我們需要分四篇文章來把這個問題理清楚。」，菜鳥掰著手指頭就數了出來：

• 表變數和臨時表基本概念
• 表變數和臨時表的對比
• 表變數和臨時表認知誤區
• 表變數和臨時表的選擇

點擊閱讀詳情

2. SQL Server 臨時表和表變數系列之認知誤區篇

關於臨時表和表變數，是一個老生常談的話題，但是很多SQL Server老司機都存在或多或少的認知誤區。指出一些常見的認知誤區就是寫作本文的目的。

點擊閱讀詳情

3. SQL Server 臨時表和表變數系列之選擇篇

前三篇文章，大家對臨時表和表變數的概念、對比和認知誤區已經有了非常全面的認識。其實，終極目的，是本文要討論的話題：即當面對具體的業務場景的時候，該選擇臨時表還是表變數？

點擊閱讀詳情

4. SQL Server 臨時表和表變數系列之踢館篇

在面對SQL Server選擇使用臨時表還是表變數作為數據暫存問題時，有一個非常重要的選擇標準便是性能，兩者對於查詢語句和DML性能表現到底如何呢？我相信，很多人的認識是片面的，或者是錯誤的。這裡以一篇引用率很高的文章來作為反面教材來糾正那些片面和錯誤的認識，我暫且稱之為「踢館」。

點擊閱讀詳情

雲上實踐

1. SQL Server － 最佳實踐 － SSMS配合BCP遷移SQL Server資料庫上阿里雲

本文討論的主題是使用SSMS（SQL Server Management Studio）配合BCP命令行的方式來遷移SQL Server資料庫。使用SSMS做資料庫結構遷移，使用BCP命令做全量數據遷移，此方案是以本地SQL Server資料庫遷移到阿里雲RDS SQL Server 2012為例。

點擊閱讀詳情

2. 開啟TDE的RDS SQL Server還原到本地環境

阿里雲RDS SQL Server 2008 R2版本，客戶在前端控制台可以自行啟用透明數據加密（TDE），來避免客戶資料庫備份文件被非法盜取而引起拖庫風險。最近，客戶諮詢如何將開啟了TDE的資料庫還原到本地環境，這篇文章的目的就是為了解決這個問題。

點擊閱讀詳情

3. RDS SQL SERVER 解決中文亂碼問題

這天老鳥又開始糾纏著菜鳥：「菜鳥啊，我們最近遇到一個RDS SQL Server 2008 R2的奇怪的問題，我們的生僻字寫入到RDS SQL Server中，查詢結果展示出來是亂碼呀？你去解決下這個問題吧。」。

「可是，鳥哥，我最近在做關於SQLTest的系列文章啊，暫時抽不出。。。。。。」。

「那個暫時先放放，這個比較緊急，儘快，立刻，馬上去復盤並解決掉，Understand？」。還沒等菜鳥說完，老鳥已經迫不及待的發號施令了。

點擊閱讀詳情

4. SQL Server FullText解決Like字句性能問題

這天老鳥火急火燎的衝到菜鳥座位：「還記得你在雲棲社區發表的一篇名為『SQL Server利用HashKey計算列解決寬欄位查詢的性能問題』的文章嗎？被人踢館啦，人家覺得你這個限制條件太苛刻，只能解決完全等於的問題條件下的性能問題，沒有太大的現實意義。」

菜鳥燒腦的調動大腦的每一個細胞：「哦，你說的是這篇文章啊？」。

菜鳥反思著，的確，需要完全匹配這個條件限制太嚴格了，SQL Server有沒有一種方法來代替LIKE字句的功能而又可以大大提高查詢效率的呢？因為，我們知道，LIKE左模糊匹配是可以使用到索引，而右模糊和完全模糊匹配是完全無法使用到索引的。G哥告訴菜鳥有解決方法，用FullText搜索啊。

點擊閱讀詳情

5. SQL Server使用視圖做許可權控制

這天老鳥火急火燎的跑到菜鳥旁邊，想必是遇到什麼難題了：「現在有這麼一個場景，假如有三種角色，並且存在層級關係，他們需要訪問同一個數據源表，但是需要做許可權控制，使得每種角色只能看到自己及以下層級的數據。比如：公司有CEO，Manger和普通的employee三種角色，CEO可以查看CEO、Manager和employee層級的數據；Manger只能查看Manger和employee的數據，不能查看CEO層級；而employee只能查看employee的數據，不能查看CEO和Manager級別的數據。這個在SQL Server有比較簡單清爽的實現方法嗎？」。老鳥這個問題的確問得非常有水準，這個場景也非常普遍，菜鳥頓時陷入了無邊的困境。

在關係型資料庫SQL Server中，許可權的確不能達到行列級別這麼細粒度的控制，這也是菜鳥為什麼陷入困境的原因。但是，突然菜鳥靈魂出竅，靈光一現，像是被雷劈中一般的感覺：雖然SQL Server基於表無法達到那麼細粒度的許可權控制，但是我們可以建立視圖（VIEW），用視圖來建立正式表的行、列過濾，然後在視圖對象上做許可權控制，最終達到對三個層級的許可權控制的目的，想到這裡菜鳥立馬赫然開朗。

點擊閱讀詳情

6. 巧用COLUMNS_UPDATED獲取數據變更

在平時與資料庫打交道的過程中，我們經常會有這樣的疑惑：如何快速的獲取數據變更記錄呢？舉個例子，搜索引擎要為外部客人提供快速準確的商品信息搜索功能，那麼當有新的商品數據變更後，搜索引擎如何快速的發現這些新的變更數據呢？

點擊閱讀詳情

7. SQL Server利用HashKey計算列解決寬欄位查詢的性能問題

某年某月某日，某MSSQL菜鳥滿臉愁容的跑到老鳥跟前，心灰意懶的對老鳥說「我最近遇到一個問題，很大的問題，對，非常大的問題」。老鳥不急不慢的推了推2000度超級近視眼鏡框，慢吞吞的說：「說來聽聽」。

「我有一個100萬數據量的表，有一個寬度為7500欄位，不幸的是現在我需要根據這個欄位的值來查詢表數據，而且最為可恨的是MSSQL Server不允許我在這個欄位上建立Index，所以，我的查詢語句爆慢，應用程序直接超時，腫么辦呀，腫么辦？」。

點擊閱讀詳情

8. 如何偵查SQL執行狀態

隨著菜鳥一點點的成熟，現在老鳥已經開始慢慢的將一些問題拋給他：「菜鳥，你去研究下如何有效而快捷的偵查SQL執行狀態？」。

「鳥哥，你交代的任務，我分分鐘就去辦。」，菜鳥領了任務趕緊忙碌起來。

「其實這個場景經常遇到，比如：我們想知道某個進程的SQL查詢執行到哪一步了？當前執行多久了？查詢是從哪個登錄用戶哪一個機器過來的？跑的是什麼業務？甚至執行計劃是什麼樣子？老鳥就是老鳥，總想的比我們遠」。菜鳥一邊尋思著，一邊又馬不停蹄的問G哥，終於功夫不負有心人，總算有了點眉目。

點擊閱讀詳情

9. 誰佔用了我的Buffer Pool

雙十一後，老鳥接二連三的狂轟濫炸著菜鳥：「你讀過一本叫《誰動了我的乳酪》的書嗎？正好，你研究下誰動了SQL Server的Buffer Pool吧？」。

菜鳥又是滿臉懵逼茫然狀：「這誰跟誰啊？有半毛錢關係嗎？」。沒辦法，老鳥交代的任務，菜鳥還是要一絲不苟的竭盡全力。

點擊閱讀詳情

10. sys.master_files不能準確展示Tempdb資料庫大小

老鳥這兩周一直沒有找到機會略菜鳥，因為菜鳥最近一直在參加百阿培訓。這不，剛好菜鳥過完買買買的雙十一回來，老鳥逮著機會劈頭蓋臉問道：「菜鳥啊，你去研究下為什麼MSSQL Server系統視圖sys.master_files不能準確展示Tempdb資料庫數據文件大小啊？」。

點擊閱讀詳情

11. SQL Server - 最佳實踐 - 參數嗅探問題

這篇文章從參數嗅探是什麼，如何產生，表象是什麼，會帶來哪些問題，如何解決這五個方面來探討參數嗅探的來龍去脈，期望能夠將SQL Server參數嗅探問題理清楚，道明白。

點擊閱讀詳情

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

推薦閱讀：