在平時我們用mysql的鎖時，一般剛接觸資料庫是很少考慮鎖的效率，一般只求到達防止併發的目的就可以了，但是隨著資料量的增大我們就會發現有很多sql我們已經寫的非常優化了，但是有時候還是很慢，很難找到原因，這時候我們就應該考慮一下是不是mysql的鎖在導致的，（當然可能的原因很多，比如沒有正確的建立以及使用索引、事物過長、伺服器配置跟不上等等，這裡主要討論索引和鎖的聯絡。）下面我們來舉一個例子；

我們首先建立一個新的資料表：

這裡我們的主鍵預設是有索引的；這邊加幾條資料

然後我們開兩個程序進行測試：

先加一個where條件沒有涉及到索引的鎖：

然後我們在第二個視窗進行一個更新這一行的資料，我們會發現這個操作會被卡著，

然後我們提交事務會發現第二個視窗的資料會立馬執行，

從上面來看似乎沒有任何問題，這樣確實達到了我們想要的目的，但是你可以再加同樣的鎖，試著更新下其他的資料比如我下面執行的資料：

上面的三種情況都是我用同樣的流程測試的，他們都會被卡住，這樣問題就來了，我們其實在鎖住name='測試姓名'的時候或許只是想鎖住id=133和id=134兩行，我們並不想鎖住135,136,137，但是這三行我們也訪問不了，因為我們的鎖是一個表鎖，我們來試一下另一種用鎖時用到索引的情況：

上面用鎖時用到了索引，但是我們在更新資料時還是被卡住了；這裡我們就會覺得索引其實也沒什麼用，但是你遇到同樣的鎖，更新資料時也用到索引是可以看一下效果：

我們會發現這個沒有被鎖卡住，直接更新了；

下面總結一下：如果我們的鎖用到索引就是行鎖，如果沒有用到索引就是表鎖，但是我們操作的資料必須用到鎖才行；

下面我們來說一下為什麼會這樣：

首先我們知道如果沒有建立索引的話我們在進行資料選取或者定位的時候是通過全表掃描的形式來進行的，這樣就會形成表鎖，要是有索引的話就會直接定位到指定的行，就是形成行鎖，但是要注意你在更新資料是假如沒用到索引也會全表掃描，當掃到被鎖的這一行是也會被鎖住，所以達不到想要的效果；