您好,登錄后才能下訂單哦!
小編給大家分享一下MySql類型轉換導致行鎖升級為表鎖的示例,希望大家閱讀完這篇文章之后都有所收獲,下面讓我們一起去探討吧!
在MySql的寫語句中,給表列賦值與表類型不符合時,MySql底層的優化器發揮作用,會做一個強制類型轉化,此時能正常操作,但會導致行鎖升級為表鎖。示例如下
以student表為例,表字段類型:
表內容如下:
打開兩個session會話窗口,并把兩個會話窗口中的MySql的自動提交模式改為手動提交
>set autocommit=false;
在會話窗口1中執行更新語句,但不提交事務。age列在建表時指定的是int類型,此地更新語句中用字符串’100’進行賦值,在MySql的優化器中會自動把字符串’100’強制轉化為整形100,然后再執行SQL檢索。
>update student set class=3 where age='100'
然后再會話窗口2中對另外沒關系的數據執行更新操作
>update student set age=28 where name='lzj';
正常情況下,兩條SQL語句操作的行數據不同,執行起來會互不影響,但實際會話1中的更新操作阻塞了會話2中的更新操作
會話1中執行了更新操作,但沒有執行事務提交,事務的隔離級別為Read Committed,所以在會話2中還看不到會話1中更新后的結果。但在回話2中執行對其它行數據更新操作時,出現了阻塞。可見會話1中的SQL語句的賦值出現了強轉,導致會話1由行鎖升級為表鎖,鎖住了整個student表,因而會話2中的SQL阻塞。下面對會話1中的更新操作執行事務提交,那么會話2中的更新操作就會繼續執行了
對會話1中的更新操作執行commit
手動提交事務后,會話1釋放掉student的表鎖,會話2中的更新操作可以繼續執行。
最后對會話2中的更新也執行commit
事務提交,兩條SQL都更新完畢,student表內容如下:
從上述案例觀知,SQL語句賦值與表列類型不匹配時,MySql的優化器強制轉化為匹配的類型,導致行鎖升級為表鎖。所以開發中一定要注意類型的匹配,避免行鎖升級為表鎖,影響并發性能。
看完了這篇文章,相信你對“MySql類型轉換導致行鎖升級為表鎖的示例”有了一定的了解,如果想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。