TiDB v7.5 分区索引、HTAP、运维工具多模块底层机制疑问

🪐 TiDB 技术问题
1

【TiDB 使用环境】测试环境（原理学习验证场景）
【TiDB 版本】v7.5.0
【部署方式】机器部署
【操作系统 / CPU 架构 / 芯片详情】Linux x86_64
【机器部署详情】通用测试服务器配置
【集群数据量】测试样本数据
【集群节点数】PD×3、TiKV×3、TiDB×2、TiFlash×2

【问题复现路径】
学习TiDB相关知识，结合v7.5官方文档梳理架构、索引、HTAP、运维工具相关知识点，多个机制边界场景缺少直观对比结论，希望和社区同学确认底层原理。

【遇到的问题：问题现象及影响】
无线上业务故障，属于理论知识点辨析，存疑方向：

  1. 分区表 Local Index / Global Index：底层Key编码差异；表达式前缀全局索引统计信息自动收集限制；TRUNCATE PARTITION 对全局索引的影响；分区表未声明GLOBAL时索引默认类型。
  2. 资源管控两套参数协同逻辑：resource-control.enabled 与 tidb_enable_resource_control 不同组合下集群行为。
  3. TiFlash内存落盘机制：查询级、算子级两层落盘阈值优先级；存在可落盘算子情况下依然内存超限的诱因。
  4. TiUP集群运维：不停机滚动升级操作边界；集群标准组件启动顺序；TiFlash在线缩容前置条件。
  5. 数据迁移&备份工具场景区分：Lightning Logical/Physical导入模式限制；BR、Dumpling、sync-diff-inspector、DM各自适用场景与约束。
  6. TiCDC、Raft高可用：TiCDC同步对表索引的硬性要求；Raft多副本模式下机柜、多数据中心故障容忍逻辑；两地三中心架构特点。

【资源配置】学习测试集群，暂无TiDB Dashboard主机截图
【复制黏贴 ERROR 报错的日志】无业务报错
【其他附件：截图 / 日志 / 监控】无

2

自己先梳理一部分理解，抛出来供大家指正：

  1. 分区表不添加 GLOBAL 关键字时，分区索引默认是 Local Index；全局索引的 key 编码会携带 TableID，PartitionID 存放于 value 端。
  2. resource-control.enabled=true、tidb_enable_resource_control=OFF 场景：仅 TiKV 采集 RU 资源消耗，TiDB 侧不做请求限流与资源组调度。
  3. TiFlash 内存管控优先级：查询级阈值优先于算子级阈值；即便存在可落盘算子，如果其他算子占用大量内存，依然会触发内存超限报错。
4

TiDB 无法自动正常收集 Global 表达式索引、前缀索引的统计信息

  1. ANALYZE TABLE t; 全局分析不会对这类 Global 索引生成有效统计；
  2. ANALYZE TABLE t INDEX global_expr_idx; 手动指定索引收集，估算依然存在偏差；
  3. 底层原因：Global 索引物理存储独立，表达式求值、字符串前缀截断逻辑与 TiDB 现有跨分区采样模型不兼容；
  4. 风险：优化器基数估算不准，极易产生劣化执行计划。

建议：尽量规避 GLOBAL INDEX + 表达式索引 / 前缀索引。

5

感谢大佬分享

6

TRUNCATE PARTITION 只会删除分区内的行数据；全局索引里残留该分区对应的索引条目。
v7.5 需要手动执行 ADMIN CLEANUP GLOBAL INDEX 清理孤儿索引；

7

关于分区表索引：v7.5默认是LOCAL索引，除非显式声明GLOBAL。LOCAL索引的Key编码包含分区ID，GLOBAL则没有。TRUNCATE PARTITION会直接删除对应分区数据，GLOBAL索引不受影响但统计信息会过时，建议TRUNCATE后手动ANALYZE TABLE。

资源管控两套参数：resource-control.enabled是系统变量控制资源管控功能开关，tidb_enable_resource_control是session级变量。

8
  • 算子落盘为批量刷盘机制，存在内存缓冲区，瞬时流量尖峰直接击穿 hard 阈值；
  • 一条 SQL 同时存在 Join+Sort+Agg 多个重型算子，单个算子未超限，叠加总内存打满查询上限；
  • 多条并发分析 SQL 共享 TiFlash 进程内存池，单条 SQL 合规，进程整体内存耗尽触发系统 OOM；
  • TiFlash 落盘磁盘 IO 瓶颈，数据刷盘速度小于内存数据生成速度，内存持续上涨击穿阈值。
9

是的,落盘机制并不能保证绝对不 OOM

11

感谢大佬分享

12

全局索引与局部索引编码和作用域不同；表达式前缀全局索引统计收集能力有限。Lightning 物理导入对目标表状态更苛刻；BR 偏集群恢复，DM 适合库表迁入持续同步。资源管控两参数需同向开启才完整生效。