1 | show create table banner; |
information_schema.innodb_locks
这个表罗列了两类锁：
- 事务请求了但是还没有获取到的锁
- 事务持有的锁，并且这个锁阻塞了其他事务的执行
The INNODB_LOCKS table contains information about each lock that an InnoDB transaction has requested but not yet acquired, and each lock that a transaction holds that is blocking another transaction.
最近在研究数据库的事务和并发控制，顺带把以前碰到 MySQL 的间隙锁一起研究。
条件查询和幻象现象（Phantom Phenomenon）
在不考虑 MVCC 的情况下考虑下面两个事务：
T1：
1 | select count(*) from instructor where dept name = 'Physics' |
T2：
1 | insert into instructor values (11111,’Feynman’, ’Physics’, 94000); |
T1 的查询和 T2 的写入是冲突的，如果事务执行序列是 T1 => T2，那么最终的调度就要求是 select 要发生在 insert 之前。如果一个调度的 insert 发生在前，那么这个调度不是一个冲突可串行化调度，这个调度的执行结果和 T1 => T2 的执行结果不一样。
最近在研究数据库的事务和并发控制。其中的多粒度锁，意向锁（intention lock）书上写的比较抽象，不太具体。网上搜的资料又很概括，描述的清的很少，花了一些时间去理解意向锁整个运行的机制。
最近在研究数据库事务和并发控制，主要的学习资料是《数据库系统概念 第六版》。本文记录了一些自己的理解和问题。如果同样在看这本书或者在研究类似问题的有兴趣可以看一下。这本书描述的东西比较理论，但是对数据库的各种问题的描述比较深入，相比网上的一些文章更加能接触到「真正的东西」，比较推荐。
一些待解决的问题
为什么需要设计共享锁和排他锁？还有意向锁。
SELECT * FROM child WHERE id = 100;If id is not indexed or has a nonunique index, the statement does lock the preceding gap.
为什么这种语句需要加间隙锁？没道理啊 …
答：光 select 是不加锁的，select for update 或者加共享锁才会。光 select 会直接读 MVCC 的快照。
各种锁是如何被数据库系统使用的，如何用锁解决了数据库的一致性和隔离性要求
答：锁锁住了数据，避免了并行执行事务之间的冲突。
锁的目的：是为了实现并发事务控制。各种锁：行锁、间隙锁、next-key 锁。
年终总结之前一直都没写过，公司老大要求写的不算，那种更偏重完成任务，邮件发出去再也不会回头看，自己连存档都懒得做的。今年，2017 年和往年不一样，换了工作，整体上想法和做的事情都有很大不同，值得去总结回味一下。
《Java Nio》4.3.1 节 selection process 阅读的笔记：
Java NIO 比较系统的资料就只能找到英文版的这本书了，对应的中文版翻译实在是太差，只能看英文，这一节的内容比较重要，看了好几遍才看明白，特别记录下来。
selector 包含维护着三种 SelectionKey：
| key类型 | 定义 |
|---|---|
| registered key set | 已注册的 SelectionKey |
| selected key set | 已经就绪的 SelectionKey |
| cancelled key set | registered key set 中，已经调用了 cancel() 但是还没有去除注册关系的 selectionKey |
公司有个项目要用到分布式锁，之前有模仿别人用 memcache 实现过一个，但是现在的公司用 redis ，基本思路还是差不多，网上搜点资料就开始撸。查了不少用 redis 实现分布式锁的文章，发现以前想的思路并不能保证能锁的住，而且不出幺蛾子。本文记录一些基本思路，还有一些资料记录。