mysql学习笔记-1
mysql最不同也是最重要的特性，就是它的存储引擎架构。如图，存储引擎只处理mysql server发送的请求，不处理sql语句的解析与缓存等内容。但innodb是一个例外，因为innodb有外键定义，而mysql server目前还没有实现相关内容。
在mysql内部，每个连接都有一个线程来处理这个连接上面的请求（所以事务是不能跨越在两个连接上的，一个连接在同一时间也只能启动一个事务）。
在sql语句的parser，将sql解析成树状结构，这里可能会重写sql决定使用哪个索引等。在query cache存储sql语句与result，如果命中，就不再到存储引擎进行查询了。Query cache只存储select语句。
mysql server本身使用表级锁，如ALTER TABLE使用的就是mysql server提供的。行级锁是在存储引擎实现的，各存储引擎都有自己实现行级锁的方式，mysql server对此不需要了解。
大多数存储引擎的隔离级别是read committed，但Mysql的默认隔离级别却是repeatable read。innodb是通过多版本的方式解决repeatable read带来的幻读问题的。附：
l read uncommited即脏读，一个事务修改了一行，另一个事务也可以读到该行。如果第一个事务执行了回滚，那么第二个事务读取的就是从来没有正式出现过的值。
l read commited即一致读，试图通过只读取提交的值的方式来解决脏读的问题，但是这又引起了不可重复读取的问题。一个事务执行一个查询，读取了大量的数据行。在它结束读取之前，另一个事务可能完成了对数据行的更改。当第一个事务试图再次执行同一个查询，服务器就会返回不同的结果。
l repeatable read即可重复读，在一个事务对数据行执行读取或写入操作时锁定了这些数据行。但是这种方式又引发了幻想读的问题。因为只能锁定读取或写入的行，不能阻止另一个事务插入数据，后期执行同样的查询会产生更多的结果。
l sieralizable完全串行，用的太少，就不写了。
默认情况下，mysql开启autocommit，只有调用start transaction，它一直认为每个sql都是一个单独的事务。如果关闭了autocommit，除非你调用了commit或者rollback，你会一直在一个事务里面。当调用commit或者rollback后，它会自动的帮你在启动一个事务。
因为存储引擎自己实现事务，所以一个事务无法跨越多重存储引擎类型的表。
在一个事务中任何时候都可以获取锁，但只有事务结束时才会释放锁。lock in share mode是允许其他session读但不能写，读取的数据行如果被其他事物锁着，就会等待直到那个事务提交。for update则是排他锁，不允许读或者写。
Innodb实现Mutiversion concurrency control（MVCC），通过为每行数据记录两个隐藏的值，这两个值分别为数据创建点与过期点（binlog中的那些版本号）。增删查的处理就不用多说了，改的时候，innodb通过增加一个数据行的拷贝来完成，拷贝的创建号与原数据行的删除号就是当前系统号。
遗留问题：
在repeatable read下，innodb是怎么处理这个lock in share mode的呢？