MySQL是我们日常生活中常见的数据库，他的innodb存储引擎尤为常见，在事务方面使用的是扁平事务，即要么都执行，要么都回滚。而tidb数据库则使用的是分布式事务。两者都能保证数据的高一致性，但是在实现方式上是不一样的。
我们先来看看MySQL的事务机制，采用redo log机制来保证事务更新的一致性和持久性。那我们来看看innodb重做日志的内部机制。
当更新数据时，innodb内部的操作流程是：
而tidb数据库，在事务上采用的是乐观锁：
TiDB 使用乐观事务模型，在执行 Update、Insert、Delete 等语句时，只有在提交过程中才会检查写写冲突，而不是像 MySQL 一样使用行锁来避免写写冲突。类似的，诸如 GET_LOCK() 和 RELEASE_LOCK() 等函数以及 SELECT .. FOR UPDATE 之类的语句在 TiDB 和 MySQL 中的执行方式并不相同。所以业务端在执行 SQL 语句后，需要注意检查 commit 的返回值，即使执行时没有出错，commit 的时候也可能会出错。
TiDB 的事务模型采用乐观锁，只有在真正提交的时候，才会做冲突检测，如果有冲突，则需要重试。这种模型在冲突严重的场景下，会比较低效，因为重试之前的操作都是无效的，需要重复做。举一个比较极端的例子，就是把数据库当做计数器用，如果访问的并发度比较高，那么一定会有严重的冲突，导致大量的重试甚至是超时。但是如果访问冲突并不十分严重，那么乐观锁模型具备较高的效率。所以在冲突严重的场景下，推荐在系统架构层面解决问题，比如将计数器放在 Redis 中。