Mysql-----Innodb引擎行锁变为表锁

MySQL 的 InnoDB 存储引擎支持事务，支持行级锁（InnoDB 的行锁是通过给索引项加锁实现的）。得益于这些特性，数据库支持高并发。如果 InnoDB 更新数据使用的不是行锁，而是表锁呢？是的，InnoDB 其实很容易就升级为表锁，届时并发性将大打折扣了。

常用的索引有三类：主键、唯一索引、普通索引。主键不由分说，自带最高效率的索引属性；唯一索引指的是该属性值重复率为0，一般可作为业务主键，例如：学号；普通索引与前者不同的是，属性值的重复率大于0，不能作为唯一指定条件，例如：学生姓名。

先给结论：Innodb引擎下，行锁是基于索引项加锁来实现的，故有以下几点

• 如果在where筛选条件时没有使用到索引项，那么一定是表级锁
• 筛选条件时使用到主键或者唯一索引，一定是行级锁
• 筛选条件时使用到普通索引时，不一定是行级锁，得看看表内是否有大量数据且修改表内大部分数据，是的话mysql会将行锁变为表锁，即为普通索引的数据重复率过高导致索引失效，行锁升级为表锁。
• 最后，可以用expland执行计划来查看执行效率怎么样

行锁

• 行锁的劣势：开销大；加锁慢；会出现死锁
• 行锁的优势：锁的粒度小，发生锁冲突的概率低；处理并发的能力强
• 加锁的方式：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；当然我们也可以显示的加锁：
• 共享锁：select * from tableName where … + lock in share more
• 排他锁：select * from tableName where … + for update

InnoDB和MyISAM的最大不同点有两个：一，InnoDB支持事务(transaction)；二，默认采用行级锁。加锁可以保证事务的一致性

InnoDB默认采用行锁，在未使用索引字段查询时升级为表锁。MySQL这样设计并不是给你挖坑。它有自己的设计目的。
**即便你在条件中使用了索引字段，MySQL会根据自身的执行计划，考虑是否使用索引(所以explain命令中会有possible_key 和 key)。**如果MySQL认为全表扫描效率更高，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。

第一种情况：全表更新。事务需要更新大部分或全部数据，且表又比较大。若使用行锁，会导致事务执行效率低，从而可能造成其他事务长时间锁等待和更多的锁冲突。

第二种情况：多表级联。事务涉及多个表，比较复杂的关联查询，很可能引起死锁，造成大量事务回滚。这种情况若能一次性锁定事务涉及的表，从而可以避免死锁、减少数据库因事务回滚带来的开销。

案例体现：
mysql 行锁升级为表锁
MySQL 避免行锁升级为表锁