工程实践 TiDB 社区博客 - 实践案例 2026/09/28
文章复盘某区县级政务云 TiDB 6.5 集群的线上事故：凌晨批量对账把约 4000 行更新包在单个大事务中，提交时间从 30 秒拖到 9 分钟，锁长期不释放，拖垮白天查询。作者用 Grafana 指标、慢日志、cluster_transactions 和 tidb-trace 定位根因，即大事务跨 200 多个 Region 放大两阶段提交开销，叠加热点 biz_no 形成写热点 Region 排队。处理分三步：拆成每 200 行一个小事务、主键加随机分片位打散热点、调整 txn_commit_batch_size 与 txn.max-commit-txn 并错峰调度。改后单事务锁持有时间降至 15 秒内，热点 Region 冲突从数千降到个位数，TiKV CPU 回落到 55%。其排障顺序与拆分思路可迁移，但结论源于单一政务云场景和特定版本，参数调整仍需结合集群规模评估。
推荐收录，因为文章完整呈现了从监控指标异常、捞取长事务、链路追踪到根因归因与效果验证的排障闭环，并给出拆分事务、热点打散、参数兜底三刀的具体做法和量化结果。对使用 TiDB 等分布式数据库、需要写批量任务或排查锁等待与热点 Region 的工程师有直接迁移价值；但结论基于特定版本与政务云规格，参数调整需结合自身集群验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/23
文章复盘一个城市大脑 IoT 实时写入项目在 TiDB 6.5 上的写入性能雪崩排查。上线两周后批量写入超时、QPS 从 8k 降至 3k、单个 TiKV CPU 达 90% 而其余空闲，并频繁出现 Region is hot 告警。作者用 pd-ctl region top write 定位到某 Region 占全集群 70% 以上写流量，根因是 AUTO_INCREMENT 单调递增主键使新行持续写入尾部 Region。采用 SHARD_ROW_ID_BITS=4 与 PRE_SPLIT_REGIONS=4 重建表并迁移后，延迟回到 5~8ms；7.x 可改用 AUTO_RANDOM。文末总结高写入表设计、热点观察、压测需模拟真实分布等建议，但属于单一集群案例，未展开其他热点类型与迁移成本。
推荐收录。文章给出从告警、指标异常到 pd-ctl 热点定位、根因解释、表重建与迁移验证的完整闭环，证据具体且可复现。对使用 TiDB 或分布式数据库的工程师，自增主键导致写入热点、SHARD_ROW_ID_BITS 打散和压测需覆盖真实写入分布等结论可直接迁移；但结论主要适用于 TiDB 6.5 单集群，其他系统需自行验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/18
文章整理山东腾安信息的 TiDB 实践：政务协同、烟草数据中台、企业知识库、异构迁移和数据库安全五类场景共用一套数据库底座。做法包括将 12 套政务系统收敛为两个隔离集群，用 RU 配额与优先级做多租户调度；烟草中台以 TiKV 行存和 TiFlash 列存同时支撑交易与分析；知识库把 SQL 权限过滤与 HNSW 向量检索结合在同一份数据上。迁移侧用 TiDTS 编排全量与增量同步，安全侧用 DBNginx 将连接入口变为访问治理入口，结论是共性数据能力应下沉为可调度、可分析、可迁移和可治理的基础设施。不足是文章为厂商实践分享，缺少性能、成本、故障和量化收益对比，方案有效性需结合自身规模验证。
推荐收录。文章给出了多系统收敛为两个集群、HTAP 行存列存协同、SQL 权限过滤与 HNSW 向量检索结合、TiDTS 迁移编排和 DBNginx 访问治理等具体证据，适合数据库平台、数据中台和安全治理工程师参考。其可迁移价值在于把重复建设问题拆成资源调度、分析、检索、迁移与安全等可治理能力；风险是厂商视角明显，缺少量化收益与失败边界，选型时仍需独立验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/17
文章复盘得物将自建 TiDB 从 v5.3.3 迁移升级到 v7.5.x 的实践。背景是低版本停止维护、TiCDC 同步有延迟/OOM 风险、备份超 8 小时且负载上升，并偶发慢查询和可用性 BUG。团队采用迁移升级而非原地升级，经集群调研、环境准备、升级前验证、流量迁移和旧集群销毁，兼顾灰度与回滚。升级中遇到 v7.5.x 优化器对大表倾向全表扫描、聚合计划不准，通过绑定索引或设置 tidb_opt_objective=determinate 缓解。收益包括应用平均 RT 提升 44.62%、TiCDC 同步与备份效率提升、存储压缩至 MySQL 三副本约 55%，并总结 TiDB 适用于非分片查询、分析 SQL、磁盘瓶颈和数据倾斜场景。
推荐收录，因为它完整展示了一次大规模分布式数据库版本迁移的决策链路：为何放弃原地升级、如何用 TiCDC 做灰度迁移，以及优化器回归（全表扫描、执行计划不准）的定位与缓解。对 DBA、SRE 和数据库平台工程师，文中 RT、备份、TiCDC、存储压缩等量化收益及 TiDB 与 MySQL 的选型边界可迁移；但部分升级步骤仅有标题，落地需结合自身集群验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/17
文章是 TiDB 大版本升级的操作指南，按升级前置、原地升级和迁移升级三个阶段组织。前置阶段列出 variables/config 比对、应用兼容性回归、集群巡检、Patch 检查、性能压测、升级时长与 DDL 窗口评估、软件包准备和备份清单等检查项。原地升级给出屏蔽告警、按最佳实践调整 config、tiup cluster upgrade、监控 QPS/P99 与 PD Leader、核对版本和调整 variables 等步骤。迁移升级则通过 CDC 搭建备库、VIP 切换、sync_diff_inspector 校验、反向同步来支持回退。整体偏流程清单，缺少真实案例、失败复盘和版本差异细节，需结合官方 Release Notes 与自身环境验证。
推荐收录：文章给出 TiDB 大版本升级的完整检查项与操作步骤，包括升级前变量/参数比对、兼容性回归、压测、备份清单，以及原地升级和 CDC 迁移升级加反向同步的回退路径，并列出具体 tiup 命令与监控指标。对 TiDB DBA/SRE 做升级窗口评估和风险控制有直接参考价值。但内容偏流程清单，缺少实际案例与版本差异分析，使用时需结合官方 Release Notes 和环境验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/17
本文给出 TiDB 集群从 v6.5.12 升级到 v8.5.x（示例目标版本为 v7.1.8-5.2）的标准操作步骤，覆盖前置评估、原地升级和迁移升级三类流程。前置阶段通过脚本对比升级前后系统变量、TiDB/TiKV/PD 配置差异，并包含巡检、patch 检查、压测、窗口与 DDL 评估、安装包准备，以及系统变量、权限、sequence、view、core variables、meta.yaml 等备份脚本。原地升级使用 tiup cluster upgrade，随后检查 QPS/P99、PD Leader、版本与 git_hash，并按最佳实践微调 config 和 variables。迁移升级给出 BR 全量恢复、TiCDC 同步、sync_diff_inspector 一致性校验、应用切流和反向同步，以及异常时回退流程。文章偏运维 runbook，命令和脚本可复用，但版本号示例与目标不完全一致，部分步骤仅有文字或无截图，需结合实际环境验证。
推荐收录，因为它提供了可执行证据：变量/配置 diff 脚本、完整备份脚本、tiup 原地升级命令、BR+TiCDC 迁移与 sync_diff_inspector 校验、回退步骤，而不是泛泛介绍升级流程。适合 TiDB DBA、SRE 和负责数据库变更的工程团队在制定升级窗口、备份、校验与回滚预案时参考。主要风险是示例版本为 v7.1.8-5.2、部分环境信息被脱敏，且少数步骤缺少截图和验证数据，落地前需在测试环境验证。
工程实践 TiDB 社区博客 - 实践案例 2026/09/14
文章复盘在平凯 Loop 中用 5 个角色 Agent 协作交付啤酒节营销系统的实践，系统覆盖活动、促销、优惠券核销、分群、A/B 实验与看板，含 17 个 REST API 和可运行 Demo。作者关注多 Agent 如何在统一上下文和验收机制下完成需求、开发、测试与部署协同。核心做法包括：一需求一线程并前置验收标准；按 Leader、RD、QA、DevOps 等交付物划分角色；按依赖关系推进；把完成定义为静态检查、自动化测试和真实交互三层证据；将踩坑固化为规则。文中用一次 25 分钟增量变更说明上下文共享、依赖显性化和验收前置的收益，并强调该模式适合边界清晰的轻量系统，生产化仍需补齐认证、权限、审计、监控、备份和合规。
推荐收录：文章不是产品发布稿，而是给出了 5 个角色 Agent 在真实轻量业务系统中的任务拆分、角色边界、依赖排序和多层验收证据，并附 25 分钟增量变更闭环。对探索 AI 工程化、多 Agent 协作或内部工具快速交付的团队，这些实践可直接迁移；同时明确列出 Demo 到生产的安全、合规和运维缺口，避免读者误判适用范围。
工程实践 TiDB 社区博客 - 实践案例 2026/09/09
文章介绍了青岛市外贸赋能中心从 MySQL 渐进式迁移到 TiDB 的完整实践。背景是业务规模和数据量持续增长，MySQL 5.6 主从架构在部分大表接近或突破 2000 万行后出现索引、分页、聚合成本上升，单机扩展受限，且分析负载与在线交易相互干扰。团队评估了分库分表等方案，认为其只是转移复杂度，最终基于 MySQL 兼容性、分布式弹性扩展、HTAP 能力以及运维工具链选择 TiDB。迁移没有一次性推倒重来，而是先从物流系统和金融平台两套核心系统开始，保留 MySQL 处理小规模业务。实际效果包括 DDL 从十几分钟缩短到秒级，复杂 SQL 从十几秒降至秒级甚至毫秒级，数据链路从分钟级缩短到秒级、人工干预率降低 90% 以上。文章也明确了边界：并非所有业务都适合分布式数据库，数据量长期稳定、低并发的小系统仍应使用单机 MySQL。
这是一个真实数据库选型与渐进式迁移案例，完整展示了从性能拐点识别、候选方案比较、迁移策略设计到效果验证和适用边界的全过程，不是单点技术技巧堆砌。适合数据库架构师、数据基础设施负责人和需要向分布式架构演进的团队参考，其中的分阶段换道、场景取舍与成本评估方法可直接迁移到类似系统。
工程实践 TiDB 社区博客 - 实践案例 2026/09/04
文章以TiDB生产环境中的三个真实SQL调优案例为主线，展示从“跑不动”到“飞起来”的完整排查过程。第一个案例是因统计信息过期导致优化器误判筛选率，未走联合索引的最优范围，通过ANALYZE和配置自动收集恢复性能；第二个案例是分区表查询因NOW()等非常量表达式导致分区裁剪失效，改写为常量时间后恢复正常；第三个案例是自增主键在聚簇索引下形成写热点，通过AUTO_RANDOM或业务主键加预分裂分散写入。每个案例都给出根因判断、优化SQL和执行计划变化，并总结出先看执行计划、重视统计信息、预防写热点三条方法论，附有诊断命令速查。边界在于案例基于TiDB特定实现，部分结论对传统单机数据库不一定适用。
推荐收录。文章不是零散技巧，而是围绕具体线上问题的诊断链路：现象、根因定位、方案验证和预防措施都写得很清楚，适合TiDB/分布式数据库运维和SQL调优读者。文中关于统计信息、分区裁剪、写入热点的分析方法可迁移到其它分布式或关系型数据库，只是需要结合各自引擎特性试用。
工程实践 TiDB 社区博客 - 实践案例 2026/09/03
本文基于古珀医疗在区域医疗健康平台建设中的实践，复盘其数据库架构从 MySQL 到 MongoDB、再到 TiDB 的演进历程。早期单体医院项目数据量小，MySQL 可支撑业务快速上线；当业务扩展到区域级和省级平台后，数据规模增长至数十TB，MySQL 在 DDL 变更、写入容量和运维成本上出现瓶颈。MongoDB 的文档模型提升了迭代灵活性，但复杂关联查询和空间成本限制了其适用性；Doris、ADB 等分析型数据库性能好，却因私有化部署和数据同步链路复杂而未采用。最终选 TiDB 主要看中其水平扩展、HTAP、MySQL 兼容和 TiCDC 实时同步能力，并在区域医疗健康大脑、智慧法医等四个核心场景规模落地，最大单集群 80TB。文章也说明没有绝对完美的数据库，需根据场景组合使用多种存储技术。
推荐收录，因为它呈现了真实业务约束下的数据库选型与切换过程，给出了从数百GB到80TB数据规模时的取舍依据和多个核心场景的落地形态。适合在医疗/政务等私有化部署环境下做数据架构选型、或评估分布式数据库替代 MySQL 的读者参考。文中对 HTAP、MySQL 兼容生态和同步链路需求的判断，可迁移到类似高可靠、强一致的数据平台建设中。
学习路线 TiDB 社区博客 - 实践案例 2026/09/03
作者作为分布式数据库从业者，完整记录了通过 TiDB 官方 PCTA、PCTP、PCSD 三级认证的过程与备考策略。他将三个阶段分别类比为 AI 预训练、领域微调和推理增强：PCTA 覆盖集群架构、Region/Raft/TSO、部署与工具；PCTP 聚焦生产管理、备份恢复、迁移和高可用，并以首考 41 分（及格 42）失败后强化故障演练二战通过的经历说明实战的重要性；PCSD 则转向 SQL 开发侧，考察索引、执行计划、事务与在线 DDL 等细节。文章给出了各级别的知识点权重、官方课程和练习方法，对打算系统学习 TiDB 认证的人有路线图式的参考价值。其边界在于内容围绕官方认证展开，考试细节会随版本变化，未对底层原理展开深入讲解。
推荐收录。它提供了完整的 TiDB 认证路线和结合实际故障演练的备考方法，尤其记录了 PCTP 失败后的调整策略，对准备官方认证或学习 TiDB 运维/开发的读者有直接参考价值。虽然内容随版本可能时效受限，但作为入门路线图仍值得借鉴。
工程实践 TiDB 社区博客 - 实践案例 2026/08/29
文章以内网环境为背景，详细演示了通过 MCP SSE 模式将 TiDB 数据库能力接入 Dify 智能体平台的完整过程。作者先对比了原生 MCP（SSE）与 FastAPI + OpenAPI 两种接入方案的适用场景，指出前者适合快速原型和内部数据分析，后者更适合生产环境和复杂业务流。随后给出在 RockyLinux 上配置阿里云源、安装 Docker、部署 Dify、克隆 pytidb 项目、创建 Python 虚拟环境并启动 SSE 服务的具体命令和排错要点。文章还展示了在 Dify 中安装 MCP 插件、配置模型、创建 Agent 并编写系统提示词的步骤，最后通过四个对话场景验证了 Agent 查询集群信息、表结构和执行只读 SQL 的能力。文章适用于内网数据库 AI 化改造的入门实践，但未深入讨论安全管控、SQL 注入防御或大规模并发下的性能问题。
推荐收录，因为文章提供了从环境准备到 Agent 联调的可复现操作路径，并明确对比了 MCP 与 FastAPI 两种方案的安全性与适用边界。对需要在内网快速搭建数据库 AI 助手的工程师、数据分析师或低代码团队有直接参考价值，关键的环境配置和排错步骤可迁移到类似场景。
工程实践 TiDB 社区博客 - 实践案例 2026/08/29
本文记录作者基于 Dify、FastAPI 与 PyTiDB 构建大模型驱动 TiDB 智能运维 Agent 的完整实践。文章先说明了每层的职责划分：Dify 作为 Agent 编排与 LLM 调度层，FastAPI 提供 RESTful 接口并执行参数校验和安全控制，PyTiDB 作为 Python 数据访问层连接 TiDB 集群。随后详细介绍了 Ollama 本地部署 DeepSeek 模型、Dify 安装配置、Python 虚拟环境搭建与依赖安装、FastAPI 服务编写、systemd 服务配置以及通过 OpenAPI Custom Tool 将后端服务注册为 Dify 工具的过程。文中提供了完整的 app.py 代码，并明确限定 /db/execute-sql 接口仅允许 SELECT/SHOW/EXPLAIN/DESC 只读操作，以规避大模型生成 SQL 的安全风险。作者最终用自然语言查询集群拓扑、会话列表等验证了通路，同时指出本地小模型效果有限、建议使用在线模型，并强调该方案仍是 demo 级别，未覆盖生产环境的权限管理、审计与高并发场景。
推荐收录。文章不是简单概念介绍，而是给出从环境部署、代码实现到系统集成验证的完整链路，尤其对 FastAPI 作为 LLM 与数据库之间的安全隔离层做了可复用的设计。适合数据库运维、AI 应用工程化以及希望将自然语言接入私有数据系统的读者参考，可直接照搬其分层思路与只读 SQL 防护模式；但需注意生产环境仍需补充鉴权、SQL 白名单与操作审计。
工程实践 TiDB 社区博客 - 实践案例 2026/08/28
文章记录智慧停车平台从 PolarDB 迁移到 TiDB 的过程，背景是核心表每年新增约 2.4 亿条数据，大表到 8000 万行后出现慢 SQL、跨停车场 join 困难等问题。团队实测对比 TiDB、ClickHouse 等数据库，最终选择 TiDB v8.5.2，原因包括 MySQL 兼容、压缩成本低、社区活跃等。迁移采用 Dumping 导出加 Lightning 导入，并借此规范了索引设计和代码中的排序逻辑。上线一年多后，慢 SQL 从满屏降到每天约 46 条，监控和告警体系从无到有，运维变为主动。文章最后给出选型建议：小场景用 MySQL，中大型 SaaS 用 TiDB，分析密集型可用 HTAP。内容属于真实的数据库迁移工程案例，但来源为 TiDB 官方博客，存在一定的推广立场。
推荐收录，因为它展示了在停车业务高可用约束下，数据库选型、迁移和运维改进的完整链路，包含数据规模、慢 SQL 数量、迁移工具等可量化证据。对于面对大数据量 join 问题和分布式数据库选型的工程师，文中的对比方式和迁移后治理经验有直接参考价值。需要注意的是，文章由数据库厂商发布，性能收益数据缺乏独立验证，读者应结合自身场景做验证。
工程实践 TiDB 社区博客 - 实践案例 2026/08/27
作者结合TiDB免费认证学习经历，对TiDB与OceanBase做了MySQL语法兼容性对比测试。测试围绕外键关联表、RANGE/LIST/HASH及复合分区表、在线索引DDL、前缀索引和存储过程等对象的DDL/DML展开，并检查执行计划与错误提示。结果显示两者对MySQL基本语法均兼容，都支持外键约束、普通分区和在线加索引；差异在于TiDB不支持复合分区与存储过程，OB支持；索引选择路径与报错信息也有不同。文章给出完整测试SQL、版本信息和结果截图，但未涉及性能、事务隔离、复杂查询等场景，对比深度停留在功能支持层面，且针对特定版本，结论时效性有限。
文章以可复现的SQL脚本和截图直接对比TiDB与OceanBase在MySQL兼容性上的功能差异，覆盖外键、分区、索引和存储过程等迁移常见场景，对分布式数据库选型和MySQL业务迁移评估有直接参考价值。适合DBA、架构师和迁移项目成员；测试方法可迁移，但结论基于特定版本，使用时需结合最新版本文档复核。
个人心得 TiDB 社区博客 - 实践案例 2026/08/27
本文作者是一名数据库运维工程师，在一年多内先后考取 MySQL OCP、TiDB PCTA 和 PCTP 认证，并完整复盘了这段经历。文章先说明考证动机来自业务增长和团队引入 TiDB，随后分别回顾三场备考：MySQL OCP 补全了 MVCC、半同步复制等底层原理；PCTA 帮助建立对 TiDB 计算、存储、调度分离架构的认知，并记录了一次扩容磁盘告警的踩坑；PCTP 则深入分布式执行计划、TiKV 底层和集群调优。作者总结了认证是系统化学习的起点，MySQL 与 TiDB 互补而非替代，分布式数据库对 DBA 能力提出新要求，并强调动手实验的重要性。最后给出夯实 MySQL 基础、以认证为脚手架、多动手、关注社区等建议。文章适合数据库运维人员和计划学习分布式数据库的工程师参考，但属于个人经验分享，深度和通用性有限。
文章以真实考证经历为基础，具体描述了从单机数据库到分布式数据库的学习路径和常见陷阱，对数据库运维人员有直接参考价值。它强调了认证考试作为知识体系化工具的价值，并给出了可执行的实验和学习建议，可迁移到其他数据库技术栈的学习中。主要风险是个人经验成分较多，部分结论需结合实际场景验证。
工程实践 TiDB 社区博客 - 实践案例 2026/08/25
本文是宁波金唐与平凯数据库（TiDB企业版）在医疗行业落地实践的技术复盘。文章首先分析医疗国产化的特殊挑战，如系统数量多、新旧兼容、7×24小时高可用和海量数据混合负载，然后介绍宁波金唐的选型策略，强调分布式与集中式数据库需按业务规模取舍，并看重TiDB对中小型至大型机构的全场景覆盖、HTAP能力和MySQL生态。通过宁波市全民健康信息平台和海曙区一体化医疗云平台两个案例，作者给出具体性能数据，如诊断匹配查询从109秒降至0.281秒，年度收入报表从350秒降至6秒，并指出性能提升来自数据库能力、冷热分区和持续调优的共同作用。文章也提到迁移后仍需依赖厂商协同调整SQL和索引，并展望医疗AI对高质量数据底座的需求。总体以真实系统规模和多组对比数据为基础，但视角偏厂商合作方，可能弱化迁移中的风险和成本。
本文提供了一手医疗行业数据库国产化迁移的工程案例，包含选型判断、架构决策、真实系统规模和对比性能数据，对负责数据库选型、迁移或医疗信息系统的读者有直接参考价值。可迁移的不仅是具体优化技巧，更是从业务需求出发评估分布式vs集中式数据库、以及迁移后持续调优的思路。由于文章由TiDB社区发布，部分表述带产品宣传倾向，读者应关注其方法和数据，而非单纯的产品结论。
工程实践 TiDB 社区博客 - 实践案例 2026/08/24
文章复盘了 TiDB 7.5.x 生产环境中一次 CREATE INDEX 卡在 write reorganization 且 ROW_COUNT 恒为 0 的故障救援过程。故障根因被定位为 DXF（disttask 框架）残留孤儿任务：历史中断的 add index 在 mysql.tidb_global_task 中留下长期处于 pausing/reverting 状态且 dispatcher_id 为 NULL 的条目，框架 scheduler 因内存态不刷新而持续调度这些僵尸任务，占满调度槽位，导致新的 ingest 模式索引任务无法推进。作者完整记录了 40 分钟排查链路，包括 AI 协助查证系统表、发现 tidb_enable_dist_task 开关被误关、最终通过滚动重启 tidb-server 清空框架内存态恢复服务，并提供了分场景的临时解决方案、每日巡检脚本、业务规范以及对 TiDB 团队在 scheduler 超时回收和内存态一致性方面的改进建议。文章还反思了 AI 在故障排查中作为“军师”与用户作为“侦察兵”的协作模式及其边界，指出 AI 缺乏现场执行权，有效协作依赖完整证据输入。
推荐收录。文章以真实生产事故为样本，完整呈现了从现象、日志证据、系统表探查到根因确认和恢复操作的故障处理闭环，并给出了可复用的 SOP、巡检脚本和预防规范，对负责 TiDB 运维或分布式数据库稳定性保障的工程师有直接参考价值。其对 AI 协同排查方式的反思也提供了可迁移的人机协作模式，但读者需注意文中操作涉及直接修改系统表和重启集群，须在受控环境验证后使用。
工程实践 TiDB 社区博客 - 实践案例 2026/08/22
文章记录了某数据库集群在运行过程中出现响应时间突增、CPU 使用率升高、整体性能下降的现象。排查时发现期间曾执行过 systemctl stop tuned.service 操作，即关闭了 tuned 服务。通过检查 /etc/tuned/ 目录未找到自定义配置，使用 tuned-adm list 确认当前配置为 throughput-performance，但因 tuned 未启动导致该配置没有生效。启动 tuned 服务后，throughput-performance 配置生效，集群性能恢复正常。文章还简要介绍了 tuned 是系统级动态调优守护进程，throughput-performance 模式会关闭节能机制、启用 sysctl 优化、切换 I/O 调度器并将 CPU 调频策略设为 performance。该案例展示了操作系统服务配置对分布式数据库集群性能的显著影响，但缺少具体的性能指标对比与更深入的原因分析。
收录原因是它提供了一个真实的、可复现的运维排障案例：数据库性能劣化可能与 tuned 服务被关闭直接相关。对于负责数据库或分布式系统运维的工程师，文中通过 tuned-adm 检查配置、确认服务状态并恢复的排查路径具有直接可迁移性。但内容深度有限，建议结合官方手册进一步理解 tuned 参数细节。
工程实践 TiDB 社区博客 - 实践案例 2026/08/20
文章基于TiDB团队近两年服务AI Agent应用（如Kimi、Dify）的实践，总结了Agent时代基础设施的演化路径与核心设计原则。作者唐刘指出，Agent产品规模化首先要解决“计算资源空闲成本”和“执行环境消失后任务恢复”两大难题，分别通过虚拟数据库（scale-to-zero、秒级就绪）和持久文件系统（Sandbox与Workspace分离）来应对。随着Agent任务变长，跨session记忆、文件与Git工作区持久化、可审计的权限与数据可信性成为新的需求，推动TiDB形成覆盖数据、记忆、文件和Lake分析层的Agent Stack。文章还提出了三个可迁移判断：先算空闲成本，从第一天拆分执行与状态，减少Agent跨系统边界。整体以真实客户案例为支撑，但内容带有TiDB产品推广成分，且结论主要基于个别头部客户实践，适用范围需读者结合实际验证。
本文以Kimi、Dify等真实Agent产品的业务需求为线索，详细拆解了Agent基础设施从数据库自动创建到记忆、文件系统、可靠分析层的演化过程，给出了具体的成本模型和架构取舍（如scale-to-zero、执行与状态分离）。适合正在构建Agent产品或关心AI基础设施底座的技术决策者阅读，其中的“先算空闲成本”“让Agent少跨系统边界”等判断可直接迁移到类似场景。不过文章源自TiDB商业推广，需注意案例的代表性与产品倾向。
工程实践 TiDB 社区博客 - 实践案例 2026/08/20
文章以杭州银行新一代核心系统采用平凯数据库（TiDB 企业版）替换传统集中式数据库的实践为主线，总结了从架构落地到开发治理的完整经验。作者提出按业务等级差异化设计部署架构：普通系统采用单集群多副本，重要系统采用“3+1 副本”与自动同步复制，核心系统则按“5+1 副本”建设“两地三中心”容灾体系，实现 RPO=0、RTO 不超过 30 秒。在开发治理方面，文章重点说明了数据库对象命名、数据类型映射（如 Oracle 的 Number 与 ZHS16GBK 向 Decimal 与 UTF8MB4 的转换）、索引数量控制、联表数量和事务拆分等规范，并通过自研 DAP 平台将规范嵌入开发测试发布流程，以强控和提醒规则保证执行。文章还提到连接池生命周期配置、慢 SQL 日志关联和常态化巡检等运维治理手段。整体上这是一次金融级分布式数据库国产化的系统实践，但对于小型系统或非金融场景，部分设计可能偏重，需要结合实际业务等级裁剪。
推荐收录，因为文章基于真实金融核心系统上线案例，提供了从部署架构、容灾设计、SQL 规范到平台管控的完整闭环，具有明确的约束条件和取舍逻辑，不是泛泛的产品宣传。适合正在从事分布式数据库选型、迁移或国产化改造的架构师、DBA 和开发管理者参考，其中的分级部署思路、开发规范落地方法和连接池配置策略可迁移到其他数据库工程实践。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
工具笔记 TiDB 社区博客 - 实践案例 2026/08/13
文章详细介绍了平凯 Loop 多 Agent 协作开发环境的搭建与使用，涵盖架构概览、Agent 角色设计（架构师、开发者、双审查者、测试、文档工程师等）、Skill 技能库准备、Agent 与 Skill 绑定、频道组织、任务工作流以及需求文档转 Markdown 的多种方式。文中给出了具体的 Agent 系统提示词、配置参数和操作步骤，强调角色分离、交叉审查等实践，并提供了从需求分析、编码、审查到测试、文档的完整示例。文章面向从零搭建多 Agent 开发团队的用户，适用于私有化或 SaaS 部署，但内容高度绑定 Loop 产品，部分建议依赖平凯/TiDB 生态，模型可用性受部署环境限制。
本文提供了可复用的多 Agent 协作开发配置模板，包括角色设计、提示词编写、审查流程和技能绑定，对希望构建 AI 辅助开发工作流的团队有直接借鉴价值。适合正在探索 Agent 协作开发、代码审查自动化或工程效率提升的开发者与技术负责人。主要风险是内容高度绑定平凯 Loop 产品，部分 Skill 和模型建议依赖特定生态，读者需抽取其团队设计思想与工作流模式，而非照搬操作步骤。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章围绕TiDB集群在元数据和管理信息完全丢失、仅保留TiKV数据文件情况下的恢复策略展开。作者以测试环境模拟案件取证场景，先通过TiKV日志提取原集群的Cluster ID，然后销毁原有集群与tiup元数据，重新部署相同版本TiDB集群，并将TiKV数据目录指向物理拷贝路径。随后修改last_tikv.toml中的日志、数据、raft等路径，使用pd-recover工具重置Cluster ID，最后启动集群并验证各组件状态。该方法适用于TiDB v6.1.0环境且TiKV数据完整、PD元数据不可恢复的场景。文章给出了具体命令和配置修改项，但未深入解释pd-recover原理、数据一致性验证细节及操作风险，整体更偏向可复现的操作记录。
推荐收录，因为文章提供了一个具体且可复现的TiDB灾难恢复案例，尤其适合运维人员或数据库管理员在元数据丢失时参考。文中的操作步骤、配置修改和Cluster ID恢复方法具备可迁移性，但需注意版本差异和数据一致性风险，建议结合官方文档使用。
工程实践 TiDB 社区博客 - 实践案例 2026/08/10
文章记录了永康市卫健委全民健康平台为解决业务高峰负载过高与容灾需求，采用平凯数据库物理复制能力进行架构改造的实践。改造将主集群专注核心事务，备集群承担报表查询等读操作和容灾角色，实现读写分离。上线后故障切换低于15秒且数据零丢失，系统负载下降，运维操作秒级完成。文章解释了物理复制基于日志实时同步所有数据库对象，支持最大保护、最大可用、最大性能三种模式，并与 TiCDC 逻辑复制对比，指出物理复制适合集群级容灾和读写分离，逻辑复制适合异构同步与数据管道。实际指标依赖网络拓扑和负载，且相关能力仍在演进。
推荐收录，因为文章提供了真实医疗场景下的数据库高可用与读写分离改造案例，包含明确的问题定义、技术选型依据、实施效果和方案对比。适合关注核心系统容灾、分布式数据库选型或架构优化的读者。可迁移价值在于展示了物理复制在强一致需求下的应用边界，但需注意厂商案例可能带有一定推广成分。
工程实践 TiDB 社区博客 - 实践案例 2026/08/07
文章记录了在 openEuler 22.03 SP4 国产化操作系统上部署 TiDB v8.5 的完整实践过程，包括 TiUP Playground 快速测试和 TiUP Cluster 单机模拟生产两种方案。作者详细列出了与官方 CentOS/RHEL 文档差异导致的典型问题，如 bash_profile 环境变量不生效、Playground 监听 127.0.0.1、openEuler 默认 MaxSessions=10 导致 SSH 并发连接失败、禁止 root 运行 TiDB 进程、防火墙端口放行、随机密码保存等，并给出对应解决命令。随后使用 Sysbench 进行只读和读写混合压测，复现了读写混合场景下的锁等待超时故障，分析了热点索引页、乐观事务冲突等成因，并通过调整隔离级别、增加 TiKV scheduler-concurrency、使用 --skip-trx 等方法缓解。文章适用于国产化环境部署 TiDB 和初步进行基准测试与故障排查的读者，但部分建议需根据实际业务场景谨慎采用。
推荐收录，因为它是真实环境下的部署与压测案例，覆盖了国产操作系统与分布式数据库兼容性问题、SSH 并发限制、权限管理等工程约束，以及基于 Sysbench 的锁等待故障分析。适合需要在 openEuler 等信创系统上部署 TiDB 或学习分布式数据库基准测试和初步排障的工程师，文中命令和排查路径可直接迁移到类似环境。主要风险是部分优化建议如降低隔离级别需结合业务正确性验证，不宜直接照搬生产环境。