有如下遞歸函數,用來查詢某型裝備下的所有子裝備,并將結果以字符串形式返回,具體函數如下:


圖1 查看參數

經過反復測試,該函數始終無法得到所有子裝備,懷疑是該函數內部某參數長度或系統函數返回結果的長度無法滿足要求。
經反復檢查,初步懷疑是group_concat函數返回值長度受限。
如圖1所示,查看系統有關參數后發現group_concat函數的最大長度為1024,無法滿足需求。故使用“set group_concat_max_len =10000”將該參數設置為10000。再次運行遞歸函數,結果正常。
本以為問題已經得到解決,但是在客戶端斷開與MySQL服務器連接后,再次連接MySQL服務器時,問題仍然出現。
此時查看參數” group_concat_max_len”,發現之前做的更改失效了。
后經研究發現”set group_concat_max_len”相當于”set session group_concat_max_len”,該設置只對單次連接有效,因此當連接斷開后,再次進行連接時,上次所做更改失效。
使 用”set global group_concat_max_len”修改參數后,斷開連接后再次連接時,發現所做更改仍然有效。
但是當重啟MySQL服務后,問題再次出現,再看參數,發現之前所做更改再次失效。
此時,修改配置文 件 my.ini,加 入 一行” group_concat_max_len=10000”,重 啟 MySQL服務,再次查看對應參數,發現所做更改有效。
至此,問題完全解決。得出結論:my.ini文件中的配置永久有效;使用”set global xxx”設置參數時,在MySQL服務不重啟的情況下,一直有效;使用“set xxx”設置參數時,僅對當前連接有效。
由于需要批量處理數據,因此必須用到游標。在使用游標的過程中,也出現了一些問題。
1.游標的聲明。游標聲明必須在變量或條件聲明后。
2.多一次循環的問題。有一個存儲過程,其中使用到了游標。代碼如下:


圖2 查看數據庫情況

圖3 查看相關參數

當調用該存儲過程時,發現實際的循環次數總是比所希望的循環次數多一次。
經研究發現,當游標指到最后一條數據時,done的值仍為0,滿足循環條件,因此又進入下一次循環,fetch后面的代碼繼續執行,游標繼續向后移動,此時無數據,將done置為1,不滿足循環條件,因此實際循環次數比理論循環次數多了一次。
在將代碼進行如下修改后,程序正常執行。
……
fetch getEqu into equID,equNum,equPrice;if(not done) then
……
end if;
筆者在一次向后臺服務器提交數據庫處理請求時,遭遇了嚴重的超時問題。具體情況如下:
系統采用的是B/S架構,在前臺向服務器提交請求后,前臺頁面一直處于等待狀態。
使 用”show processlist”反復查看數據庫運行狀態,結果如圖2所示。
結果數據庫一直在執行語 句”delete……”,直 到50秒后,進入sleep狀態,此時前臺的等待狀態結束。懷疑該問題與數據庫鎖有關。此時使用”show variables like ‘%innodb_lock%’” 查看相關參數,結果如圖3所示。
我們可以看到innodb_lock_wait_timeout的值與之前等待的時間相同,再查看后臺軟件,有提示表示鎖等待超時。
為了查明具體的原因,再次向服務器提交相同的請求。
此 時,查 看information_schema數據庫,如圖 4、圖 5。
通過以上結果可以初步判斷,此次請求造成了數據庫的鎖等待,并且能夠精準定位具體產生鎖等待的表為ck.sysmsg。
此時,再去檢查后臺響應請求的代碼,


圖4 information_schema數據庫

圖5 information_schema數據庫
此處,首先建立了一個數據庫連接,并且執行了相應的數據庫操作,該操作會向ck.sysmsg表中新增一條數據,但是由于將autocommit設置為0,該新增操作并不會立即提交。
然后,sqlExecute函數又新建了一個數據庫連接,用來更新application表,同時會觸發對ck.sysmsg表的delete操作。
此時,之前向ck.sysmsg新增數據的操作正在等待提交。因而就會產生鎖等待的現象,delete的操作一直在等待ck.sysmsg表中鎖的釋放。
為了解決這一問題,對后臺代碼做如下的修改:

至此,問題完全解決。
在利用MySQL進行開發的時候會遇到各種各樣的問題,在遇到問題時,一定要思路清晰,多利用MySQL自帶的命令語句查找問題。希望本文能為大家提供一個思路。