有程式設計師跑來說我們的群組最近好像有些卡。看看記憶體
cpu都還算正常，
io也沒有比平時高多少。
總體上沒什麼問題，接下來看看細的。於是用
profiler
抓了一把
duration超過1
秒的儲存過程，抓了
20來分鐘，竟然乙個都沒有。好傢伙，看樣子在我們平日的精心呵護下，那些儲存過程跑得還算可以的嘛，卡的主要原因應該不是
db這塊的事情啦，自我滿足一下先。
再一想，群組帖子內容多，平日裡讀取還是蠻厲害的，既然叫我查了，總得找點優化的東東不。於是又抓了一把
reads
比較大的，不到一會馬上乙個可疑的儲存過程出現了：「
***getpostbytag
」，reads
有些時候超過
10多萬，而且很頻繁。看樣子得看看他了
!開啟過程定義，看到裡面的語句其實很簡單，看了下實際的執行計畫，主要的開銷就是下面的這個語句。為了介紹方便，這裡省去其他邏輯，把變數替換為開銷比較大的乙個值，只寫出最主要的語句。
select
top 9 plateforum
.title
,tag
,idx
asfidx
,groupidx
from
plateforum
with
(nolock
)where
contains
(tag,'
朋友')and
state
<>2
order
bynewid()
開啟「包含實際的執行計畫」選項，執行如上語句，發現開銷最大的是索引查詢和鍵查詢，分別佔了
47%和
48%，加起來就是
95%了。而作為主要查詢條件的
contains
部分1%
。於是仔細看了下，他的實際行數竟然有
13076
行，而我們只需要返回
9行而已，再順著執行計畫往後走，發現索引查詢和鍵查詢都有
12000
多行。
具體的執行計畫，以及關鍵步驟的執行屬性如下圖所示：
找到了最大的問題，現在的關鍵任務就是怎麼樣減少全文操作、索引查詢、鍵查詢的實際行數。
由於符合搜尋條件的項有很多
(示例中就有
1.3萬
)，如果能夠使用這些資訊按排名對匹配項進行排序，並最多隻返回我需要的數目的匹配項，不就可以大幅度提高效能，從而解決我的問題了嘛。
查閱相關資料，發現全文函式
containstable
正好符合我的要求，於是開始改寫。
改下之後的語句如下：
select
ft_tbl
.title
,tag
,idx
asfidx
,groupidx
from
plateforum
asft_tbl
inner
join
containstable
(plateforum
,tag,'
朋友' ,
9)askey_tbl
onft_tbl
.idx
=key_tbl
.[key]
where
state
<>
2 and
rank
>
100order
bynewid
()迫不及待地開啟「包含實際的執行計畫」選項看看是否真的提公升了效能，結果如下圖：
果然不負我望：資源消耗竟然降低了
19倍。
接下來就是驗證，效能提公升是否是因為減少了實際行數？具體的執行計畫如下所示：
通過上圖可以看出，全文操作、索引查詢、鍵查詢的實際行數確確實實已經減少到我們需要的
9行，而全文操作在總的語句裡面的開銷比例也從
1%增加到了
15%。
由於對錶做了分割槽儲存，由於減少了實際行數，「實際分割槽計數」也從原來的
5個減少到1個。
用上面的方法改到儲存過程裡面，用
profiler
再次抓取，發現
cpu開銷降低了
10倍、
io讀取將近減少為原來的
1/6、而原先的延時更是降低了將近
20倍。至此，優化基本完成。
看懂並深入分析執行計畫太重要了！
oracle contains函式 全文檢索
1.查詢住址在北京的學生 select student id,student name from students where contains address,beijing remark beijing是乙個單詞，要用單引號括起來。2.查詢住址在河北省的學生 select student id,...
05 使用ES替代whoosh全文檢索
1.docker安裝es 1.拉取docker映象 從倉庫拉取映象 sudo docker image pull delron elasticsearch ik 2.4.6 1.0 2.使用docker安裝es docker run d p 9200 9200 p 9300 9300 name el...
用MySQL全文索引給FeedDB打造乙個搜尋引擎
用mysql全文索引給feeddb打造乙個搜尋引擎 雜項其他 python.cn news,jobs 原始出處 xiaoxia pg 效果圖，歡迎測試 只要你輸入關鍵字 xiaoxia 進行搜尋，絕對不會出現 xiaoxiao 的結果了，因為這是兩個不同的名字。提到搜尋引擎技術就離不開分詞和索引，在...