索引可以讓查詢鎖定更少的行.如果你的查詢從不訪問哪些不需要的行,那么就會鎖定更少的行,從兩方面來看這對性能都有好處. Innodb只有在訪問行的時候才會對其加鎖,而索引能夠減少Innodb訪問的行數,從而減少鎖的數量.但這只有當Innodb在存儲引擎層能夠過濾掉索引不需要的行的時候才有效果, 如果索引無法過濾無效的行,那么在Innodb檢索到數據并返回給服務層以后,mysql服務器才能應用到where子句.這時候已經無法避免鎖定行了,innodb已經鎖定這些行了,到適當的時候才會釋放, 在mysql5.1以及更新版本的時候,innodb可以在服務器端過濾掉后就釋放鎖,但是在早期的mysql版本中,Innodb只有在事務提交后才能釋放鎖 看下面的例子 ~~~ set autocommit = 0 ; begin; select actor_id from sakila.actor where actor_id < 5 and actor_id <> 1 for update; ~~~  底層的存儲引擎的操作是"從索引頭開始獲取滿足條件actor_id < 5"的記錄,服務器并沒有告訴Innodb可以過濾第一行的where條件,注意到explain的extra出現了Using where,這表示mysql服務器將存儲引擎返回行以后再應用where過濾條件 下面的第二個查詢就能證明第一行確實被鎖定,盡管第一個查詢的結果中并沒有這個第一行,保持第一個連接打開,然后開啟第二個連接并執行如下的查詢  這個查詢將會掛起,直到第一個事務釋放第1行的鎖,這個行為對于基于語句的復制的正常運行來說是必要的.(盡管在理論上使用基于行的日志模式,在某些是事務隔離級別下,服務器不再需要鎖定行,但是實際上經常發現無法實現這種預期的行為.知道mysql5.6.3版本,在read-commit隔離級別和基于行的日志模式下,這個例子還是會導致鎖) 就像這個例子顯示的,即使使用了索引,Innodb也可能鎖住一些不需要的數據.如果不能使用索引查找和鎖定行的話問題可能會很糟糕,mysql會做全表掃描并鎖住所有的行,而不管是不是需要的 關于Innodb,索引和鎖有一些很少有人知道的細節,Innodb在二級索引上使用共享(讀)鎖,但訪問主鍵索引需要排他(寫)鎖,這消除了使用索引覆蓋的可能性,并且使得select for update 比 lock in share mode或非鎖定查詢要慢很多