mysql插入意向锁测试

1、表结构

    CREATE TABLE `reno` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `name` varchar(10) DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=112 DEFAULT CHARSET=utf8

2、表数据

    insert into reno select 5, 'aa'

  insert into reno select 7, 'bb'

  insert into reno select 9, 'cc'

  insert into reno select 18, 'dd'

  insert into reno select 23, 'ee'

  insert into reno select 30, 'ff'

  insert into reno select 40, 'gg'

  insert into reno select 45, 'hh'

  insert into reno select 99, 'ii'

3、两种尝试

    下面两种方案都会造成阻塞,我理解都是事务1获取到了间隙锁，事务2获取插入意向锁阻塞，但是“show engine INNODB status\G”输出结果不一样，

第一种方案

    事务1 lock_mode X locks gap before rec 我理解是间隙锁

    事务2 lock_mode X locks gap before rec insert intention waiting 我理解是获取插入意向锁

第二种方案

    事务1  trx id 9821 lock_mode X 我理解是 Next key锁

    事务2 lock_mode X insert intention waiting 我理解是获取插入意向锁

我的疑问 为什么两个方案，事务1获取的锁，以及事务2获取的锁都是不一样的呢 

第一种方案 

当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。

当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。

当MySQL检测到磁盘空间满了，它会：

每分钟：检查空间是否得到释放，以便写入新数据。当发现有剩余空间了，就会继续写入数据，一切照旧。

每十分钟：如果还是发现没剩余空间，则会在日志中写入一条记录，报告磁盘空间满(这时候只写入几个字节还是够的)。

应该怎么办

那么，当发现磁盘空间满了之后，我们应该怎么处理呢，建议：

提高监控系统检测频率，预防再次发生；

及时删除不用的文件，释放空间；

若有线程因磁盘满的问题被阻塞了，可先杀掉，等到下一分钟重新检测时它可能又可以正常工作了；

可能因磁盘满导致某些线程被阻塞，引发其他线程也被阻塞，可把导致阻塞的线程杀掉，其他被阻塞的线程也就能继续工作了。

例外

有个例外的情况是：

当执行 REPAIR TABLE 或者 OPTIMIZE TABLE *** 作时，或者执行完 LOAD DATA INFILE 或 ALTER TABLE 之后批量更新索引时，这些 *** 作会创建临时文件，当执行这些 *** 作过程中mysqld发现磁盘空间满了，就会把这个涉及到的表标记为crashed，删掉临时文件(除了 ALTER TABLE *** 作，MySQL会放弃正在执行的 *** 作，删除临时文件，释放磁盘空间)。

备注：当执行这些命令过程中mysqld进程被意外被杀掉的话，其所生成临时文件不会自动删除，需要手工删掉才能释放磁盘空间。

5.5.53版本同样出现这情况，估计版本无关。也是insert语句，大量插入后就停在这状态了。。。据说这状态完后面还有一个freeing item状态，然后还有一个cleaning up状态然后才结束

---