如何理解数据库MySQL的表级锁、行级锁、页锁问题？

从锁的粒度进行对数据库进行划分等级

1. 表级锁
2. 行级锁
3. 页级锁（这个不常用）

（1）MySQL的表级锁两种模式：

1. 表级共享读锁（共享锁）：

也就是在MyISAM引擎下，如果对一个表加了读锁的话，那么这个表（user表吧）当前的A线程可以进行读，但是不能对user表进行写操作，如果又有一个B线程想要去读取user表的时候，此时也是可以读取user表的，但是不能对user表进行写操作，会对B线程进行阻塞。

2. 行级共享写锁（排它锁）：

同样是在MyISAM的引擎下，如果对一个表加了写锁的情况下，就是说当我对user表加了写锁的时候，你其他人就不能读、也不能写对我这个加写锁的表进行任何操作了，就是这么任性，如果你想进行操作你只能在外面排队，等我释放之后你才能进行操作。

总结：表锁适合那些业务偏读的一些场景

（2）MySQL的行锁：

MySQL的行锁主要偏向于InnoDB引擎，开销大，加锁慢，容易出现死锁，但是行锁的粒度最小，并发度也比较高。所以InnoDB和MYISAM的主要区别也就是两点：

1. InnoDB可以支持事务，但是 MyISAM引擎不支持事务
2. InnoDB可以最大化的支持行锁的最小粒度

2. Innodb中的行锁与表锁：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

1. 在不通过索引条件查询的时候,InnoDB 确实使用的是表锁,而不是行锁。
2. 由于 MySQL 的行锁是针对索引加的锁,不是针对记录加的锁,所以虽然是访问不同行 的记录,但是如果是使用相同的索引键,是会出现锁冲突的。应用设计的时候要注意这一点。
3. 当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论 是使用主键索引、唯一索引或普通索引,InnoDB 都会使用行锁来对数据加锁
4. 即便在条件中使用了索引字段,但是否使用索引来检索数据是由 MySQL 通过判断不同 执行计划的代价来决定的,如果 MySQL 认为全表扫 效率更高,比如对一些很小的表,它 就不会使用索引,这种情况下 InnoDB 将使用表锁,而不是行锁。因此,在分析锁冲突时, 别忘了检查 SQL 的执行计划,以确认是否真正使用了索引。

最重要的提醒一下：在使用索引的时候如果不给varchar类型的字段加单引号，就会导致索引失效，造成全表扫描