【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】
ALTER TABLE move_call_tx_new REORGANIZE PARTITION pmax INTO (
→ PARTITION p202603 VALUES LESS THAN (1775001600000),
→ PARTITION p202604 VALUES LESS THAN (1777593600000),
→ PARTITION p202605 VALUES LESS THAN (1780272000000),
→ PARTITION p202606 VALUES LESS THAN (1782864000000),
→ PARTITION p202607 VALUES LESS THAN (1785542400000),
→ PARTITION p202608 VALUES LESS THAN (1788220800000),
→ PARTITION p202609 VALUES LESS THAN (1790812800000),
→ PARTITION p202610 VALUES LESS THAN (1793491200000),
→ PARTITION p202611 VALUES LESS THAN (1796083200000),
→ PARTITION p202612 VALUES LESS THAN (1798761600000),
→ PARTITION p202701 VALUES LESS THAN (1801440000000),
→ PARTITION pmax VALUES LESS THAN (MAXVALUE)
→ );
【遇到的问题：问题现象及影响】
多个表获取锁超时，非分区表
Lock wait timeout exceeded; try restarting transaction
集群状况看是有一台机器cpu打满了，最后这条sql是手动kill掉的
【资源配置
【附件：截图/日志/监控】
请问是哪个版本的问题？
集群的部署情况是什么样的？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
这个可以发一下
-
执行
ALTER TABLE move_call_tx_new REORGANIZE PARTITION pmax INTO (...)操作时， 仅会复制 pmax 分区 ，但如果表存在 全局索引（GLOBAL Indexes） ，则需要同步更新全局索引，这可能导致 CPU 资源消耗过高及锁等待超时。 -
对于大表（如日增 3 亿行的表），直接使用
ALTER TABLE t PARTITION BY会重组整个表，成本极高；建议通过脚本提前准备分区，例如每月执行一次REORGANIZE PARTITION操作，避免一次性处理大量数据
感谢感谢，确实存在全局索引，但是pmax这个分区中，是没有任何数据的
会不会是 空分区 REORGANIZE 引发锁超时 + CPU 打满，先查锁持有情况，考虑临时规避该操作～
如果是低版本的话，可以升级一下版本，新版本对分区表和 DDL 的性能做了大量优化
楼主已经8.5.1版本，不建议用升级来解决问题。
基本上每个分区表都可能存在全局索引的现象，这种索引特别容易引起更新索引引起的性能问题
但我确实不理解为啥处理一个空的分区，会触发全局索引的更新，感觉处理的有点呆
有全局索引维护相当麻烦，新版本不知是否支持异步处理了？
有没参考文档?
如果一个表有3亿数据,每天新增300万, 是否算大表呢? 可不可以执行这种操作?
新版本应该会优化这个问题
可能就是全局索引的问题吧
TiDB 执行 REORGANIZE PARTITION 会触发全局 schema 锁并大量消耗资源，导致包括非分区表在内的其他事务因锁等待超时，建议避免在高峰期操作大表分区重组，或拆分为低影响的增量步骤。
版本问题吧，这个如何解决的
这个最后怎么解决的
查一下锁的进程，然后Kill掉
ALTER TABLE move_call_tx_new ADD PARTITION (
PARTITION p202603 VALUES LESS THAN (1775001600000)
);