Mysql VS Postgresql

1. 事务性

1. Postgresql  实现了读已提交（默认），可重复读，可串行化，没有实现读未提交

    Mysql 实现了读未提交，读已提交，可重复读（默认），可串行化四个隔离级别

2. MySQL 在REPEATABLE READ隔离级别下，普通的select语句是看不到在事务启动之后已经提交的数据，但select for update却能看到，也就是说普通select与select for update看到的结果是不一样的，这是特别需要让开发人员注意的地方。

   而PostgreSQL在REPEATABLE READ隔离级别，select for udpate语句和select语句的结果是一样的，都看不到在事务启动之后已经提交的数据。

3. 在MySQL中，一旦设置了SERIALIZABLE级别后，在事务中一旦查询表，就会把查询的记录都锁住，而PostgreSQL中的SERIALIZABLE也与MySQL中完全不一样。查询不会锁表。

在PostgreSQL中，在窗口１中先开始一个事务，然后在窗口2中再开始一个事务，窗口2中修改id=3的记录，再到窗口1中修改id=3的记录时，会报错，由此实现了SERIALIZABLE的隔离级别。

由此可见在SERIALIZABLE的级别上，PostGreSQL的并发会比MySQL好很多。

2. 锁

Postgresql  有三种锁：table-level, row-level and advisory
locks.

根据锁的类型分，可以分为共享锁，排他锁，意向共享锁和意向排他锁。根据锁的粒度分，又可以分为行锁，表锁。对于mysql而言，事务机制更多是靠底层的存储引擎来实现，因此，mysql层面只有表锁，而支持事务的innodb存储引擎则实现了行锁(记录锁)，gap锁，next-key锁。

Mysql的记录锁实质是索引记录的锁，因为innodb是索引组织表；gap锁是索引记录间隙的锁，这种锁只在RR隔离级别下有效；next-key锁是记录锁加上记录之前gap锁的组合。mysql通过gap锁和next-key锁实现RR隔离级别。

说明：
对于更新操作(读不上锁)，只有走索引才可能上行锁；否则会对聚簇索引的每一行上写锁，实际等同于对表上写锁。
若多个物理记录对应同一个索引，若同时访问，也会出现锁冲突；
当表有多个索引时，不同事务可以用不同的索引锁住不同的行，另外innodb会同时用行锁对数据记录(聚簇索引)加锁。
MVCC并发控制机制下，任何操作都不会阻塞读操作，读操作也不会阻塞任何操作，只因为读不上锁。