第一类:查询长时间不返回
大概率是表被锁住了。一般都是首先执行一下show processlist命令,看看当前语句处于什么状态。
等MDL锁
show processlist命令,显示Waiting for table metadata lock。表示现在有一个线程正在表t上请求或者持有MDL写锁,把select语句堵住了。
通过查询sys.schema_table_lock_waits这张表,我们就可以直接找出造成阻塞的process id,把这个连接用kill 命令断开即可。
等flush
线程的状态是Waiting for table flush
等行锁
session A启动了事务,占有写锁,还不提交,是导致session B被堵住的原因。可以通过sys.innodb_lock_waits 表查到是谁占着这个写锁。
mysql> select * from t sys.innodb_lock_waits where locked_table=`'test'.'t'`\G
第二类:查询慢
扫描行数多,所以执行慢
带lock in share mode的SQL语句,是当前读,因此会直接读到1000001这个结果,所以速度很快;而select * from t where id=1这个语句,是一致性读,因此需要从1000001开始,依次执行undo log,执行了100万次以后,才将1这个结果返回。
小结
我们在举例加锁读的时候,用的是这个语句,select * from t where id=1 lock in share mode。由于id上有索引,所以可以直接定位到id=1这一行,因此读锁也是只加在了这一行上。
但如果是下面的SQL语句,
begin;
select * from t where c=5 for update;
commit;
这个语句序列是怎么加锁的呢?加的锁又是什么时候释放呢?