問題是這樣的，在直接使用mysql c api構(gòu)建應(yīng)用的時(shí)候，一個(gè)連接只能執(zhí)行一次存儲(chǔ)過程，不管怎樣free再次利用這個(gè)連接的時(shí)候就會(huì)出現(xiàn)不能執(zhí)行qurry的提示，我想，這么大型的軟件 不會(huì)存在這樣的基礎(chǔ)性問題吧，畢竟大多數(shù)的adodb都是基于c api的，難道所有的軟件都無法進(jìn)行連接緩存？

別說，接觸到這類問題的人還真不多，大多數(shù)的連接池都寫好了，誰會(huì)去直接構(gòu)建連接進(jìn)行操作呢，所以baidu google基本都沒有結(jié)果，今天回頭來解決這個(gè)問題，突然就有了突破，找到了一篇文章《對(duì)Mysql的C API調(diào)用存儲(chǔ)過程的問題及解決方法分析》，正是我的問題。
作者分析的挺復(fù)雜了，其實(shí)我們一般只用mysql_query、mysql_use_result等幾個(gè)函數(shù)，問題的癥結(jié)在于當(dāng)執(zhí)行一個(gè)存儲(chǔ)過程的時(shí)候， 數(shù)據(jù)庫返回的是多個(gè)數(shù)據(jù)集合，即使只有一個(gè)數(shù)據(jù)集合，他也會(huì)有一個(gè)空集合用于結(jié)束一次回話，作者罵他變態(tài)，其實(shí)不然，可能作者考慮到的只是一般的請(qǐng) 求，mysql是給所有用戶使用的，說不能真有變態(tài)的人把圖片文件等等直接保存在mysql字段里面，那么回復(fù)就不可能一次完成，需要多此網(wǎng)絡(luò)交互，那么 所有的交互肯定需要一個(gè)結(jié)束符號(hào)，并且存儲(chǔ)過程本來就可以返回多個(gè)數(shù)據(jù)集合，如果他在c pai中只做一個(gè)結(jié)果己處理就允許下一次全新的請(qǐng)求，那么對(duì)于同一連接，在mysql服務(wù)斷其實(shí)還有沒有發(fā)送完成的數(shù)據(jù)，這個(gè)時(shí)候他安全的做法就是不接受 任何新的請(qǐng)求，直到數(shù)據(jù)發(fā)送完全，或者連接關(guān)閉，不然，mysql協(xié)議解析就會(huì)出現(xiàn)問題，下次發(fā)送就會(huì)出現(xiàn)黏包或者丟包，所以他的做法是完全正確的，即使 只有一個(gè)結(jié)果集合，也需要當(dāng)前會(huì)話內(nèi)的通訊(比如mysql_next_result)確認(rèn)完畢，然后結(jié)束本次請(qǐng)求，這個(gè)時(shí)候服務(wù)端其實(shí)沒有數(shù)據(jù)了，但是 這個(gè)過程是不能省略的，然后在不關(guān)閉連接的情況下就可以進(jìn)行全新的請(qǐng)求了。
所以總結(jié)起來就是：使用存儲(chǔ)過程的時(shí)候一定要循環(huán)執(zhí)行，把所有的結(jié)果集合都取到，直到為空，這個(gè)時(shí)候當(dāng)前數(shù)據(jù)庫連接才可以安全歸還回去，下面是demo。

經(jīng)過上面的循環(huán)讀取就能夠保證一條連接會(huì)干凈地歸還到連接池，當(dāng)然有的連接池可能已經(jīng)把后面一個(gè)循環(huán)放在連接池中處理了，解釋說把剩余的數(shù)據(jù)集全部取過來然后釋放，這樣比如在php等里面使用mysql的連接池的時(shí)候就沒有感受到上面說的問題。

最新評(píng)論