策劃｜Gary
作者｜何愷鐸
美國時間 2017 年 10 月 2 日，微軟最新一代數據庫 SQL Server 2017 正式發布。SQL Server 2017 帶來了一系列全新的功能與設計，體現了微軟在數據平臺建設方面的最新思考和實踐。InfoQ 特邀國雙科技高級技術總監何愷鐸撰文對 SQL Server 2017 進行深入探討和解析，以饗各位讀者。
寫在前面
數十年來，關系型數據庫一直是結構化數據存儲的不二之選。從高校到工業界，關系型數據庫向來是數據研究和應用的核心，也促生了大批從事數據庫開發、維護和調優的人才。近年來隨著各種 NoSQL 數據庫和 Hadoop 技術生態的誕生和流行，RDBMS 似乎受到了巨大的挑戰，有著“嚴謹呆板”形象的關系型數據庫一度被市場唱衰。然而事實證明，即便面對著眾多后起之秀的競爭，有著悠久歷史的關系型數據庫不但沒有消亡，反而歷久彌堅，不斷推陳出新，在現代后端數據架構中仍然占據核心地位，散發出十足活力。
微軟 SQL Server 數據庫，是商業關系型數據庫陣營中的杰出代表，在 DB-Engines 數據庫流行度排行榜上常年位居前三。得益于便捷的圖形化管理界面和易于上手的特點，許多人的關系型數據庫之旅，就是從 SQL Server 開始的。如今正值 SQL Server 2017 發布之際，我們不妨一起來看看 SQL Server 的前世今生，探究微軟數據平臺發展之路。
微軟 SQL Server 自身的歷史具有傳奇色彩，最初是由微軟、Sybase、Ashton-Tate（開發 dBase 的公司）三家合作，將 Sybase SQL Server 數據庫移植到 OS/2 操作系統而誕生的。后來隨著 OS/2 的挫敗和 Windows NT 操作系統的走強，微軟停止了與 Sybase 的合作，開始聚焦于為 Windows 平臺獨立地開發和維護這個數據庫產品，此即 Microsoft SQL Server 的由來。為了避免混淆，Sybase 也將自己的數據庫從 Sybase SQL Server 重命名為了 Adaptive Server Enterprise(ASE)，從此 SQL Server 僅指微軟旗下關系型數據庫了。說起來 Sybase 的數據庫產品也一度在金融等行業享有盛譽、頗受歡迎，但如今早已風光不再，于 2010 年被 SAP 收購，令人唏噓。
與 Sybase 分道揚鑣之后的 Microsoft SQL Server，倒是穩扎穩打，一路前行。SQL Server 7.0 和 SQL Server 2000 這兩個版本基本完成了在原有 Sybase 代碼基礎上的大量重寫和擴展，正式進入企業級數據庫的行列；而 SQL Server 2005 則真正走向了成熟，與 Oracle、IBM DB2 形成了商業數據庫的三足鼎立之勢。之后 SQL Server 歷經 2008、2008 R2、2012、2014、2016 各版本的持續投入和不斷進化，直至 2017 年 10 月 2 日正式發布了最新版本 SQL Server 2017，也即本文的主角。
近年回顧
在著手分析 SQL Server 2017 新特性之前，我們不妨先來看看 SQL Server 近些年的著力點，一窺其發展思路。
著力點之一，在于 OLAP。傳統關系型數據庫一般以行為基本的處理和存儲單位，以便于數據記錄的增刪改查。但面對日益增長的數據分析和聚合類查詢，基于行的存儲和處理就顯得有些笨拙和低效了。為此，在以 Denali 為代號的 SQL Server 2012 中，微軟引入了一個全新的 xVelocity 列式存儲與分析引擎，使得 SQL Server 擁有了一個高質量的列式存儲實現，以及一個為矢量化和批處理高度優化的查詢執行引擎。從此面向 OLAP 負載的數據表可以選擇建立基于列存儲的非聚集索引（Non Clustered Column Store Index），大幅提升了分析類查詢性能。在后續的 SQL Server 版本中，列存儲相關特性不斷得到進一步的增強和完善，不但引入了列存儲聚集索引（Clustered Column Store Index）使數據表能夠完全僅以列式存儲，還通過 Delta-Store 機制實現了列存儲表的數據更新支持，進一步拓寬了應用場景，增強了易用性。
筆者還清晰記得多年前在自己的 Thinkpad T410 上首次嘗試 SQL Server 2012 的列存儲索引時帶來的震撼，針對近億行數據的分析查詢在普通筆記本上也做到了數秒內的返回結果，令人印象深刻。歷經多年的打磨之后，可以說微軟的列存儲實現已經成為世界范圍內最高效最可靠的列存儲設計之一。 相關技術微軟甚至還作了一定程度的對外輸出：通過與 HortonWorks 合作，微軟向開源世界的 Apache Hive 項目貢獻了不少代碼（被稱為 Stinger 項目，[注 1]），幫助 Hive 提速，其思想精髓也正來自于 SQL Server 的 xVelocity 列式存儲和分析引擎。
著力點之二，在于 OLTP。傳統關系型數據庫其實本就擅長 OLTP，那么可改進的點在哪里呢？計算機發展的歷史進程所帶來的一個問題是，經典的數據庫存儲機制大都針對磁盤結構進行設計和優化，原本昂貴的內存資源更多充當的是緩存的角色。而隨著硬件技術不斷發展，服務器內存不斷增大后，許多場景下數據的存儲和索引其實都可以完全納入內存中了——這就為基于內存的數據庫引擎提供了條件。當一個數據庫引擎及其存儲完全為內存優化和設計后，其性能的增幅將是非常驚人的。微軟數年前在這一領域進行了大舉投入，代號為 Hekaton 的內存數據庫技術最早在 2012 年底對外進行了公布[注 2]，后隨 SQL Server 2014 正式發布。配合其無鎖的并發模型及用 SQL 撰寫的本機編譯存儲過程（Natively Compiled Stored Procedure），相比傳統方案，Hekaton 往往能夠達到多達數十倍的性能提升，完全地改變了許多系統的設計思路，實現了之前難以企及的高負荷場景支撐。
可以看到，截止到 SQL Server 2016 版本，這款微軟的拳頭產品已經非常強大和完整，能夠在單個產品內提供 OLAP 和 OLTP 負載的完美融合。那么僅過了短短一年時間，最新的 SQL Server 2017 還能帶來哪些新的驚喜？我們來一看究竟。
新特性之跨平臺與容器化
SQL Server 2017 第一個不得不提的變化，不是一個具體功能，而是其運行環境的變革：支持 Linux 服務器。這是微軟 SQL Server 系列產品首次正式地得以在 Linux 上運行，并且提供完整的官方支持。這無疑大大拓寬了 SQL Server 的應用場景和客戶群體。要知道，雖然 Windows Server 的授權并不算昂貴，但對于許多以 Linux 生態為主要技術棧的公司而言，并不會考慮申購和運維基于 Windows 的后端服務器——因此在技術選型時，SQL Server 可能第一時間就被排除在外了。當 SQL Server 2017 正式支持 Linux 后，這一障礙將不復存在，SQL Server 終于可以在新的戰場和競爭對手開展競爭，這無疑會非常有助于其市場份額的提升。
當然，看上去深度耦合于 Windows 的 SQL Server 想要完美地運行于 Linux 上，實現起來絕非一件容易的事情。這是怎樣做到的呢？這里有兩個關鍵因素：
其一是 SQL Server 原本就有稱為 SQL OS 的底層基礎設施，該組件可繞過操作系統和 Win32 API 的限制，直接自行管理和組織 CPU、內存等計算和存儲資源，以及進行適合自己的線程調度，以便充分利用底層硬件性能；
其二是來自微軟研究院的 DrawBridge 項目，該項目原用于實現應用沙盒機制，它的 Library OS 組件依靠僅約 50 個底層內核調用實現了一千多個常用的 Windows API，同時還具備為其他組件如 MSXML 和 CLR 等提供宿主的能力。
SQL Server 團隊基于這兩個已有基礎進行了偉大的嘗試，將二者進行了必要的重寫和充分的融合，形成了新一代的底層封裝 SQLPAL(SQL Platform Abstraction Layer)，同時將上層邏輯代碼都移植到了 SQLPAL 之上——這是 SQL Server 得以在短時間內實現跨平臺的關鍵所在。與此同時，SQLPAL 這種特殊的抽象機制，并沒有付出通常意義上抽象所帶來的性能代價，因為它一定程度地繞過了操作系統的制約，自底向上地搭建了自身所需的運行環境。
SQL Server on Linux 實現原理[注 3]
前面回顧歷史時我們提到，SQL Server 在 90 年代努力地獨立與成長，戰略性地聚焦在了 Windows 平臺。而 20 多年后，SQL Server 如今跨出擁抱 Linux 的關鍵一步，同樣是一種戰略的調整。歷史看似循環往復，其實都是不同時代不同環境下的最佳商業選擇。
為了給 SQL Server on Linux 保駕護航，微軟還和 Red Hat 等老牌 Linux 提供商達成了合作[注 4]，一起為客戶提供整合解決方案，以確保操作系統層面的可靠性及與 SQL Server 的兼容性。目前 SQL Server 能夠被安裝到 Red Hat Enterprise Linux、SUSE Linux Enterprise Server 及 Ubuntu 之上。伴隨著 Linux 支持一起到來的，還有對于容器的支持。SQL Server 2017 現能完美地通過 Docker 運行，微軟也已在 Docker Hub 上發布了基于 SQL Server on Linux 的官方 SQL Server 鏡像[注 5]（微軟同時還提供了面向 Windows 容器的版本）。SQL Server 容器化的主要意義在于支持 DevOps。在以往，想要讓 SQL Server 這樣一個重型數據庫實例按需地、自動地啟動或關閉是比較困難的，一般都需要事先安裝準備好相關的數據庫環境；而如今，借助容器和鏡像，我們可以非常方便地通過 Docker 來輕量化地啟停 SQL Server，通過腳本與 DevOps 流程進行集成也變得很容易。
筆者曾經在自己的一個開源類庫[注 6]中做過這樣的嘗試，將原有的依賴于 SQL Server LocalDB 的一系列集成測試遷移到了新的 SQL Server 容器上，順利解除了本地測試運行環境必須安裝 SQL Server 的依賴，也為在遠端 CI 環境中運行測試掃清了障礙。當然，除了 DevOps 方面的應用，也可以嘗試在生產環境直接使用容器化的 SQL Server，以便使數據庫也統一納入生產環境容器編排的范疇。限于篇幅，此處不再展開。
如上所述，SQL Server 2017 已從原來固守 Windows 的策略，大步地轉向了支持 Linux、Docker 容器和 Windows 三大平臺。這一決策無疑將對 SQL Server 乃至數據庫市場產生深遠影響。
新特性之圖數據處理
向新興的 NoSQL 學習也是現代關系型數據庫發展的一個重要特征。如文檔型數據庫善于處理的 JSON 數據，在 SQL Server 2016 中也成為了一等公民，得到了存儲、索引、查詢等方面的全面支持。而在 SQL Server 2017 中，這位數據庫老前輩與時俱進，又開始向 Neo4j 這樣的后起之秀學習，大膽地引入了圖數據的處理與支持[注 7]。
眾所周知，圖數據庫的核心實體是節點和邊，通常都擁有一些屬性，然后節點通過邊進行相互關聯。在傳統關系型數據庫中，對圖進行建模其實并不困難，可以通過為節點和邊分別建表并通過外鍵關聯的方式來完整表達圖的信息。然而，主要的問題在于查詢和查詢的性能：一些典型的圖查詢的表達在傳統關系型數據庫中顯得笨拙而困難，尤其當需要在圖的節點間進行多次跳躍（multi-hop）時，SQL 的撰寫比較容易出錯，查詢性能也不能得到保證。
SQL Server 2017 中的圖數據庫特性試圖解決這兩個問題，它仍然以表的形式來對圖信息進行建模和存儲，但加上了額外的擴展，大幅提升了易用性。在創建表時，現可通過 T-SQL 的擴展語法來指定此表是圖數據庫中的節點表 (AS NODE) 或邊表 (AS EDGE)，隨后 SQL Server 會隱式地為表加上 $node_id 或是 $edge_id、$from_id、$to_id 等字段，以幫助記錄節點和節點間的關系；在查詢時，SQL Server 2017 一定程度借鑒了 Neo4j 中 Cypher 查詢語言的部分語法，通過引入 MATCH 關鍵詞來幫助用戶以 ASCII-art 的方式表達有向圖中的節點巡游，同時完美地融合進現有的 SQL 查詢體系。我們不妨來看一個官方的查詢樣例：
可以看到，上述 T-SQL 片段能夠很方便地表達出“John 的朋友喜愛的餐館”這個包含兩種不同連接類型的“二跳式”查詢，并且用 ACSII 字符表達的箭頭也很好地體現了邊的方向性。若與相同語義的傳統 SQL 寫法相比，這樣的表達方式無疑清晰、直觀得多。
圖數據庫特性在 SQL Server 2017 中已初露崢嶸。當然，由于此特性是首次引入，客觀上來講并沒有到達完全成熟的程度。例如，不支持 transitive closure（節點間不限跳躍次數的連通性判斷）和 polymorphism（查詢某節點所能到達的不同類型的節點）等圖數據庫常用的高級查詢。在性能方面，SQL Server 目前主要利用的也僅是二維表的既有索引和查詢優化器所作的表連接優化，尚沒有引入為圖優化的專用數據結構。期待后續的版本升級和更新會在這些方向上做進一步的增強。
新特性之數據庫內機器學習
機器學習無疑是近年來的熱詞，也是現代數據應用不可或缺的組成部分。微軟雖然在此領域擁有雄厚的研究實力和成果，但在構建相關開發生態上卻顯得動作緩慢。早年的 SQL Server Analysis Service 雖然也內置了數據挖掘功能，但因過于笨重及程序集成困難等問題，使用場景非常受限。直到近年，微軟才開始逐漸發力：在 2015 年初，微軟果斷地將 Revolution Analytics 收入囊中[注 8]。此次收購至關重要，它為微軟帶來了面向 R 語言生態的全面的開源和商業解決方案，覆蓋了龐大的 R 語言社區和數據科學家人群。
那么作為經典的關系數據庫，SQL Server 如何應對和適應這個新趨勢呢？受益于 Revolution Analytics 的收購，SQL Server 2016 版本帶來了突破性的 SQL Server R Services[注 9]：能夠讓 R 語言及其生態直接作為一個服務在 SQL Server 環境內部運行。而在 SQL Server 2017 中，更進一步加入了另一個擁有強大 AI 生態的語言支持：Python。原有的 R Services 也與新引入的 Python 服務一起重命名為 Machine Learning Services。
Machine Learning Services 的核心產品思路，是在數據庫內直接運行機器學習負載，它允許大家熟悉的 Python/R 腳本與眾多機器學習類庫在數據庫服務器上運行，并無縫地與 SQL 銜接。這樣的設計理念，與傳統的數據庫外獨立的機器學習相比有何好處呢？在筆者看來，其核心優勢正在于“集成”二字，可從幾個方面來理解：
一是便捷的數據集成，即無需進行復雜的數據移動和準備就可以使用 SQL 訪問到各類業務數據，并提供給 Python/R 的各類 AI 算法作為輸入；二是高效的模型集成，即訓練完成后的模型可以使用 SQL Server 進行管理和存儲，模型使用時也可輕易地通過存儲過程進行調用并獲取結果，SQL Server 會自動幫助你完成執行引擎和 Python/R 運行環境間的高效數據傳輸和序列化；三是無痛的應用集成，即應用可以通過傳統的數據庫連接和存儲過程返回值的方式來獲得機器學習能力，無需復雜的儀式和專用的架構，一切就和傳統的數據庫訪問一致。
當然，客觀地說數據庫內機器學習的設計也有其技術局限，主要體現在可伸縮性方面：由于模型訓練時需要較大的計算資源消耗，因此單機服務器可能成為潛在的瓶頸。雖然 SQL Server 中可以使用性能超越開源 R 實現的 ScaleR/ScalePy/MicrosoftML 等支持多線程和 GPU 加速的商業級類庫，但可能仍不適合數據量大到需要動用大規模集群進行訓練的場合。此外，也有人對數據庫內集成 Python/R 腳本的開發、測試和運維成本表示疑慮。這些也是微軟后續會考慮增強的地方，R Tools for Visual Studio 在這方面已經作出了一些努力。
對比同類解決方案，SQL Server Machine Learning Services 有其獨特的優勢。數據庫內機器學習的理念讓擁抱 AI 變得更簡單而直接，也意味著更低的研發成本和更早的上線時間。它尤其適合現有基于 SQL Server 的企業應用進行機器學習方面的嘗試和升級。讓我們期待更多的實際案例的誕生，也期待它的進一步完善。
新特性之自適應查詢處理
如果說數據庫內機器學習給開發者應用帶來了智能，那么 SQL Server 的查詢執行引擎本身是否也能變得更聰明更智能呢？答案是肯定的，這也正是 SQL Server 2017 的另一個發展方向，相關的一系列特性被稱為自適應查詢處理（Adaptive Query Processing）。
SQL 查詢高效執行的關鍵在于制定合理的執行計劃。一般來說，執行計劃的生成發生在查詢執行之前，是執行引擎基于統計信息和索引狀態等元數據信息，結合執行步驟和中間結果集的量級預估而綜合得出的。同時執行計劃通常會進行緩存，以便相同形式的查詢可以復用查詢計劃，以提高綜合查詢性能——這一切看上去很美好，不是么？然而在實際環境中，上述的精妙機制也會遇到種種挑戰和棘手問題。例如，參數化的查詢常常對參數輸入較為“敏感”，不同的參數會導致數據結果量級波動很大，難以事先預估和選擇最優的查詢計劃；又如統計信息未及時更新導致中間結果集規模預估失誤而選擇了錯誤的計劃；再如使用 hint 解決短期問題，導致長期來看效果適得其反等等。
為了緩解上述的種種痛點，勢必要引入執行時智能和自我調優，對此 SQL Server 2017 的自適應查詢處理作了有益的探索和落地。其核心思路在于，一定程度地延后完整的執行計劃生成的時間，等待部分實際輸入集合到位后再做下游執行方式的策略選擇。例如，新引入的自適應 join 運算符可以基于上游數據輸入的精準量級動態地選擇聯接策略是應當使用 nested loop 還是 hash join；又如多語句表值函數 (MSTVF) 不再使用固定的量級預估，而是可以先執行函數再制定下游執行計劃的方式來確保獲得更優的執行效率。這些新特性，有 DBA 給出了“能夠避免我上周一半的查詢性能調優工作” [注 10]的高度評價。
除了執行時的計劃延遲生成，數據庫系統還可以從已經執行完成的查詢中獲得反饋，以便后續的同形態查詢獲得更合適的查詢計劃，這是超越簡單的執行計劃緩存的更高級形式。在這個方面，SQL Server 2017 實現了批處理模式下的內存分配反饋（memory grant feedback）功能， 可幫助后續查詢從之前查詢的內存分配實踐中吸取“經驗教訓”，實現內存資源的準確估計和分配。
可以看到，SQL Server 2017 已通過自適應查詢處理在執行智能方面開始發力，實現了一系列場景下的自動適應和優化，同時做到了對開發者透明。目前其局限性主要在于不少上述特性僅適用于批處理模式（見于針對列存儲的查詢），而不適用于傳統的行式處理模式。相信微軟今后會在此領域加入更多對行處理模式的支持，進一步拓展自適應查詢處理的適用場景。
SQL Server 與大數據
在大數據時代，以 Hadoop 為代表的分布式數據處理計算框架層出不窮，取得了空前的生態繁榮；而以 Hive、Impala、Presto 等為代表的 SQL on Hadoop 解決方案更是對傳統數據庫發起了強而有力的沖擊。在這樣的時代背景下，關系型數據庫的確略顯尷尬。那么，SQL Server 是如何應對和擁抱“大數據”浪潮的呢？
應對之一，是強化 SQL Server 自身的數據存儲和處理能力，拓展應用場景，即”SQL Server 也能處理大數據”。得益于服務器硬件技術的不斷發展，單服務器容量和處理能力不斷提高，配合優秀的分區機制和列存儲壓縮，SQL Server 事實上已經能夠處理相當大體量的數據。去年微軟和英特爾曾合作進行了一個有趣的實驗，使用一臺單機 SQL Server 服務器承載了多達 100TB 的數據，并進行了詳細的測試，其綜合性能表現令人驚喜[注 11]。百 TB 的量級，其實已經能夠滿足不少存儲和計算“大數據”的需要了。在很多場景下，與有著 over-engineering 之嫌的 Hadoop 集群方案相比，SQL Server 更易于管理和維護，架構穩定簡單，反倒是綜合成本更低的選擇。
當然，若是面對 PB 級別以上的數據，單服務器仍會捉襟見肘。針對這樣的數據量級，微軟有一個被稱為 SQL Server Parallel Data Warehouse（簡稱 PDW）的產品解決方案，可以理解為 SQL Server 的一個分布式變體，是基于 SQL Server 核心構建的一個 MPP 分析型數據庫。PDW 通常以與硬件廠商合作的方式進行軟硬件一體化售賣，能夠輕松支持 PB 規模的數據存儲與分析。
應對之二，自然是與大數據開源解決方案的充分共通與融合，尤其是大數據的事實標準：Hadoop。這里的主角，是微軟在 SQL Server 2012 PDW 中開始正式引入的 PolyBase 技術?，F在它不再是 PDW 版本所獨有，已成為了標準 SQL Server 和 Hadoop 間的重要橋梁。PolyBase 的核心能力，是允許在 SQL Server 上下文環境中定義面向 Hadoop 的外部表，并面向外部表執行 SQL——這一設計思路和 Hive 的外部表以及 PostgreSQL 的 FDW 擴展非常類似?；谶@樣的核心能力，就能夠很容易地實現將大量數據從 Hadoop 導入 SQL Server，也可以反向將 SQL Server 數據導出至大數據集群。若和 Sqoop 這樣單純的數據移動方案相比，PolyBase 一方面擁有更好的性能（基于直接 HDFS 訪問而非 MapReduce），另一方面受益于外部表的抽象，能夠在外部 Hadoop 數據不落地的情況下和本地數據庫表進行聯合查詢。
由上可見，面對風起云涌的大數據浪潮，微軟沒有固步自封。在強化自身能力的同時，SQL Server 也選擇了和大數據生態和諧共存，互相融合。
SQL Server 與云計算
如今的云計算發展如火如荼，因此擁抱和支持云也是每一個數據庫產品都需要做好的功課。在這個方面，SQL Server 稱得上是成績出色的優等生，是微軟云計算戰略的重要組成部分。
作為擁抱云的第一步，微軟毫無懸念地將 SQL Server 以 PaaS 服務的形式提供了出來。這一服務其實早在 2010 年就已經發布，當時命名為 SQL Azure，后改稱 Azure SQL Database。對傳統商業數據庫而言，通常采購和安裝的流程較為冗長，開發者即便有興趣，也有比較高昂的嘗試成本——Azure SQL Database 的出現徹底改變了這一點，只需在 Azure 門戶中輕輕點擊，一個托管的數據庫實例就整裝待發了。這一商業模式上的改變，無疑大大降低了微軟數據庫的使用門檻，拓展了使用場景。
從技術上來說，Azure SQL Database 絕非通過虛擬機提供 SQL Server 服務那么簡單，它是基于 SQL Server 的能力完全為云端環境設計的 PaaS 產品——它不但擁有豐富的 SQL Server 特性，與 SQL Server 的功能升級同步，而且具有良好的彈性伸縮特點。Azure SQL Database 使用 Data Transaction Unit (DTU) 的概念來描述 SQL Database 實例的性能級別。用戶可以隨時地按需調整數據庫實例 DTU 的大小，以達到不同時間段下工作負載和性能級別的匹配，有效地節省成本。此外，Azure SQL Database 還支持彈性池（elastic pool）特性，允許一組數據庫實例共享一個資源池，特別適合于多租戶的 SaaS 類應用程序。
在微軟 2015 年 Build 大會上發布的 Azure SQL Data Warehouse，則是 SQL Server 在云端的另一位表親。它本質上是前面提到的 SQL Server PDW 的云端版，是可用于大規模數據計算與分析的分布式數據倉庫。SQL Data Warehouse 的核心技術，除分布式調度之外，正是運行在 SSD 存儲之上的列存儲索引。相對主要競品 AWS RedShift 而言，Azure SQL Data Warehouse 受益于 Azure 存儲與計算分離的理念，不但可以動態調節計算能力，甚至可以“關機”，即暫時關閉計算能力而僅保留存儲——這在許多數據倉庫場景中是可以節省大量成本的殺手級特性，也成為了許多客戶選擇 Azure 的原因。
當然，有時仍然需要 SQL Server 以 VM 的形式在 Azure 上運行，以突破一些 PaaS 形式云數據庫的限制，如使用 SQL Agent 或需要在 VM 上安裝其他配套軟件等。針對這種情形 Azure 也提供了便捷的 SQL Server 虛擬機，開箱即用，數據庫的許可證費用也會按照使用時間進行計算。
作為擁抱云計算的另一種形式，SQL Server 也非常重視云端互操作能力，將云作為自己的擴展，以及融入云端數據平臺體系。首先，從 2016 版本起，SQL Server 就開始支持使用云作為數據庫的外延，通過 Stretch Database 功能可以讓本地數據庫中的冷數據自動無縫地上傳到 Azure 云中，同時前端查詢不需要做任何的調整。其次，SQL Server 也能夠通過不斷增強的 PolyBase 技術順暢地融入云端的大數據解決方案，如微軟自家的 Azure Data Lake 或是 Hortonworks 提供支持的基于 HDP 的 HDInsight。
前景與展望
如今的 SQL Server 風華正茂，早已不是當年那個被認為“只適合中小企業”的年輕后輩。通過拿下納斯達克、NTT DoCoMo 等大型標桿客戶，SQL Server 正在全面出擊、攻城掠地，已不懼怕任何競爭對手。Gartner 近年的魔力象限報告也可以印證這一點：微軟已在操作型數據庫、分析型數據管理解決方案和商業智能等多個領域都處于領導者象限。
Gartner 操作型數據庫 (ODBMS) 魔力象限圖[注 12]
距離 SQL Server 2016 短短一年，SQL Server 2017 就全新發布了，微軟明顯加快了更新的節奏。支持 Linux 的 SQL Server 2017 完全有理由百尺竿頭，更進一步。這是技術平臺的選擇，更是商業策略的創新。脫離 Windows 捆綁之后的 SQL Server 即將闖蕩一片新的廣闊市場。
從使用場景角度來看，如上述介紹，SQL Server 現既可以從容應對高頻 OLTP 負載，也可以作為面向 OLAP 的數據倉庫，還可以打造為基于內存的實時數據處理組件，或是用作應用智能的驅動引擎——SQL Server 已經變得非?！叭堋?。
另外值得一提的是，相比 Oracle、SAP 等競爭對手的細分產品策略和琳瑯滿目的產品列表，微軟選擇了“簡單、集成”的設計哲學和商業模式。一個 SQL Server Enterprise Edition 就囊括了競品中可能需要分別單獨購買的列存儲、內存數據庫等功能，商務層面更加便捷的同時，也簡化了系統架構。從版本策略的角度，微軟也進行了聰明的調整，將大多數的重要功能下放到了 Standard Edition 和 Express Edition 中，轉而主要通過數據量級來劃分版本，以便高級功能觸達更多的潛在客戶。此外，微軟還特意推出了可免費下載安裝的 Developer Edition，除了不能用于生產環境之外，在功能與數據量級上與最高級的 Enterprise Edition 完全一致，沒有任何限制，大大降低了開發者們體驗和嘗試各項企業級功能的門檻。
一個繞不開的話題，也許是同 MySQL、PostgreSQL 等開源關系型數據庫以及各種 SQL on Hadoop 數據庫的比較。客觀地說，開源浪潮的確對商業數據庫產生了巨大的沖擊，出于直接成本的原因，以互聯網行業為代表的諸多企業紛紛采用了開源方案。然而，隨著多年來大家對開源體系與運作模式的理解不斷加深，尤其是積累了大量的實踐經驗之后，市場逐漸趨于理性，開始更客觀地看待開源模式的利弊和適用場景。天下畢竟沒有免費的午餐，當企業的核心業務高負荷地運行在開源軟件之上時，恐怕一樣需要購買并不便宜的商業 support 服務，或是雇傭大量高級人才來了解和掌控底層的源碼級細節。所以，不少企業會寧愿直接選擇性能更佳、穩定性更高、企業級特性更豐富的商業數據庫——因為對于這些企業來說，選擇 SQL Server 具有更低的總體擁有成本。
從開發環境與工具生態上來看，SQL Server 同樣具有深厚的積累。向來口碑頗佳的 SQL Server Management Studio 一直是微軟持續投入的數據庫綜合管理工具，為 SQL Server 帶來了強大而易用的圖形化管理界面，可以免費下載使用；在各版本的 Visual Studio 中，也可以通過 VS 內置的 Server Explorer 連接和查詢 SQL Server，與開發過程緊密聯動——這些充分體現了微軟大廠所能夠帶來的整合優勢。另外值得一提的是，在編程語言支持方面，除了自家的 C#/.NET，SQL Server 團隊近年來明顯加大了對于其他流行語言支持的力度，尤其是 Java 和 PHP，為這些語言和平臺帶來了高質量的客戶端類庫支持。
最后，說說 SQL Server 之于中國市場。其實在國內，得益于在教育領域的耕耘和出色的產品易用性，SQL Server 一直有著比較好的群眾基礎和親和形象。但若要在中國的高端市場打開局面，還需要進一步塑造品牌，打造標桿案例，消除之前給部分人群留下的“適用于中小企業”的陳舊印象。要做到這一點，除產品本身需不斷提升以滿足大客戶苛刻需要外，還必須重視本地技術社區的建設，并幫助從業人員獲得良好的職業發展，形成良性循環。另外，隨著 Azure 云在中國的落地和發力，SQL Server 家族也大可借公有云發展之勢進行推廣，分享增長紅利。
寫在最后
關系型數據庫源遠流長，在許多場景下仍具有不可替代的重要地位。SQL Server 作為關系型數據庫中的翹楚，一路走高，不斷煥發著生機與活力。SQL Server 2017 的發布，有助于微軟進一步鞏固其市場地位，并通過支持 Linux 這一殺手锏，向新的市場發起有力沖擊。
其實 SQL Server 特性之多，一文遠不能窮盡。限于篇幅，我們沒有提及 AlwaysOn、AlwaysEncrypted 等企業級特性，也沒有詳細介紹 SQL Server Integration Service、Analysis Service、Reporting Service 等商業智能套件。但通過本文上述的分析，我們已清晰地了解了這個投入巨資的商業關系數據庫在新時代的大致輪廓與發展策略。如果用八個字來概括的話，“兼收并蓄，開放外聯”當是最好的詮釋。
那么，最后的問題來了：無論身處傳統行業還是消費互聯網，無論基于 Linux 還是 Windows 平臺，你的下一個關鍵應用，會選擇 SQL Server 嗎？
何愷鐸，國雙科技 (Nasdaq:GSUM) 高級技術總監。畢業于清華大學，曾供職于摩根士丹利基礎架構部門，2011 年加入國雙科技工作至今。數年來參與架構和設計了國雙多個面向數字營銷和社交聆聽的大數據解決方案。個人關注的技術領域包括.Net 生態系統、云計算、大數據技術棧等，曾撰寫發表本文姊妹篇《從 Visual Studio 2017 談起，解析微軟技術生態進化之道》。
C語言 使用freetds連接sql server讀取,win下可用, linux下也可以,.
以下是源碼，使用sql server的master數據庫來測試。讀取，
Win下編譯器是TDM-GCC-64,: gcc version 10.3.0 (tdm64-1)
Linux下是gcc:: gcc version 6.3.0 20170516
-----------------------------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <wchar.h>
#include <locale.h>
#include<sybfront.h>
#include<sybdb.h>
void shuju()
{
// 編碼
//setlocale(LC_ALL, "");
//win下的cmd要執行chcp 65001, 到utf8的編碼下顯示才正常
char aaa[50]= "test start ...";
printf("=> %s \t\n",aaa);
char szName[32] = "sa";
char szPwd[32] = "123456789";
char szDBName[32] = "master"; // master 數據庫
char szServer[32] = "192.168.0.9:1433";
char bianma[32] = "utf8";
//初始化db-library
DBINT result_code;
dbinit();
//
LOGINREC *loginrec = dblogin();
DBSETLUSER(loginrec, szName);
DBSETLPWD(loginrec, szPwd);
DBSETLCHARSET(loginrec, bianma);
DBPROCESS *dbprocess = dbopen(loginrec, szServer);
if(dbprocess == FAIL) //如果連接失敗
{
fprintf(stderr, "Connect Fail\n"); //在標準錯誤中輸出信息
exit(EXIT_FAILURE); //進程異常退出
}else{ //如果連接成功
printf("Connect success\n");
}
if(dbuse(dbprocess, szDBName) == FAIL) //使用某個數據庫，如果使用失敗
{
dbclose(dbprocess); //關閉數據庫連接句柄, 并且回收相關資源
exit(EXIT_FAILURE); //進程異常退出
}
//開始進行數據庫中數據查詢的工作------------------
char mssqlbuf[1024]; //定義保存數據庫查詢語句的字符串
memset(mssqlbuf, 0x00, sizeof(mssqlbuf)); //開始初始化字符串
sprintf(mssqlbuf, "select name,dbid from [sysdatabases] order by [name]"); //組裝操作sql的語句, 將sql語句保存到mssqlbuf
dbcmd(dbprocess, mssqlbuf); //將剛剛組裝好的sql命令, 使用dbcmd命令保存到數據庫連接句柄的緩存中
if(dbsqlexec(dbprocess) == FAIL) //如果執行的命令失敗
{
dbclose(dbprocess); //關閉數據庫操作進程
exit(EXIT_FAILURE); //程序異常退出
}
char UserName[80]; //定義兩個變量來保存綁定出來的數據 ????
char CardNo[16];
memset(UserName,'>memset(UserName,'\0',sizeof(UserName));<',sizeof(UserName));
memset(CardNo,'>memset(CardNo,'\0',sizeof(CardNo));<',sizeof(CardNo));
//char strx[] = "";
//char *strx;
char query[4096]={};
while ((result_code = dbresults(dbprocess)) != NO_MORE_RESULTS){
if (result_code == SUCCEED){
dbbind(dbprocess, 1, STRINGBIND, 0, (BYTE*)UserName);
dbbind(dbprocess, 2, CHARBIND, (DBINT)0, (BYTE*)CardNo);
int k=1;
while (dbnextrow(dbprocess) != NO_MORE_ROWS){
char shustr[100]="";
sprintf(shustr,"%d\tname: %s\t no: %s\n",k,UserName,CardNo);
k=k+1;
strcat(query,shustr);
}
printf("%s\n ok \n",query);
// printf("%s",strx);
}
}
dbclose(dbprocess);
}
int main(void)
{
shuju();
//return 0;
}
// linux: 手動編譯freetds , 就要在編譯時指向freetds安裝路徑
// linux編譯: gcc -o cmssqlmaster cmssql-master.c -lsybdb -I /usr/local/freetds/include -L /usr/local/freetds/lib
// linux: 如果是apt-get install freetds-dev 安裝的，編譯時就不用上邊那行那樣加參數： gcc -o cmssqlmaster cmssql-master.c -lsybdb
// win下用的freedts 去這里下載, https://github.com/ramiro/freetds/releases/tag/v0.95.95
// win下cmd終端運行輸出中文亂碼解決：在cmd狀態下輸入 chcp 65001 , utf8字符串，在終端的顯示
// win 編譯: gcc -o cmssqlmaster cmssql-master.c -lsybdb -L "D:\Proj-C\freetds-win64-vs2015\lib-nossl" -I "D:\Proj-C\freetds-win64-vs2015\include"
-----------------------------
最初這個程序連接mssql測試的例子網上很多源碼，都是使用freetds的，后來想在Windows下使用，網上都C語言版本的都是使用odbc的，但測試了很久，中文亂碼部分始終不完全解決，最終發現原來freetds有win版本的，實踐后，上述源碼編譯都可以通過.。