【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1.0
【复现路径】无，专用集群，每天中午跑任务（replace into）期间会有TiKV CPU 负载过高报警
【遇到的问题：问题现象及影响】
历史包袱，研发使用大量Replace into刷数据；发现运行任务期间出现所有 tikv节点CPU达到90%
1、大量（百万级别）replace into与cpu飙升是否有直接关系？
2、除程序端改造替代Replace外，是否有其他办法解决此问题。
tikv实例总共有多少核？
replace既要查询又要写入cpu使用高是预期内的。
replace into 后边跟的是 values 还是 select ，直接 replace into 跟 select 的话，我觉得还好吧，并发多少啊
发一下基本配置信息
replace into 后是select还是values? cpu飙升说明replace sql中有消耗cpu的的的部分，应该优化replace
你这应该属于正常现象，毕竟段时间内大数据量要处理，出现cpu负载高是正常的。如果想要降低负载，可以尝试增加节点试试
发下SQL和执行计划
需要看一下访问计划
严重怀疑走表扫了
多发点信息，这点看不出来啥
和 mysql 一样的逻辑，需要先 select 后判断是 insert 还是 update，相比单纯 insert/update cpu 高是正常的
信息不是很完整 看不出来什么
很多业务场景都能正常用到replace方式插入更新数据。
楼主你的问题核心点不在于replace，而在于业务访问的规模、流量以及业务SQL情况。所以需要重点排查为什么TiKV CPU负载很高，通常来说是因为有大量的数据发生读取、写入，可以重点查看Dashboard面板，确认集群热力图情况，结合SQL语句分析、慢查询模块，找到对应SQL，再结合业务访问情况优化。
replace into在有主键或唯一索引冲突时，会执行delete+insert操作
对CPU影响肯定大
8c 64G，单实例部署
是的，发现负载高期间，有其他服务的全表扫描；
目前排查replace into（百万级数据量）和全表扫描资源争抢；符合大佬给出的问题处理思路；
额外问题：对于每天都有大量（百万级）数据replace into 有啥建议？ (也是回归主题，能否减少replace into带来的负载高问题。)
ps：研发刚接手此服务，还在跟研发要SQL和场景
楼主这里每天百万级别的replace写入，其实并不高，很多用户每天写入都在亿行级别以上的，集中在某个时段的任务也有很多是几百万、几千万行的写入的。
这里的建议是需要搞清楚整个集群有哪些业务，这些业务是什么访问方式、对集群的资源使用情况如何，你弄清楚这些之后，就可以对高消耗资源的业务安排错峰运行。
鉴于楼主用的是 v7.1.0 版本，如果全部业务都不允许改变运行时间，就是无法避免会一起集中运行，那么还可以使用 资源管控功能，实现不同业务的资源使用隔离，避免相互挤兑和干扰影响。这里可以参考我之前整理的文章：专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区
专栏 - 如何构建更稳定高效的TiDB多租户系统 | TiDB 社区
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。