项目事故
在数据库写了一个定时任务，由于某些原因错误的把表内的历史数据当作正常数据写入了表，造成表内数据量飞快增长，一天后才发现定时任务出错了，数据量已经增长到了2400万条数据了。
今天发现系统特别慢，也没有排查到原因。突然有用户说系统的状态数据不正确，才确认是定时任务内的数据造成了状态异常。
幸运的是这个表的数据是只有插入，没有修改和删除操作。只需要把异常的数据删除掉即可。
确认了一下需要删除的数据有2400万条。以后找工作，再问是否有千万的数据操作经验，你看这不就来了吗？
我很着急，我很着急，想尽快把事故处理掉。
delete删除
首先用delete根据条件删除
由于发现事故的时候，首先对所有的异常数据进行删除。
delete from table where remark like '来源于database.dbo.%' and tableid is null 但是数据量太大了，如果直接删除，整个系统将会卡住，很长时间不能使用。
根据特定编码删除
发现上面方式行不通后，通过特定编码条件进行删除，
delete from table where remark like '来源于database.dbo.%' and tableid is null and code='123456'生成一批删除语句，批量执行
select top 1000 code,count(1),
' delete from table where remark like ''来源于database.dbo.%'' and tableid is null and code='''+code+'''; '+Char(13)+Char(10)+' ' from table where remark like '来源于database.dbo.%' and tableid is null
group by code执行了几次后，发现执行的特别慢。100条数据也需要大概1分多钟的时间。
根据ID删除
发现上面方式太慢后，确定根据ID删除。由于ID是自增的。而且是主键。删除理论上应该会快很多。
select top 100000 id,
' delete from table where id='''+Cast(id as nvarchar(100))+'''; '+Char(13)+Char(10)+' '
from table with(nolock)
where remark like '来源于database.dbo.%' and tableid is null 删除10万条数据，在30秒到1分钟之间。速度的确快了很多。
但是2000/10=200 最少还需要200次的手动操作，大约200分钟，也就是3个多小时，才能删除完成。
而且删除10万次也不稳定，执行几次后，会出现内存溢出等问题。
操作几次后，我更着急了，快抑郁了，不知道改怎么办，这种方式感觉有点蠢，3个小时真的很煎熬。
把复制改名
思路：
把正确的数据复制到一个表中，然后把原来的表改名成table_source,把复制的数据改名为原来的表名。
--把原表重命名
EXEC sp_rename 'tablename', 'tablename_Source';
--把正确的表重命名为原来的表明
EXEC sp_rename 'tablename20240724', 'tablename';结果这个表进行了发布订阅。需要先取消订阅。
不知道怎么取消订阅，就换了个方式对备份数据进行清空后，删除原来的表，在重新创建。
我很着急，都要疯了。
重新创建表
对整个表进行备份。
select * into table20240723142500 from table with(nolock)然后把正确的数据复制到一个新的表里面
select * into table20240725
from table with(nolock)
where id not in (
select * from table_error_ids
)清空当前表的数据
truncate table tablename;删除这个表
drop table tablename;把正确的数据复制回到原表
select * into tablename from table20240725 with(nolock)理论上这样一顿操作后，数据应该是正确的了。
结果由于订阅发布了，truncate和drop不能操作。
取消订阅
数据库服务器->复制->本地发布->找到发布的数据库
然后取消对于上面要操作表的发布订阅。
然后再次执行【重新创建表】的逻辑。
执行成功。2000多万行数据都删除了。
最后确认一下主键ID是否自增；数据是否正确性；订阅重新添加订阅。
整个项目事故就处理完了。
轻松了，跟用户确认了一下数据，完全正确。
长长的呼了一口气。