大家好，我是架构摆渡人。这是实践经验系列的第七篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。今天给大家分享一个容易忽略的问题，正是因为容易忽略，所以才要重视。我们的业务表中有两个字段是必不可少的，分别是创建时间和修改时间，这样就知道数据是什么时候创建的，最后一次的修改时间是什么时候。就是经常会在修改时间上看到这个语句ON UPDATE CURRENT_TIMESTAMP，SQL语句如下：
`update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
也就是说update_time这个字段不需要我们手动去维护，只要这行数据有修改，就会自动更新update_time，非常方便的一个功能。但这个功能如果没用好，是很有可能带来严重的问题，下面给大家介绍下会带来什么问题？在某个业务场景下，会使用update_time来进行范围查询，也就是查询增量更新的数据。正常情况下是没有问题的，功能也跑了很久。突然有一天，这个查询大量报错，SQL都是超时的情况，并且影响了其他的业务，因为都是慢SQL。通过SQL执行计划，发现update_time范围查询最近一天的数据，扫描行数达到了上千万，你说能不超时么？问题是之前都没问题，突然就出了这个问题，是不是SQL写错了？其实没有，只是因为update_time范围内确实有这么多数据。另一个问题来了，为什么一天内有这么多数据变更呢?经排查，刚好有一个需求需要对老数据进行清洗，刚好update_time又是ON UPDATE CURRENT_TIMESTAMP，所以变更了的数据都会更新update_time，从而导致业务查询异常。
以后凡是对于老数据清洗，除了更新要清洗的字段之外，还需要更新update_time为原先的值，这样就不会影响业务。
update table set name=xxx,update_time=update_time where xxx=xxx
update_time如果加了ON UPDATE CURRENT_TIMESTAMP如果有业务查询需求，就要慎重考虑是否可以使用，最好还是单纯的作为数据的系统变更时间。业务变更时间还是由程序去控制，单独加一个业务变更时间字段，这样即使清洗数据时update_time变了也不影响业务。
大家好，我是从古代穿越过来的美男子：架构摆渡人。我将把我的武功秘籍全部传授与你们，觉得有用请分享给身边的朋友。来个三连吧，感谢各位！另外我还在B站录制了《真实订单业务，亿级数据带你实战分库分表》的实战课程，记得去学习哦！
