Mvcc机制

• 一张表，多个用户同时读取数据。（读读）
• 一张表，一个用户读数据，一个用户写数据。（读写）
• 一张表，多个用户同时写数据。（写写）

而第二种情况之前有一种很简单粗暴的解决办法，就是加锁但是这样的效率很低，而mvcc机制则是将表中每次更改的记录都保存下来，如果有多个用户进行读写操作，那么读数据的用户所看到的只会是历史数据。执行写操作的用户只要事务没有提交，在事务中所执行的变更对于其他用户来说都是不可见的。

• 一致性：一个事务的执行不能破坏数据库的完整性和一致性，比如如果从A账户转账到B账户，不可能因为A账户扣了钱，而B账户没有加钱。
• 隔离性：是指多个事务并发执行时，应该是互相隔离，不可相互干扰。此性质下文会详细解释。
• 持久性：是指事务一旦提交数据就必须永久保存，就算遇到系统或者服务器的故障也不会丢失。

• 读未提交 Read uncommitted

  这个级别可能会遇到一个问题“脏读”，就是a事务中读取到了b事务中更改的数据，此时b事务回滚a事务读到的数据最终未被更改。而a事务后续所有基于这个数据的操作都是错误的。这个就是脏读。

• 读已提交 Read committed

  这个级别不会出现脏读的问题，但是重复读的时候可能会发现多次读取的结果不一样。

  举个例子a事务有两个查询x表的数据，第一次查询值为1。此时b事务执行update修改x表值为2。a事务的第二个查询的值就是2。

• 读可重复 Repeatable read

  该级别解决了读已提交的不可重复读的问题，在事务开启的时候，不能再修改操作了，直到该事务提交。（此时的不能修改值得是在事务中修改了也不会生效）。

  举个例子a事务有两个查询x表的数据，第一次查询值为1。此时b事务执行update修改x表值为2。a事务的第二个查询的值还是1。明明已经被修改但是查询的结果还是未修改的的值，类似这样的结果就是幻读。（在gp中此隔离级别不会出现幻读）

• 序列化 Serializable

  在该级别下，事务是按照串行化的顺序执行，可以避免脏读，重复读，幻读。虽然可以避免以上的几种问题但是此级别的效率可想而知是非常低的。

在greenplum中每一行数据，有4个隐藏字段。虽然这四个字段是隐藏的，但可以访问。

• xmin ：在创建（insert）记录（tuple）时，记录此值为插入tuple的事务ID。
• xmax ：默认值为0.在删除tuple时，记录此值。

• cmin和cmax ：标识在同一个事务中多个语句命令的序列值，从0开始，用于同一个事务中实现版本可见性判断。

建表：