在MySql的寫語句中，給表列賦值與表類型不符合時(shí)，MySql底層的優(yōu)化器發(fā)揮作用，會(huì)做一個(gè)強(qiáng)制類型轉(zhuǎn)化，此時(shí)能正常操作，但會(huì)導(dǎo)致行鎖升級為表鎖。示例如下

以student表為例，表字段類型：
表內(nèi)容如下：

打開兩個(gè)session會(huì)話窗口，并把兩個(gè)會(huì)話窗口中的MySql的自動(dòng)提交模式改為手動(dòng)提交

>set autocommit=false;

在會(huì)話窗口1中執(zhí)行更新語句，但不提交事務(wù)。age列在建表時(shí)指定的是int類型，此地更新語句中用字符串’100’進(jìn)行賦值，在MySql的優(yōu)化器中會(huì)自動(dòng)把字符串’100’強(qiáng)制轉(zhuǎn)化為整形100，然后再執(zhí)行SQL檢索。

>update student set class=3 where age='100'

然后再會(huì)話窗口2中對另外沒關(guān)系的數(shù)據(jù)執(zhí)行更新操作

>update student set age=28 where name='lzj';

正常情況下，兩條SQL語句操作的行數(shù)據(jù)不同，執(zhí)行起來會(huì)互不影響，但實(shí)際會(huì)話1中的更新操作阻塞了會(huì)話2中的更新操作
會(huì)話1中執(zhí)行了更新操作，但沒有執(zhí)行事務(wù)提交，事務(wù)的隔離級別為Read Committed，所以在會(huì)話2中還看不到會(huì)話1中更新后的結(jié)果。但在回話2中執(zhí)行對其它行數(shù)據(jù)更新操作時(shí)，出現(xiàn)了阻塞。可見會(huì)話1中的SQL語句的賦值出現(xiàn)了強(qiáng)轉(zhuǎn)，導(dǎo)致會(huì)話1由行鎖升級為表鎖，鎖住了整個(gè)student表，因而會(huì)話2中的SQL阻塞。下面對會(huì)話1中的更新操作執(zhí)行事務(wù)提交，那么會(huì)話2中的更新操作就會(huì)繼續(xù)執(zhí)行了
對會(huì)話1中的更新操作執(zhí)行commit手動(dòng)提交事務(wù)后，會(huì)話1釋放掉student的表鎖，會(huì)話2中的更新操作可以繼續(xù)執(zhí)行。
最后對會(huì)話2中的更新也執(zhí)行commit事務(wù)提交，兩條SQL都更新完畢，student表內(nèi)容如下：

從上述案例觀知，SQL語句賦值與表列類型不匹配時(shí)，MySql的優(yōu)化器強(qiáng)制轉(zhuǎn)化為匹配的類型，導(dǎo)致行鎖升級為表鎖。所以開發(fā)中一定要注意類型的匹配，避免行鎖升級為表鎖，影響并發(fā)性能。

相關(guān)推薦：

MySQL行級鎖、表級鎖、頁級鎖詳細(xì)介紹

MySQL鎖的用法之表級鎖

以上就是MySql類型轉(zhuǎn)換導(dǎo)致行鎖升級為表鎖的詳細(xì)內(nèi)容，更多請關(guān)注php中文網(wǎng)其它相關(guān)文章！