【 TiDB 使用环境】TIDB serverless
下午的时候误操作，直接把产品核心的用户表给批量错误更新了，下面是记录数据还原和修复的过程和经验总结，希望帮到大家。
1:发现错误更新数据后，第一时间需要修改GC时间避免数据被垃圾回收掉，从而需要更复杂的还原办法，或导致历史数据记录丢失，所以抢救数据时间最重要。
SHOW VARIABLES LIKE ‘%tidb_gc_life_time%’; 默认10分钟。
SET GLOBAL tidb_gc_life_time=‘48h’; 先将数据垃圾回收时间修改为48小时，争取抢救时间。
SET GLOBAL tidb_gc_life_time=‘30m’; 数据恢复后修改为30分钟，后期会有更多的抢救时间。
2:确定数据错误操作的具体时间，如果发现时可以及时记录执行的时间，这个非常重要，否则通过历史日志查询确定更新的时间戳会非常麻烦。
SELECT NOW(); 这里的时间是以数据库的时间，然后下列语句TIMESTAMP '2025-01-25 08:30:00’的日期比我们updata操作的时间更早即可。
3:查询修改更新前的历史版本数据，核对数据是否正确，行数是否正确。
SELECT * FROM plug_user AS of TIMESTAMP ‘2025-01-25 08:30:00’;
4:准备空表，将历史数据另存写入。如果数据较少，客户端查询结果的数据，以INSERT INTO的格式复制数据，然后粘贴到新的SQL对话框中，修改旧表名到新准备的空表中，然后逐行写入错误更新的历史版本数据，逐行写入比较慢。
INSERT INTO … + SELECT * FROM plug_user AS of TIMESTAMP ‘2025-01-25 08:30:00’; 经过测试，这样的组合无法写入数据。
INSERT INTO amztrends_plug_prod.plug_user_nnn (id, email, phone, nick_name, store_name, password, status, create_time, update_time, user_type, expires_time, vip_type, invite_code, bind_invite_code, mark) VALUES (3154637, NULL, ‘13600000000’, ‘amz_00000’, NULL, ‘JjU9KE4Y28xW’, 0, ‘2022-02-19 00:17:48’, ‘2022-02-19 00:17:48’, ‘normal’, NULL, NULL, ‘4NA2L2SI’, NULL, NULL); 目前我是通过这样的方法写入的，其他方法大家可以自行测试和研究。
5:已更改表的数据再次更新，修复数据，选择需要更新的列，其中id作为主键是必须写在前面的。这样在复制为UPDATE语句的时候，会自动的识别并生成以id为主键的更新语句。
SELECT id,user_type,expires_time,vip_type,mark FROM plug_user AS of TIMESTAMP ‘2025-01-25 08:30:00’;
UPDATE amztrends_plug_prod.plug_user SET user_type = ‘normal’, expires_time = NULL, vip_type = NULL, mark = NULL WHERE id = 3154637;
