久久久美国精品中文字幕,回本九九久久久久久久久,真实夫妻露脸爱视频九色网

圖6-4
而反觀并行采用奇數(shù)并行數(shù)，這時當分發(fā)數(shù)據(jù)時就不會造成某個thread所持有的數(shù)據(jù)只是奇數(shù)或是偶數(shù)，也就不會造成后來的情形，死鎖也就不會出現(xiàn) 。如圖6-4感興趣的同學可以做實驗調(diào)整并行數(shù)并閱讀相應的執(zhí)行計劃。

圖6-5
至此我們應該可以明白了。
萬事皆有因果，一個簡單的BUG可以做為回應，但深究可能窺其本質(zhì)，并且很有意思。技術(shù)人需有這種精神。
優(yōu)化實踐
最后咱們再通過一個簡單的實例說下優(yōu)化實踐。
日常的OLTP環(huán)境中，有時會涉及到一些統(tǒng)計方面的SQL語句，這些語句可能消耗巨大，進而影響整體運行環(huán)境，這里我為大家介紹如何利用SQL Server中的“類MapReduce”方式，在特定的統(tǒng)計情形中不犧牲響應速度的情形下減少資源消耗。
我們可能經(jīng)常會利用開窗函數(shù)對巨大的數(shù)據(jù)集進行分組統(tǒng)計排序。比如下面的例子：
腳本環(huán)境

當我們針對bigProduct表的productid分組，并按照bigTransactionHistory的actualcost及quantity分別排序取結(jié)果集語句如下：

執(zhí)行此語句并輸出實際執(zhí)行計劃如圖7-1：

圖7-1
可以看出我的這條語句由于對大量結(jié)果集進行排序，致使消耗了365MB的內(nèi)存，并且由于分別對actualcost， quantity排序使得在進行第二個排序時內(nèi)存不足并溢出，排序的操作只能在tempdb中進行。
Sort由于是典型的計算密集型運算符，此查詢在我的機器上執(zhí)行時間為5s 。
大量的內(nèi)存被個別查詢長時間獨占，使得Buffer Pool的穩(wěn)定性下降，進而可能影響整體吞吐。
關(guān)于SQL Server的Sort限于篇幅這里就不細說了。
在介紹“類MapReduce”之前，我想先接著上面Sort溢出的現(xiàn)象給大家簡單介紹下通過Query hints 來影響優(yōu)化器的資源分配。

通過查詢可以看出由于我加了Query Hint，改變了優(yōu)化器的資源評估標準，使得優(yōu)化器認為productid本身需要資源從1001 and 3001分配變?yōu)榱?001 and 5001分配，內(nèi)存申請由365MB變?yōu)榱?85MB，接近一倍的增長，避免了溢出。并且執(zhí)行時間也由5S變?yōu)榱?S，提升了用戶體驗。
如圖7-2：

圖7-2
可以看到溢出與不溢出在查詢消耗時間上差別很大，但這樣就是好了嗎?其實未必，畢竟即便在非溢出的情形中將近700MB的內(nèi)存近2s內(nèi)被這個查詢占用，這在高并發(fā)的OLTP環(huán)境中是傷全局的。那更理想的解決方式呢?
在并行執(zhí)行計劃中是多個線程(CPU核)協(xié)同工作，這里面的Sort面對大量數(shù)據(jù)結(jié)果集時即便多核同時進行，在復雜的預算面前也是有些力不從心。在分布式的思想中，講究分而治之，我們只要將大的結(jié)果集化為多個小的部分并多核同時進行排序，這樣就達到了分而治之的效果。也就是前面說的“MapReduce” 。