干货满满，受益匪浅
实践案例很有参考价值
实践出真知，感谢分享实战经验
技术细节讲得很清楚，学到了！
mark~~
DELETE 慢即使有索引，也可能是：1）条件未走索引或回表量大；2）大量行锁/事务冲突；3）触发 compaction、clog 刷盘；4）分区表跨分区删。建议 EXPLAIN 看执行计划，确认走索引且 rows 合理；分批 DELETE + 小事务；检查 memstore/major 是否堆积；看是否有外键、触发器。大表删除优先按主键/索引范围分批，低峰执行并调大 ob_query_timeout 仅作辅助，根因仍在计划与锁。
收藏了
写得很详细
写得很详细
收藏了
DELETE 慢即使有索引，在 OB 中常见几个原因：
- 查看执行计划：
EXPLAIN DELETE FROM t WHERE ...;
确认是否走了索引。如果是全表扫描则说明条件没命中索引或统计信息不准。
- 大事务锁开销：如果一次 DELETE 影响行数很多（比如几十万行），OB 会在内存中维护大量行锁和 undo 信息，导致变慢。建议分批删除：
DELETE FROM t WHERE condition LIMIT 10000;
-- 循环执行直到 affected_rows = 0
-
索引维护开销：表上如果有多个二级索引，每删一行都要同步维护所有索引。索引越多 DELETE 越慢。可以用
SHOW INDEX FROM t检查是否有冗余索引。 -
转储/合并压力：如果 MemTable 写满频繁触发 minor freeze，DELETE 会被反压变慢。查看：
SELECT * FROM oceanbase.GV$OB_MEMSTORE WHERE tenant_id = xxx;
看 active_memstore 是否接近上限。
- 统计信息过期：手动收集一下统计信息后再试：
CALL dbms_stats.gather_table_stats('库名', '表名');
建议先 EXPLAIN 看执行计划，再根据影响行数决定是否分批执行。
感谢分享！
感谢分享！
干货满满，受益匪浅
66666
实践案例很有参考价值
内容很好
写得很详细
文中提到的OceanBase问题很常见，通过优化or和调整OB配置，通常可以解决。
技术细节讲得很清楚，学到了！