在平時我們用mysql的鎖時，一般剛接觸資料庫是很少考慮鎖的效率，一般只求到達防止併發的目的就可以了，但是隨著資料量的增大我們就會發現有很多sql我們已經寫的非常優化了，但是有時候還是很慢，很難找到原因，這時候我們就應該考慮一下是不是mysql的鎖在導致的。
我們首先建立乙個新的資料表：
這裡我們的主鍵預設是有索引的；這邊加幾條資料
然後我們開兩個程序進行測試：
先加乙個where條件沒有涉及到索引的鎖：
然後我們在第二個視窗進行乙個更新這一行的資料，我們會發現這個操作會被卡著，
然後我們提交事務會發現第二個視窗的資料會立馬執行，
從上面來看似乎沒有任何問題，這樣確實達到了我們想要的目的，但是你可以再加同樣的鎖，試著更新下其他的資料比如我下面執行的資料：
上面的三種情況都是我用同樣的流程測試的，他們都會被卡住，這樣問題就來了，我們其實在鎖住name='測試姓名'的時候或許只是想鎖住id=133和id=134兩行，我們並不想鎖住135,136,137，但是這三行我們也訪問不了，因為我們的鎖是乙個表鎖，我們來試一下另一種用鎖時用到索引的情況：
上面用鎖時用到了索引，但是我們在更新資料時還是被卡住了；這裡我們就會覺得索引其實也沒什麼用，但是你遇到同樣的鎖，更新資料時也用到索引是可以看一下效果：
我們會發現這個沒有被鎖卡住，直接更新了；
下面總結一下：如果我們的鎖用到索引就是行鎖，如果沒有用到索引就是表鎖，但是我們操作的資料必須用到鎖才行；
下面我們來說一下為什麼會這樣：
首先我們知道如果沒有建立索引的話我們在進行資料選取或者定位的時候是通過全表掃瞄的形式來進行的，這樣就會形成表鎖，要是有索引的話就會直接定位到指定的行，就是形成行鎖，但是要注意你在更新資料是假如沒用到索引也會全表掃瞄，當掃到被鎖的這一行是也會被鎖住，所以達不到想要的效果；
mysql的索引和鎖的微妙關係
做專案時由於業務邏輯的需要，必須對資料表的一行或多行加入行鎖，舉個最簡單的例子，圖書借閱系統。假設id 1的這本書庫存為1，但是有2個人同時來借這本書，此處的邏輯為 select restnum from book where id 1 如果restnum大於0，執行update update bo...
MySQL索引和鎖
索引和鎖可以讓查詢鎖定更少的行。如果你的查詢從不訪問那些不需要訪問的行，那麼就會鎖定更少的行，從兩個方面來看這對效能都有好處。首先，雖然innodb的行鎖效率很高，記憶體使用也很少，但是鎖定行的時候仍然會帶來額外的開銷，其次，鎖定超過需要的行會增加鎖競爭，並減少併發性。innodb只有在訪問行的時候...
mysql索引與鎖的關係 關係型資料庫 索引與鎖
設計乙個關係型資料庫 png 索引模組 為什麼要使用索引 查詢時間複雜度從o n 提公升到o logn png 存在以下弊端，並且會多次io，影響速度。png 採用b tree b tree 多路搜尋樹，並不是二叉的 是一種常見的資料結構。使用b tree結構可以顯著減少定位記錄時所經歷的中間過程，...