问题描述
MySQL中对于UPDATE_TIME字段我们有时候会设置ON UPDATE CURRENT_TIMESTAMP，表示在数据库数据有更新的时候UPDATE_TIME的时间会自动更新（如果数据库数据值没有变化的话，UPDATE_TIME是不会自动更新的）。那么假设一个场景，我们有一个长事务有10秒，在进入事务第2秒的时候我们执行了一个update操作，然后往下继续执行，直到第10秒，事务提交。此时数据库记录的时间是执行update的时候的第2秒的时间点呢？还是事务提交后的第10秒的时间点？
验证结果
事务提交完成后，保存到数据库的时间是执行update的第2秒的时间点。
场景限制
如果UPDATE_TIME只是用来记录更新时间，那么这个自动更新的时间点倒是没有什么影响。但是如果想要用UPDATE_TIME来作为数据同步（比如同步到另一个库，或者es之类的）的依据，那么就不能够这样定义。因为我们使用UPDATE_TIME作为更新，一般也是要求准实时同步，假如一个事务比较长，在事务还没提交过程中我们已经记录了更新的时间，等事务提交后，这个UPDATE_TIME的时间我们是没有同步到的。
举个栗子：一个长事务的开始时间为12:00:00，结束时间为12:00:10，在12:00:02的时候执行了update操作，此时数据库的UPDATE_TIME的时间还是12:00:00，因为事务还没提交。
与此同时有个定时任务在扫描这段时间内的数据，比如12:00:00到12:00:03，没有数据，因此将12:00:03记录下来，下次从这个时间点继续往后扫描，等12:00:10时长事务提交，此时数据库中该条数据的UPDATE_TIME值为12:00:02，但是定时任务扫描不会再扫描中这条数据了，就会导致同步数据不完整。对这种情况，我们只能够在程序中进行设置UPDATE_TIME的值，而不应该通过数据库本身设置ON UPDATE CURRENT_TIMESTAMP。
