如何進(jìn)行MySQL Stmt預(yù)處理提高效率問題的研究，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)2013年開創(chuàng)至今，先為瑞安等服務(wù)建站，瑞安等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為瑞安企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

在oracle數(shù)據(jù)庫中，有一個變量綁定的用法，很多人都比較熟悉，可以調(diào)高數(shù)據(jù)庫效率，應(yīng)對高并發(fā)等，好吧，這其中并不包括我，當(dāng)同事問我MySQL中有沒有類似的寫法時，我是很茫然的，于是就上網(wǎng)查，找到了如下一種寫法：

view sourceprint?DELIMITER $$ 

  set @stmt = select userid,username from myuser where userid between ? and ?; 

  prepare s1 from @stmt; 

  set @s1 = 2; 

  set @s2 = 100; 

  execute s1 using @s1,@s2; 

  deallocate prepare s1; 

$$ 

DELIMITER ;

 用這種形式寫的查詢，可以隨意替換參數(shù)，給出代碼的人稱之為預(yù)處理，我想這個應(yīng)該就是MySQL中的變量綁定吧……但是，在查資料的過程中我卻聽到了兩種聲音，一種是，MySQL中有類似Oracle變量綁定的寫法，但沒有其實際作用，也就是只能方便編寫，不能提高效率，這種說法在幾個09年的帖子中看到：

另一種說法是MySQL中的變量綁定是能確實提高效率的，這個是希望有的，那到底有木有，還是自己去試驗下吧。

試驗是在本機進(jìn)行的，數(shù)據(jù)量比較小，具體數(shù)字并不具有實際意義，但是，能用來說明一些問題，數(shù)據(jù)庫版本是mysql-5.1.57-win32免安裝版。

本著對數(shù)據(jù)庫不是很熟悉的態(tài)度^_^,試驗過程中走了不少彎路，此文以結(jié)論為主，就不列出實驗的設(shè)計過程，文筆不好，文章寫得有點枯燥，寫出來是希望有人來拍磚，因為我得出的結(jié)論是：預(yù)處理在有沒有cache的情況下的執(zhí)行效率都不及直接執(zhí)行…… 我對自己的實驗結(jié)果不愿接受。。如果說預(yù)處理只為了規(guī)范下Query，使cache命中率提高的話個人覺得大材小用了，希望有比較了解的人能指出事實究竟是什么樣子的——NewSilen

實驗準(zhǔn)備

第一個文件NormalQuery.sql

NormalQuery
Set profiling=1;Select * From MyTable where DictID = 100601000004;Select DictID from MyTable limit 1,100;Select DictID from MyTable limit 2,100;/*從limit 1，100 到limit 100,100 此處省略重復(fù)代碼*/......Select DictID from MyTable limit 100,100;SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE d:/NormalResults.csv FIELDS TERMINATED BY , LINES TERMINATED BY
;
第二個sql文件 StmtQuery.sql

StmtQuery
Set profiling=1;Select * From MyTable where DictID = 100601000004;set @stmt = Select DictID from MyTable limit ?,?;prepare s1 from @stmt;set @s = 100;set @s1 = 101;set @s2 = 102;......set @s100 =200;execute s1 using @s1,@s;execute s1 using @s2,@s;......execute s1 using @s100,@s;SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE d:/StmtResults.csv FIELDS TERMINATED BY , LINES TERMINATED BY
;
做幾點小說明：

1. Set profiling=1; 執(zhí)行此語句之后，可以從information_schema.profiling這張表中讀出語句執(zhí)行的詳細(xì)信息，其實包含不少內(nèi)容，包括我需要的時間信息，這是張臨時表，每新開一個會話都要重新設(shè)置profiling屬性才能從這張表中讀取數(shù)據(jù)

2. Select * From MyTable where DictID = 100601000004;

這行代碼貌似和我們的實驗沒什么關(guān)系，本來我也是這么認(rèn)為的，之所以加這句，是我在之前的摸索中發(fā)現(xiàn)，執(zhí)行過程中有個步驟是open table，如果是第一次打開某張表，那時間是相當(dāng)長的，所以在執(zhí)行后面的語句前，我先執(zhí)行了這行代碼打開試驗用的表

3. MySQL默認(rèn)在information_schema.profiling表中保存的查詢歷史是15條，可以修改profiling_history_size屬性來進(jìn)行調(diào)整，我希望他大一些讓我能一次取出足夠的數(shù)據(jù)，不過最大值只有100，盡管我調(diào)整為150，最后能夠查到的也只有100條，不過也夠了

4. SQL代碼我沒有全列出來，因為查詢語句差不多，上面代碼中用省略號表示了，最后的結(jié)果是兩個csv文件，個人習(xí)慣，你也可以把結(jié)果存到數(shù)據(jù)庫進(jìn)行分析

實驗步驟

重啟數(shù)據(jù)庫，執(zhí)行文件NormalQuery.sql，執(zhí)行文件StmtQuery.sql，得到兩個結(jié)果文件

再重啟數(shù)據(jù)庫，執(zhí)行StmtQuery.sql，執(zhí)行文件NormalQuery.sql，得到另外兩個結(jié)果文件

實驗結(jié)果分析

每一個SQL文件中執(zhí)行了一百個查詢語句，沒有重復(fù)的查詢語句，不存在查詢cache，統(tǒng)計執(zhí)行SQL的平均時間得出如下結(jié)果

從結(jié)果中可以看出，無論是先執(zhí)行還是后執(zhí)行，NormalQuery中的語句都比使用預(yù)處理語句的要快一些=.=！

那再來看看每一句查詢具體的情況，Normal和Stmt的query各執(zhí)行了兩百次，每一步的詳細(xì)信息如下：

從這里面可以看出，第一個，normalquery比stmtquery少一個步驟，第二個，雖然stmt在不少步驟上是優(yōu)于normal的,但在executing一步上輸?shù)籼啵詈蠼Y(jié)果上也是落敗

 最后，再給出一個查詢緩存的實驗結(jié)果，具體步驟就不列了

在查詢緩存的時候，Normal完勝……

關(guān)于如何進(jìn)行MySQL Stmt預(yù)處理提高效率問題的研究問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。