TiDB v7.1.1 升级至 v8.5.3 版本性能优化升级报告

一、升级基础信息

版本信息

原集群版本:TiDB v7.1.1

目标集群版本:TiDB v8.5.3(LTS 长期支持版)

升级执行时间:2026-06-11 完成全集群滚动升级

指标观测周期

升级前基线周期:05-14 ~ 06-10(近 4 周,稳定业务负载基准)

升级后验证周期:06-11 ~ 06-17(升级后一周,同业务并发对比)

观测维度

数据库总耗时、SQL 全链路解析 / 编译 / 执行耗时、应用连接、QPS 与异常 SQL、事务延迟、TiDB-TiKV 底层 RPC、PD 调度、存储写入全链路监控指标。

升级目标

依托 v8.5 内核重构优化,削减 SQL 长尾延迟、锁等待耗时,降低数据库整体负载;

优化执行计划缓存、悲观事务、批量扫描逻辑,减少重复硬解析与事务冲突;

收敛 TiKV、PD 底层 RPC 突刺延迟,消除批量查询、写入场景极端耗时尖峰;

本次升级核心动因:

(1)政务云资源扩容约束,无法通过硬件扩容解决性能瓶颈

集群部署于政务专属云环境,存在严格资源审批流程:服务器、内存、存储扩容申请周期漫长,流程复杂;受政务预算与资源配额限制,短期内无法新增 TiDB/TiKV 节点、扩容 CPU 与内存硬件。

原有 v7.1.1 集群在业务高峰时段仅靠现有硬件已无法承载查询压力,硬件扩容路径不可行,只能通过数据库内核版本升级挖掘现有服务器性能潜力。

(2)业务研发人力紧张,无法大规模开展 SQL 语句改造优化

当前研发团队重点保障业务功能迭代,无充足人力批量梳理、改写历史复杂慢查询;业务侧大量分页检索、多表关联统计接口短期内无法完成 SQL 重构、索引优化。

因此选择升级 TiDB 内核版本,依托 8.5.3 内置的执行引擎、计划缓存、批量扫描、悲观事务原生优化,不改动业务代码、不投入大量研发人力,自动降低慢 SQL 执行耗时,缓解高峰期数据库压力。

(3)原版本 7.1.1 业务高峰期慢 SQL 阻塞严重,影响多地市业务访问

高峰期大量地市检索接口产生超长耗时查询,截图为升级前早高峰慢 SQL 采样:

单条 SQL 最长执行 6 分钟,大量语句执行耗时 2~6 分钟,内存占用最高 878.8MiB;

并发查询叠加,长期占用集群计算、内存资源,引发数据库总耗时尖峰、锁等待、连接异常断开,多地市前端查询超时、页面加载缓慢。

如图:

二、升级前后核心监控指标对比分析

(一)数据库总耗时:全场景资源占用显著下降

按 SQL 类型总耗时(Database Time by SQL Types)

升级前(5.14-6.10)Select、Update 读写 SQL 周期性出现 25s 以上数据库耗时尖峰,读写操作长期争抢计算资源;

6 月 11 日升级完成后,同等 QPS 业务下峰值大幅压低,周期性突刺幅度降低 30% 以上,Select/Update 基线耗时持续走低。

根因:v8.x 重构批量 KV 请求、Coprocessor 下推逻辑,批量读取开销大幅缩减TiDB。

SQL 阶段拆解耗时(Database Time by SQL Phase)

集群核心耗时集中在execute执行阶段,升级前执行阶段频繁触发 25s 高耗时尖峰;升级后执行长尾尖峰基本消失,parse解析、compile编译、get token令牌校验耗时基线同步下压。

SQL 执行细分等待总耗时(SQL Execute Time Overview)

升级前悲观锁(PessimisticLock)、Scan 扫描、预写 Prewrite 存在多次超过 3.3 分钟极端等待尖峰;升级后长耗时突刺完全消除,悲观事务锁冲突、行扫描阻塞问题得到根本性缓解。

如图:

(二)应用连接:连接稳定性大幅提升,异常断连断崖下跌

连接总数 Connection Count

业务总连接数稳定维持 100~350 区间,升级前后并发连接基线无明显变化,业务负载持平,指标具备完全对比参考价值;

活跃连接(active connections)升级前偶发瞬时尖峰,升级后曲线全程平稳,新版本连接池闲置连接回收、复用逻辑优化生效。

客户端断开连接 Disconnection

6 月 11 日升级节点出现清晰分界:升级前各业务 IP 断连量持续高位波动;升级后全 IP 断开次数断崖式下跌,客户端异常重连、连接超时问题大幅改善,应用侧连接稳定性提升。

如图:

(三)SQL 吞吐与异常报错:失败 SQL 大幅减少,计划缓存命中率提升

每秒查询量 QPS(Query Per Second)

集群总 QPS 峰值稳定 700~800,Begin/Commit 事务语句占主要流量,升级前后业务查询并发无衰减,未出现吞吐降级。

失败 SQL Failed Queries

升级前 parser 解析器、planner 优化器、executor 执行器、unknown 未知错误持续高频周期性波动;升级后各类报错数量显著下降,优化器缺陷、语法兼容、执行异常尖峰高度大幅缩减。

执行计划缓存 Queries Using Plan Cache OPS

升级前缓存未命中avg-miss频繁出现超高尖峰,大量重复业务 SQL 触发全量硬编译;升级后缓存未命中突刺基本消除,缓存命中基线抬升。

如图:

(四)SQL 单阶段细分延迟:解析、编译、执行全链路收敛

Get Token 令牌耗时:平均耗时稳定微秒级,99 分位极端等待尖峰消失,权限校验逻辑轻量化。

Parse 语法解析耗时:升级后 99 分位解析曲线整体下移,大 SQL 解析开销降低,无持续走高趋势。

Compile 编译耗时:SQL 编译 99 分位峰值收窄,优化器代价估算、逻辑重写效率提升,单次编译耗时缩短。

Execute 执行耗时:执行阶段 99 分位峰值从 140ms 持续下降,批量扫描、Hash Join 执行引擎重构,多表关联、批量查询延迟降低最高 5 倍。

Transaction Per Second 悲观 / 乐观事务提交吞吐维持原有水平,高并发事务下集群处理能力无衰减。

Transaction Duration 升级前悲观事务 99 分位耗时峰值接近 800ms;6 月 11 日后悲观事务长尾延迟持续走低,乐观 / 悲观事务平均耗时基线同步下降,锁等待、预写、提交阶段阻塞大幅减少。

如图:

(五)TiDB-TiKV 底层存储 RPC 全链路长尾延迟消除

TiDB KV 请求耗时 Avg TiDB KV Request Duration

升级前BatchCop批量读取频繁出现 2s + 极端尖峰;升级后批量扫描长延迟突刺基本消失,MPP、批量下推读取性能优化生效,搭配 8.5 新增 MVCC 内存引擎优化热点多版本扫描场景TiDB。

TiKV GRPC 交互耗时 Avg TiKV GRPC Duration

升级前存在 60ms 以上 RPC 突刺;升级后节点间锁检查、副本同步、Coprocessor 交互延迟曲线平稳,网络交互抖动减少。

PD TSO 分配等待耗时 PD TSO Wait/RPC Duration

TSO 分配 99 分位等待耗时整体下移,高并发事务下 PD 调度压力降低,无长时间时间戳阻塞。

存储异步写入 Storage Async Write Duration

升级前单次 200ms + 写入尖峰消失,Raft 异步刷盘、副本 Apply 日志同步逻辑优化,写入长尾延迟大幅收敛,OLTP 写入性能提升约 27%。

Store 本地存储、Raft 副本 Apply 耗时

TiKV 本地读写、副本日志应用 99 分位峰值持续压低,Region 合并、小 Region 调度优化,底层 IO 抖动减少。

如图:

三、本次升级综合收益总结

  1. 性能量化收益

数据库整体总耗时峰值降低 30% 以上,SQL 执行、悲观锁等待极端长耗时尖峰基本消除;

SQL 解析、编译、执行全链路 99 分位长尾延迟全面下降,批量查询、多表关联查询速度提升显著;

悲观事务平均延迟、P99 长尾延迟大幅缩减,事务冲突、锁争抢阻塞频次明显减少;

执行计划缓存命中率提升,重复 SQL 硬编译 CPU 开销显著降低;

TiKV 批量扫描、Raft 写入、PD TSO 分配、节点 RPC 底层全链路极端延迟尖峰消除,集群 IO 与网络调度稳定性提升;

客户端异常断连数量断崖式下跌,各类 SQL 执行报错频次大幅减少,业务侧异常反馈降低。

四、升级最终结论

本次 TiDB v7.1.1 滚动升级至 v8.5.3 操作平稳,自 6 月 11 日升级完成后,一周全链路监控指标验证:在业务 QPS、事务并发量无明显变化的同等负载下,数据库总耗时、SQL 全链路延迟、悲观事务锁等待、TiKV/PD 底层 RPC 长尾延迟均实现大幅下降,SQL 异常报错、客户端异常断连数量断崖式减少,集群整体吞吐稳定性、业务查询响应速度全面提升。

本次版本升级完全达成预设性能优化目标,TiDB 8.5.3 LTS 版本对当前业务场景适配良好,内核优化解决了原 7.1.1 版本存在的长尾延迟、锁冲突、缓存失效、连接不稳定等痛点,集群具备长期稳定运行条件。后续将持续基于 v8.5.3 版本开展业务迭代与精细化运维调优,进一步挖掘集群性能上限。

3 个赞

看来新版本优化了挺多东西,在不进行SQL改造的情况下,紧靠升级版本就解决了 :+1:

1 个赞

这份 v7.1.1 升级 v8.5.3 LTS 的升级报告很有参考价值,政务云受限无法扩容、无力大规模改 SQL 的场景下,靠内核版本升级直接根治长尾慢查询、锁冲突、连接抖动等痛点,全链路指标改善明显,充分体现 8.5 长期支持版内核优化红利,滚动升级方案也平稳可靠,可作为同类政务 TiDB 集群升级参考范本。

1 个赞

本来也是没有报太大希望从技术侧能做的都做到。结果效果很好。每天业务高峰期的慢语句都不见了,客户端异常断开数量一下子降下来了。

但是你这个升级之前是怎么评估的?
本身是因为有性能问题进行的升级,在不改动SQL的情况下,升级新版本,又带来新的参数,既有可能变好,也有可能变坏。

TiDB主从数据库集群版本升级方案
一、升级概述
1.1升级基本信息
本次升级针对妇幼保健系统生产TiDB主从集群,集群共计20余台服务器,采用主从分层升级模式,保障业务平稳过渡、数据零风险。具体升级参数如下:
当前集群版本:TiDB v7.1.1(生产在线主从集群)
目标升级版本:TiDB v8.5.3
升级方式:停机整体升级,采用先从集群、后主集群分批升级模式,无组件版本共存,升级稳定性更高
升级范围:生产主从集群全组件(PD、TiDB、TiKV、TiFlash、TiCDC)、配套监控组件(Prometheus、Grafana)
验证资源:已向政务云申请3台临时服务器,用于搭建等同生产环境的验证集群
升级目的:修复7.1.1已知安全漏洞、优化内核性能缺陷,适配8.5.3新版SQL优化器、MDL元数据锁等核心特性,解决存量版本性能瓶颈与运维短板。同时适配妇幼保健系统业务迭代需求,全面提升主从集群稳定性、安全性、扩展性,保障妇幼诊疗、体检、档案、报表等核心业务长期稳定运行。
1.2升级核心原则
严格遵循:测试先行、验证兜底、分批升级、停机锁写、全量备份、静态升级、逐条校验、完整回滚、政务云协同。
1.优先完成政务云临时服务器全量验证,100%复刻生产环境与数据,验证通过后方可开展生产集群升级;
2.严格执行先从集群、后主集群分批升级策略,规避主从兼容问题,降低全域升级风险;
3.严格申请专属维护窗口,升级期间全量停止对应集群业务读写,杜绝数据写入与变更;
4.所有前置检查、备份验证、测试验证100%通过后,方可执行生产升级;
5.升级全程留痕、全程监控,联动政务云做好资源快照兜底,异常立即终止升级并启动回滚。
1.3关键时间节点
验证窗口期(截止11日前):完成政务云3台临时服务器环境部署、生产数据还原、全量升级验证,输出正式验证报告,完成生产升级前置准入;
生产升级窗口期:统一锁定11日-20日,由事业部确认最终精准升级时间,完成从集群、主集群分批升级及全量业务验收。
1.4版本兼容性与升级约束
官方支持 TiDB 7.1.1 跨版本直接停机升级至8.5.3,无需过渡版本,停机分批升级稳定性优于滚动升级;
升级强约束:单集群升级期间需完全终止对应集群业务、DDL任务、同步任务,保证集群静态无变更;
8.5.3默认开启MDL元数据强校验,升级前需完成全量元数据排查,规避升级失败风险;
升级后不支持直接降级,兜底方案为:备份还原+政务云快照还原+重装集群三重保障。
二、核心协调事项
2.1内部协调事项
事业部:11日前确定11-20日精准生产升级时间,同步运维、研发、客服部门;
事业部:提前完成妇幼系统业务停机通知、用户引导、业务变更冻结;
运维组:负责临时环境验证、生产备份、分批升级、全程监控;
事业部:安排人员进行业务升级后业务验证。
三、停机升级风险评估及专项规避预案
3.1业务停机风险及防控预案
风险1:维护窗口超时,业务中断超出预期(高风险)
规避处置:基于临时服务器演练数据精准预判升级时长,标准耗时基础上增加2-8小时应急缓冲;严格执行分批升级流程,超时立即终止、回滚恢复。
风险2:业务停写不彻底,残留任务导致升级异常(极高风险)
规避处置:分批关停从、主集群业务,清空会话、事务、DDL及同步任务,双人交叉核验集群静态状态。
风险3:升级后业务适配异常(中风险)
规避处置:临时环境全量复刻业务场景完成适配验证,生产升级后校验核心业务流程。
3.2数据安全风险及防控预案
风险1:跨版本升级元数据校验失败、集群启动异常(高风险)
规避处置:11日前完成临时环境全量升级验证,提前清理生产集群异常元数据、脏数据、异常Region。
风险2:备份失效导致无法回退(极高风险)
规避处置:执行BR数据、元数据、配置文件三重备份并完成有效性校验;新增政务云生产整机快照备份,作为终极兜底。
风险3:节点故障、网络异常导致数据损坏(中高风险)
规避处置:升级前巡检20余台集群服务器硬件、磁盘、网络,升级期间禁止硬件及网络配置变更。
3.3升级操作风险及防控预案
针对TiUP版本过低、资源不足、配置不兼容等风险,提前完成工具升级、资源清理、配置适配,所有操作均在临时环境演练验证通过后落地生产。
四、前置准备工作(含临时环境验证,11日前全部完成)
4.1政务云临时验证环境搭建与全量验证
依托政务云新申请的3台临时服务器,搭建与生产一致的验证环境,11日前完成所有验证工作,作为生产升级准入必要条件:
1.环境复刻:统一临时服务器操作系统、系统内核、依赖组件,完全匹配生产集群环境;
2.版本复刻:临时环境部署与生产一致的TiDB v7.1.1版本;
3.数据复刻:还原生产集群全量备份数据,完整复刻生产表结构、索引、数据量、权限、配置;
4.全流程演练:模拟生产停机状态,完整执行v7.1.1至v8.5.3停机升级全流程;
5.全维度验证:验证集群启动、元数据校验、数据一致性、SQL兼容性、业务功能、性能指标;
6.输出结果:11日前出具《临时环境升级验证结果》,无任何异常方可启动生产升级筹备工作。
4.2生产集群前置全量检查
完成20余台主从集群服务器拓扑梳理、硬件巡检、集群健康校验、异常任务清理、PD调度关闭,确保集群静态稳定。
4.3多重备份与政务云快照兜底
1.完成BR全量数据、系统元数据、全组件配置文件三重备份及还原校验;
2.新增政务云快照备份:升级窗口开启前,协调政务云对生产所有主从节点执行整机快照,锁定初始环境与数据状态,作为终极回滚兜底。
4.4工具、人员及业务前置准备
完成TiUP工具升级、8.5.3离线包分发、监控加固;落实全员在岗分工;提交停机申请,等待事业部确认11-20日精准升级时间。
五、生产集群分批升级实施流程(先从集群、后主集群)
生产集群共20余台服务器,严格按照先从集群、后主集群的分批升级逻辑执行,规避主从版本兼容冲突,最大限度降低业务风险。
5.1升级前最终核验
确认临时环境验证通过、三重备份+政务云快照完整有效、业务全停、资源工具就绪、人员在岗、精准维护窗口生效。
5.2第一阶段:从集群停机升级
1.停止从集群所有组件服务,关停从集群关联同步、读写任务;
2.执行从集群升级前置校验,排查适配问题;
3.执行从集群v7.1.1跨版本升级至v8.5.3;
4.启动从集群,等待节点上线、Region恢复、集群初始化完成;
5.完成从集群版本、健康度、数据一致性、元数据全量验收。
5.3第二阶段:主集群停机升级(从集群验证通过后执行)
1.确认升级后从集群运行稳定、无异常,再停止主集群服务、清空业务任务;
2.执行主集群前置校验、跨版本升级、集群重启初始化;
3.主从集群全部升级完成后,核对主从同步状态、数据一致性。
5.4升级后全维度验收验证
完成分批升级后,执行全维度分级验证,确保集群、数据、业务、性能全方位正常:
1.版本验证:确认主从集群所有组件均成功升级至v8.5.3,版本统一无差异;
2.集群健康验证:20余台节点全部在线,Region健康、无异常副本、无调度报错;
3.数据一致性验证:核心妇幼业务表全量校验,主从数据同步一致、无丢失、无错乱;
4.元数据验证:库表、索引、权限、视图、参数配置完全兼容,MDL校验无异常;
5.性能验证:对比升级前后QPS、延迟、慢SQL、资源占用,无性能退化,新版特性生效;
6.业务全量验证:灰度放开流量,验证诊疗、档案、体检、报表、接口等核心业务全流程正常;
7.主从同步验证:确认主从集群同步正常、延迟为0,数据实时一致。
5.5升级后优化与监控
适配8.5.3新版参数优化集群配置,清理冗余文件,24小时全天候监控主从集群运行状态,排查隐性隐患。
六、应急预案与政务云兜底回滚方案
6.1应急总体原则
升级异常立即终止操作,短时间无法修复则优先启动回滚,依托数据备份+政务云整机快照+集群重装三重兜底,保障数据零丢失、业务快速恢复。
6.2常规异常即时处置
针对升级进程中断、节点启动失败、数据异常、业务报错等问题,立即暂停操作,定位问题,超时未修复启动全域回滚。
6.3终极兜底回滚方案
适用场景:主从集群升级失败、集群异常、业务不可用、短时间无法自主修复
1.终止所有升级进程,停止主从集群异常服务,冻结现场状态;
2.政务云协同应急:第一时间对接政务云运维,调取升级前生产节点整机快照;
3.优先执行政务云快照还原,将所有生产服务器还原至升级前初始稳定状态;
4.快照还原异常兜底:协调政务云协助清空环境,重新部署TiDB v7.1.1原始集群环境;
5.通过前置全量备份还原数据、配置、权限,恢复主从集群正常架构;
6.校验集群健康、数据一致性、主从同步状态,确认完全恢复至升级前水平;
7.逐步恢复业务流量、定时任务、同步任务,完成业务全量恢复与验收。
七、升级交付与复盘总结
升级完成后出具正式验收报告,留存全流程操作日志、监控数据、校验记录;组织复盘,优化升级流程与风险防控机制,沉淀妇幼系统TiDB主从集群跨版本升级标准化方案。

2 个赞

我们提前两周进行方案制定与验证,同时这个8.5.3版本是我们在其他业务上再用的版本排除了升级后有不兼容的异常情况。

POC测试最重要,拿真实业务数据和查询模式跑几天。

我们当前使用也是7.1.1,这个报告对于我们来说很有价值呀

总结的不错, 学习了

学习学习

学习学习了。

看来新版本优化了挺多东西,在不进行SQL改造的情况下,紧靠升级版本就解决了