Module 05 TiDB 高级特性与企业级架构优化

本章节面向中大型企业多租户、混合负载（OLTP+OLAP）、性能调优、存储成本管控场景，分为 Lesson16、Lesson17、Lesson18 三节课，覆盖接入层代理、多租户资源隔离、数据生命周期存储优化、索引与性能观测，是支撑大规模生产集群稳定、低成本、高性能运行的核心能力，承接前面部署、同步、高可用基础模块，聚焦企业级复杂场景落地优化。

一、模块整体框架与定位

Lesson16 企业级流量路由与资源管控：接入层 TiProxy 代理 + RU 资源隔离多租户治理，解决业务连接、流量分发、资源争抢问题；
Lesson17 数据生命周期与存储优化：TTL 过期数据自动清理、TiFlash 内存落盘机制，管控存储成本、解决分析内存溢出；
Lesson18 性能观测与索引优化：索引使用观测、无用索引清理、分区全局索引，从 SQL 执行层优化读写性能。

整体目标：在集群高可用、数据安全基础上，实现多租户隔离、冷热数据分层、查询性能极致优化、资源精细化管控，适配金融、互联网、政企等大规模企业 TiDB 集群。

二、Lesson16 企业级流量路由与资源管控

1. 学习目标

掌握 TiProxy 官方代理组件架构、部署与核心能力；
理解 RU（Request Unit）统一资源计量模型；
学会 ResourceGroup 资源分组实现多租户资源隔离；
掌握 Runaway Query 逃逸查询管控，防止大 SQL 拖垮集群。

2. TiProxy 基础定位

2.1. 核心定义

TiProxy 是 TiDB 官方原生数据库代理组件，部署在客户端与 TiDB Server 中间层，核心提供负载均衡、连接保持、服务自动发现能力；

业务侧搭配虚拟 IP（VIP）提供统一接入地址，屏蔽后端 TiDB Server 集群细节。

2.2. 典型接入架构链路

应用 → VIP → 多实例 TiProxy 集群 → TiDB Server 集群

TiProxy 无状态设计，支持水平横向扩容；
多实例 + VIP 架构彻底消除接入层单点故障风险。

3. 三大核心能力

3.1. 连接保持

TiDB Server 滚动重启、版本升级、节点缩容场景下，TiProxy 自动将存量会话平滑迁移至健康 TiDB 节点，前端业务客户端连接不中断，实现运维操作业务零感知。

3.2. 智能负载均衡

依据后端 TiDB Server 连接数、节点运行状态做流量分发，均衡分配前端连接与 SQL 请求，避免单台 TiDB Server 负载过高，均衡集群接入层压力。

3.3. 自动故障摘除

实时探测后端 TiDB Server 节点健康状态，自动隔离异常故障节点；节点恢复正常后自动恢复流量转发，无需人工介入调整转发规则。

4. 核心落地应用场景

滚动升级 / 扩缩容业务无感 依托连接会话迁移能力，TiDB Server 版本迭代、节点上下线运维时，业务无断连、无报错，保障 7×24 业务稳定运行。
多 TiDB Server 统一接入与流量管控 收拢多台 TiDB Server 接入入口，统一管控前端流量、连接上限，简化集群接入层运维管理。
替代传统 HAProxy + 自定义运维脚本方案 官方原生适配 TiDB 协议与集群特性，无需额外自研脚本适配节点上下线、健康探测、会话迁移，大幅简化接入层高可用架构复杂度与运维成本。

5. 基于 RU 的 Resource Group 资源管控

5.1. 核心基础概念

RU(Request Unit)：TiDB 统一资源度量单位，标准化量化读写 SQL、后台任务消耗的 CPU、IO、网络等综合资源，规避不同业务资源口径不统一问题。
Resource Group 资源组：核心管控载体，可配置 3 项核心参数：
- RU_PER_SEC：每秒 RU 配额上限，限定资源组每秒最大可消耗资源；
- PRIORITY：任务调度优先级，高优先级任务在资源争抢时优先调度执行；
- BURSTABLE：弹性扩容能力，业务峰值可临时超额使用闲置集群资源，低谷自动回落。
租户隔离能力：数据库用户绑定资源组后，该用户所有 SQL 执行严格受资源组 RU 配额约束，实现多业务、多租户资源强隔离，避免业务互相抢占资源。
后台任务覆盖：支持对 BR 备份恢复、DDL 变更、统计信息采集等运维后台任务配置专属资源组，管控后台任务资源消耗，防止挤占前端业务资源。

5.2. 实操常用语句解读

-- 自动校准集群整体最大RU容量，获取集群基准资源上限
CALIBRATE RESOURCE;

-- 创建业务资源组rg_app，每秒RU配额10000、中等优先级、开启弹性扩容
CREATE RESOURCE GROUP rg_app
RU_PER_SEC = 10000
PRIORITY = MEDIUM
BURSTABLE;

-- 将业务用户绑定至对应资源组，生效资源管控规则
ALTER USER app@% RESOURCE GROUP rg_app;

6. Runaway Query 逃逸查询治理

6.1. 判定规则（QUERY_LIMIT）

通过设定判定阈值规则（典型如EXEC_ELAPSED执行时长、扫描行数、消耗 RU 总量等），SQL 执行超出阈值即判定为逃逸查询，触发预设处置动作。

6.2. 多维度处置 ACTION 策略

处置动作	作用说明
KILL	直接终止逃逸 SQL 会话，快速释放被占用资源
COOLDOWN	对该类查询做降级限流，后续同类查询延迟调度、限制资源分配
SWITCH_GROUP	将查询切换至低配额资源组，限制后续资源消耗上限
WATCH 规则	支持按 SQL 文本精准匹配，针对特定高危 SQL 单独配置治理规则

6.3. 业务价值

自动拦截慢查询、大表全扫、笛卡尔积等失控 SQL，避免单条异常 SQL 耗尽集群资源引发雪崩故障，保障核心业务稳定性。

三、Lesson17 数据生命周期与存储优化

聚焦冷热数据分层、过期数据自动清理、TiFlash 内存溢出防护两大存储优化方向，降低磁盘成本、稳定 OLAP 分析负载。

1. 行级 TTL（Time To Live）

1.1. 核心能力特性

按行过期自动清理 依托指定时间字段自动判定过期行数据，无需手动分区、定时清理脚本，原生后台任务完成过期数据删除。
执行机制 集群后台定时巡检任务扫描表数据，匹配 TTL 过期规则后异步删除行数据，对在线业务影响极小。
适配业务场景 日志表、流水记录、用户会话数据、临时时效业务数据等有明确生命周期的业务表。
管控参数
- TTL_ENABLE：全局开关，可临时暂停全集群 TTL 清理任务；
- TTL_JOB_INTERVAL：自定义后台巡检任务执行间隔，调整清理节奏规避业务高峰 IO 冲击。

1.2. 示例 SQL 解读

CREATE TABLE logs (
    id BIGINT PRIMARY KEY,
    created_at DATETIME,
    msg VARCHAR(255)
) TTL = `created_at` + INTERVAL 90 DAY;

规则说明：以created_at创建时间字段为基准，数据写入满 90 天后，自动被 TTL 后台任务清理删除。

2. TiFlash 数据落盘机制

2.1. 两类落盘触发逻辑

2.1.1. 算子级别落盘

针对 Join、GroupBy、Sort 等计算算子单独配置内存阈值，算子内存占用达到阈值时，自动将算子中间结果落地磁盘，防止单算子内存打爆节点。配套参数：

tidb_max_bytes_before_tiflash_external_join：Join 算子落盘内存阈值
tidb_max_bytes_before_tiflash_external_group_by：分组聚合算子落盘阈值
tidb_max_bytes_before_tiflash_external_sort：排序算子落盘阈值

2.1.2. 查询级别落盘

管控单条 SQL 在单个 TiFlash 节点的总内存上限，搭配溢出比例阈值，整条查询内存触达阈值后，按需对内部支持落盘的算子执行数据落盘。配套参数：

tiflash_mem_quota_query_per_node：单节点单查询内存配额上限
tiflash_query_spill_ratio：内存占比阈值，达到比例后触发查询级落盘

2.2. 机制核心价值

超大复杂分析 SQL（多表大 Join、海量排序聚合）执行时，避免内存溢出 OOM 导致节点宕机；
内存充足时优先内存计算保障查询性能，内存触顶自动降级磁盘计算，兼顾性能与集群稳定性；
精细化分层管控，可针对算子、查询分别调参，适配不同分析业务负载。

四、Lesson18 数据库性能观测与索引优化

面向 SQL 性能调优，提供索引使用监控、无用索引清理、分区表全局索引三大企业级优化特性，解决读写放大、分区唯一索引痛点。

1. 索引使用情况观测

1.1. 核心观测视图与工具

INFORMATION_SCHEMA.TIDB_INDEX_USAGE 系统内置视图，自动采集每条索引的访问次数、最近访问时间、扫描行数等运行统计数据，直观掌握索引真实使用频次。
sys.schema_unused_indexes 视图 快速筛选长期无访问记录的闲置索引，定位可清理冗余索引。
配套辅助分析手段 结合慢查询日志、Statements Summary SQL 执行统计，核对索引命中情况，判断索引是否生效、是否存在索引失效、隐式转换导致无法走索引等问题。

1.2. 观测核心价值

定期清理长期无用索引，减少写入链路索引维护开销（降低 INSERT/UPDATE/DELETE 放大损耗），同时节省集群磁盘存储占用。

1.3. 索引标准化治理建议

先观测、后删除 依托索引使用统计做长期观察，确认业务全周期无使用后再下线，避免误删低频刚需索引引发性能故障。
规避低效索引设计 杜绝重复索引、冗余前缀索引；联合索引遵循最左匹配原则，减少无效索引堆积。
优先使用覆盖索引 设计覆盖索引避免 SQL 回表查询，减少 TiKV IO 开销，稳定查询执行性能。

2. 分区表全局索引

2.1. 传统分区索引限制

旧版分区表约束：主键、唯一索引必须包含分区键字段，依靠分区边界天然保证分区内唯一性，无法实现跨分区全局唯一校验。痛点场景：订单号 order_id 全局唯一，但分区键为创建时间 created_at，传统模式必须把 created_at 加入唯一索引，破坏业务唯一字段设计。

2.2. 全局索引能力价值

全局索引通过语法GLOBAL修饰唯一索引，允许唯一索引字段不包含分区键，TiDB 底层保障全表跨分区数据全局唯一性，适配业务独立全局唯一字段场景。

2.3. 实操示例解读

-- 创建按创建时间范围分区的订单表
CREATE TABLE orders (
    order_id BIGINT,
    created_at DATETIME, ...
) PARTITION BY RANGE COLUMNS(created_at) (...);

-- 创建不包含分区键的全局唯一索引
CREATE UNIQUE INDEX uk_oid
ON orders(order_id) GLOBAL;

效果：order_id 字段在全表所有分区内强制唯一，无需将 created_at 加入唯一索引字段。

TiDB 高级特性与企业级架构优化（PCTP课程Module05）