41 篇内容
文章复盘某国有大行将运行十余年的 Oracle 资产托管核心迁移到 TiDB 的三年工程。面对几十 TB 数据、数万条复杂 SQL 和不能长时间停机的约束，项目放弃强行分库分表，采用原生分布式架构实现计算与存储弹性扩展。迁移中先做关联应用试点，再进行一年多的新旧系统双轨逐笔比对、数百项故障与性能准入验证，并用独立部署的 TiCDC 支撑灾备、数据湖和 Oracle 反向回写。上线后通过资源组隔离交易、批量和报表负载，降低慢查询扩散风险。文章给出了金融核心库替换的可复用路径，但作为厂商社区案例，缺少具体性能指标、成本和失败细节。
推荐收录为工程案例。文章不仅说明选型结果，还交代了不做分库分表的业务约束、双轨并行与回切链路、TiCDC 独立部署和资源隔离等具体做法，对承担核心系统数据库迁移、容灾和批流混合负载的团队有迁移方法上的参考价值。需注意其来自 TiDB 社区，缺少量化指标与失败复盘，阅读时应把厂商结论与可验证工程证据分开。
文章用“预测学员能否通过考试”案例讲解 KNN：计算待预测样本与历史样本的欧氏距离，用 ROW_NUMBER 取最近 K 个邻居，再多数投票分类。作者在 TiDB 8.5.3 Serverless 中给出纯 SQL 实现，覆盖建表造数、距离计算、单样本预测，以及 CROSS JOIN + PARTITION BY 批量预测，并说明投票后需再套 ROW_NUMBER 才能只保留冠军类别。随后用 pymysql、pandas 连接 TiDB，调用 sklearn 的 KNeighborsClassifier，结果与 SQL 版一致。适合数据库工程师和机器学习入门者参考，但样本仅 10 条，未处理归一化、K 值选择和平票规则，属于教学演示。
推荐收录。文章提供了可直接运行的 TiDB SQL KNN 全流程，包括距离计算、ROW_NUMBER 取邻居、GROUP BY 投票和 CROSS JOIN 批量预测，并用 sklearn 结果交叉验证，证据具体。适合数据库工程师和机器学习入门者理解“在库内做简单模型”的可行方式；需注意其小样本教学定位，生产使用还要补归一化、调 K 和处理平票。
文章以一张销售明细表贯穿，系统讲解 TiDB 窗口函数的语法和三类常见用法：用 ROW_NUMBER、RANK、DENSE_RANK 做排名，用 SUM、AVG 配合 OVER 做累计、占比和移动平均，用 LAG、LEAD 做环比与上下行对比，并补充 ROWS BETWEEN、NTILE 等进阶窗框和分桶技巧。文中给出可复制的建表数据、完整 SQL、运行结果解释，以及 TopN、城市内占比、环比和综合销售看板案例。作者还集中说明 WHERE 不能直接过滤窗口函数、累计求和漏写 ORDER BY、LAG 首行为 NULL 等六个易错点，并展示 pandas 通过 pymysql 读取 TiDB 查询结果的方式。文章基于 TiDB 8.0.11-TiDB-v8.5.3 和 MySQL 8 兼容语法，侧重入门与常用分析场景，未深入执行计划、性能调优或 TiDB 特有优化。
推荐收录。文章不是只罗列语法，而是用同一销售数据集给出可运行 SQL、结果解释和 TopN、累计、环比、占比综合案例，并集中列出 WHERE 执行时序、累计漏 ORDER BY、LAG 首行 NULL 等易错点，适合 SQL 初学者、数据分析师和 TiDB/MySQL 使用者查阅。其模板和避坑清单可迁移到日常分析 SQL，但性能调优与 TiDB 特有优化需另行补充。
文章复盘水务 SCADA 项目在 TiDB 上引入 TiFlash 的半年实践：1.6 亿行时序表需跨 90 天、多 DMA 聚合，TiKV 全表扫描使报表耗时 12.4 秒，并拖累点查 P99 从 30 毫秒升至 190 毫秒。作者详述加列存副本后的同步等待、优化器不选 TiFlash、weak/strong 一致性取舍及 JSON 函数算子回退等问题，并用 32 条核心 SQL 双引擎对拍发现空值与 DECIMAL 舍入差异。结果显示报表降至 380 毫秒、约 30 倍，写入 P99 增加 18%，列存仅多占 39GB，报表与点查实现隔离。经验是只给分析型大表加副本、读写引擎分开、按场景选一致性并独立部署。其边界是单机房、特定写入水位和半年观察，副本数如何确定仍无标准答案。
推荐收录，因为它给出了可核验的工程账本：12.4 秒到 380 毫秒、写入 P99 22 到 26 毫秒、列存多 39GB，并把同步、优化器选择、一致性、算子回退等真实问题逐项拆开。适合正在评估 TiDB HTAP、列存副本或报表/点查隔离的数据库架构师和运维读者；其中双引擎对拍与按场景选一致性可直接迁移，风险是结论来自单项目单机房和半年观察，容量规划仍需结合自身写入水位验证。
文章复盘一条订单查询从 MySQL 迁到 TiDB 后变慢的排查过程：查询按 status 与 created_at 过滤并按时间倒序取 20 条，作者起初加联合索引却无效。改用 EXPLAIN ANALYZE 后，他发现优化器走 TableFullScan、扫描约 120 万行；根因是统计信息过期，使 CBO 误判索引回表代价。执行 ANALYZE TABLE 后计划改用索引，耗时从约 2 秒降到 80 毫秒；文中还提醒大表可采样分析，并介绍执行计划绑定作为兜底。最后作者对比 MySQL 的局部修补与 TiDB 先看全局计划的思路。该案例具体但属单点入门经验，未展开完整基准和 binding 语法细节。
推荐收录：文章用可复现的排查链条说明 TiDB 调优不能只靠加索引——从 EXPLAIN ANALYZE 定位 TableFullScan，到检查统计信息并用 ANALYZE TABLE 验证，再到 plan binding 兜底，路径清晰。适合使用 TiDB 或分布式数据库的后端、DBA 读者借鉴；但只是单案例入门经验，正式 binding 命令和基准数据缺失，不能替代系统化优化手册。
文章整理自 TiDB 社区 Data+AI 圆桌，五位来自数据库、模型厂商、金融迁移、全栈架构与 TiDB AI 团队的实践者讨论 Agent 从 Demo 到生产的障碍。核心结论是难点多在模型之外：业务流抽象、数据对接、隐性知识沉淀和业务语义理解先于 Agent 搭建；长期稳定依赖 Harness、记忆分层、标准化数据及支持 checkpoint 的底层存储。可控性强调按风险分级授权、Human in the loop、规则引擎、可观测性和传统幂等补偿。走向决策还需元数据、确定性 skill、信息增强、交叉校验与可执行验证。文章提供多生态评估框架，但以观点为主，缺少实现细节和量化验证。
推荐收录：文章以五位一线实践者的真实场景，集中呈现业务抽象、记忆治理、checkpoint 恢复、风险分级授权、可观测性和验证闭环等企业 Agent 落地要点，适合 Agent 平台、数据基础设施和可靠性团队作为检查清单。局限是圆桌体例偏观点，缺少代码、架构图与量化基准，读者需结合自身系统二次验证。
文章复盘一次将 15.3 亿行、500GB MySQL 历史明细通过 TiDB Lightning 物理导入迁移到 TiDB 的工程事故。作者先按 24 并发导入，约 1 小时 40 分后两个 64G TiKV 节点因内存冲高被系统 OOM Killer 杀死，出现 region is unavailable 和长时间 Region 迁移，业务 P99 从 80ms 升至 3.4 秒。随后定位到内存消耗由 Lightning 并发度、表行宽和 TiKV 内存上限共同决定，将 region-concurrency 从 24 降到 8，并设置 memory-usage-limit 与较小 block cache 后重跑，虽多花 88 分钟但实现零 OOM。文章还强调导入后清理 checkpoint、逐表校验行数与 ADMIN CHECKSUM、补 ANALYZE 统计信息，并指出并发经验式仍需按集群承受能力调整。
推荐收录：文章给出完整可复现的事故链和调参证据，包括 24 并发下两次 TiKV OOM、region-concurrency 降到 8、memory-usage-limit 设为 40GB，以及 checkpoint、校验和与 ANALYZE 的收尾清单。对做数据库迁移、容量规划和线上稳定性保障的 DBA/SRE/后端工程师有直接迁移价值。注意其并发经验式来自特定 3 节点集群，跨集群仍需结合 write stall 与内存水位验证。
作者把每天新增 3000 万行、写入峰值 1.8 万 QPS 的订单流水场景迁移到 TiDB v7.5.6，为避免自增主键导致尾部 Region 热点，采用了 AUTO_RANDOM(5) 主键，写入分布确实被打散。但按 create_time 深分页的查询反而变慢：AUTO_RANDOM 聚簇主键把行数据随机散布，二级索引做范围扫描时要跨大量 Region 回表，再叠加 OFFSET 100000 的深分页放大效应。作者还遇到 SHARD_ROW_ID_BITS 对聚簇表静默无效的问题，并梳理了论坛上几种方案的取舍：补建联合索引会把热点转移到索引尾部，用 create_time 做 RANGE 分区靠分区裁剪减少扫描，深分页改成游标翻页。文章对 AUTO_RANDOM 位数如何确定仍未定论，缺少压测数据与最终验证结果。
推荐收录：文章讲清了写入热点被打散后读取被放大的真实冲突：聚簇表导致二级索引回表跨 Region、深分页 OFFSET 在分布式下被放大，并记录了 SHARD_ROW_ID_BITS 对聚簇表静默失效这一容易误判的边界。对在 TiDB 或分布式数据库上处理时序写入与分页查询的工程师，其索引设计与游标翻页排查思路可直接迁移；不足是缺少压测数据与最终验证。
文章以网店销售分析为例，解释业务表为何拆分，并用 users、orders、order_items、products、categories 五张表演示 INNER JOIN 与 LEFT JOIN。它给出建表、造数、品类 GMV、城市贡献、复购和沉睡用户等 SQL，再用 Python、SQLAlchemy 和 pandas 连接 TiDB，完成宽表读取、分组聚合、透视表与用户分层。文中强调 WHERE 过滤、GROUP BY 聚合、ORDER BY 排序的分析顺序，并指出 LEFT JOIN 右表条件应放在 ON、TiDB Cloud 需 SSL 等要点。整体适合入门复现，但偏通用 SQL/pandas 教程，对 TiDB 执行计划、索引和大数据量性能边界讨论不足。
推荐收录，因为文章提供了从五表建模、JOIN 查询到 pandas 分析的完整可运行链路，并明确点出 LEFT JOIN 过滤条件位置和 SSL 连接等易错点。适合 SQL/数据分析初学者和需要快速搭建 TiDB 演示环境的开发者作为可复现参考；不过它偏基础教程，缺少查询优化和大数据量边界，长期价值主要在入门教学与代码模板。
文章复盘某国有大型银行 A+ 级资产托管核心系统从 Oracle 迁移至平凯数据库（TiDB 企业版）的三年半实践。面对几十 TB 数据、4500 多张表、数万条 SQL 且多表关联复杂、每月近 TB 增长和同城双活 RPO=0 等约束，项目组选用原生分布式、计算存储分离、水平扩展和多副本高可用，并以 CTE、LEFT JOIN+UNION 等改造 Oracle 语法。实施采用小系统先行、生产流量双轨并行 18 个月、227 项准入测试，以及 TiCDC 独立部署形成灾备、数据湖和 Oracle 回切三条通道，配合三级资源管控。上线后联机交易稳定在 200ms 内、SLA 99.99%，保持零重大故障、零数据丢失、零业务中断。不足是文章来自厂商社区，缺少成本、运维复杂度和长期故障细节，结论需结合自身负载独立验证。
推荐收录：文章给出了金融核心系统国产化迁移的完整约束、方案和验证证据，包括小系统先行、18 个月双轨并行、227 项准入测试、TiCDC 三通道与可回切设计，适合银行核心系统、分布式数据库迁移和 SRE/架构读者借鉴。风险是来源为厂商社区，性能与零故障口径缺少独立验证，成本与运维复杂度也未展开。
文章复盘 Kimi 在 Agent 交付应用与 Coding Agent 两类场景中引入 TiDB Cloud 的实践。Website 场景需让数千万站点获得低成本、秒级就绪的隔离数据库，Kimi 用 TiDB Cloud Starter 的 Warm Pool、Scale-to-Zero 和虚拟数据库层实现秒级 provisioning、空闲零计算成本与租户隔离。Coding Agent 场景把 Sandbox 执行与持久状态解耦，用 TiDB Cloud Filesystem 承接代码、Git 状态和任务进度，并支持按需加载、分层写入、checkpoint 与 Workspace 隔离。文章结论是执行环境可临时，数据与状态须持久，但作为厂商实践总结，缺少失败细节、基准数据和长期验证。
推荐收录，因为它给出 Kimi 在超多租户 Agent 托管中的具体架构取舍：Warm Pool、Scale-to-Zero、虚拟数据库层解决秒级 provisioning 与空闲成本，Filesystem 解决 Sandbox 状态持久化与多 Agent 交接。对做 AI Agent 基础设施、Serverless 数据库和云原生状态管理的读者，可迁移的是执行与持久状态解耦的设计思路。风险是来自厂商博客，成果指标缺少第三方验证和失败案例，引用时需区分宣传口径与可复现证据。
文章复盘网易外贸通从 RDS 迁移到 TiDB 的真实架构升级实践。面对 RDS 单实例 2TB 磁盘上限、大表 DDL 长达两三天、存储成本偏高及缺乏实时分析等问题，团队基于高度兼容 MySQL、存算分离与 HTAP 能力选择 TiDB。迁移后同样的数据单副本从 1134.25G 压缩到 345G，部分文本表压缩比达 1/8，DDL 降至秒级且不阻塞业务读写，数十亿行大表可做 T+0 联合查询，并可用 SPM 直接绑定执行计划而无需发版。文中还总结了优先选自增主键聚簇表、用完整库导入验证真实压缩比、修改 BR 源码适配 100MB 块限制的自研对象存储、借 TiCDC 搭建可回滚反向链路等经验，并初步探索仅只读权限的 AI 运维。整体偏厂商实践分享，收益数据为单方披露，结尾带企业版推介。
推荐收录。文章给出可核验的具体证据：压缩比从 1134G 降到 345G、DDL 由两三天变为秒级、以 TiCDC 保证迁移可回滚，并点出非聚簇表引发空间放大与性能下降、BR 元数据触发 100MB 块限制等真实踩坑。适合正在做 MySQL/RDS 向分布式数据库迁移的 DBA 与架构师参考，其选型方法、压缩验证流程和回滚链路设计可迁移；但收益数据为单方口径且结尾含企业版推介，需结合自身场景验证。
文章以电商订单数据为背景，演示从 TiDB v8.5.3 经 SQLAlchemy 读取数据到 pandas、再用 numpy 完成分析与建模的完整链路。核心内容包括用 to_numpy() 把 DataFrame 列转成 numpy 数组、向量化运算与常用统计函数、Z-Score 标准化，以及基于消费额/下单次数/活跃度按 4:3:3 加权、先用 Min-Max 归一化再生成客户价值分的打分模型，最终把结果写回 TiDB 的 customer_scores 表。文中还列出 8 个常见坑（循环慢、values 与 to_numpy() 混用、归一化除零、std 的 ddof 口径、布尔索引括号、axis 方向、随机种子等）并给出成因与修正。整体偏入门教学，numpy 部分为通用基础知识，深度有限，更适合初学者建立向量化思维与端到端数据流程。
推荐收录：文章给出从 TiDB 读取到 numpy 计算再写回数据库的完整可运行代码链路，且 8 个避坑点附有具体成因与修正（如 std(ddof=1) 与 Excel 口径差异、布尔索引需用 & 并加括号、axis=0/1 方向、随机种子复现），对想把关系型/分布式数据库与 Python 数据分析打通的初学者有直接可迁移价值。主要不足是 numpy 内容较基础、结论多为常识性经验，进阶读者收益有限，建议作为入门参考而非深度技术素材。
文章完整复盘将 PostgreSQL Citus + PostGIS 分片集群迁移至自建 TiDB 的实操过程，先对比两者分布式机制差异（Citus 中间件分片 vs TiDB 存储层 Region 自动调度），再给出全量导出 + 增量回放 + 灰度切流的迁移方案及结构适配、数据校验步骤。核心踩坑是自建 TiDB（TiKV 行存）虽支持 GEOMETRY 与基础 ST 函数，但会忽略 CREATE SPATIAL INDEX，空间谓词全表扫描导致查询数十秒。作者给出三套选型，最终采用拆分经纬度字段、建 Btree 复合索引、业务层 GeoHash 粗筛加内存精确计算替代 PostGIS 索引。结论是 TiDB 可替代 Citus 简化运维并提升吞吐，但空间查询不能直接平移，TiDB Cloud Lake 列存虽支持空间索引却不适合 OLTP。
推荐收录，因为它给出了从分片方案对比、迁移步骤到空间索引兼容性踩坑的完整证据链，尤其是自建 TiDB 忽略 SPATIAL 索引这一具体根因和 GeoHash + 内存校验的替代实现，可直接迁移到类似异构数据库迁移场景。适合负责分片数据库迁移、地理空间数据处理或 TiDB 选型落地的工程读者，文中方案适用范围（OLTP 百万级点位）与列存 OLAP 的边界也交代清楚。
本文给出从 Oracle 11g R2 迁移到 TiDB 8.x 的端到端实施步骤，覆盖迁移前评估、环境与工具规划、对象与 DDL 改造、全量导入、增量同步、数据校验、性能压测、切换演练、正式割接和回退预案。文章强调空字符串与 NULL 语义差异、自增主键热点、大事务、存储过程/触发器/JOB 需下沉应用层等关键风险，并指出 TiDB DM 不能直接作为 Oracle 11g 的标准增量同步工具，通常需结合 OGG、Flink CDC 或自研链路。文中还给出全量导出导入、增量同步配置、行数与字段级校验、压测调优、割接和回退的具体操作及 DBA 交付物清单。其适用边界是异构关系型数据库迁移场景，尤其是 Oracle 到 MySQL 兼容分布式数据库的替换，需先在测试环境完整演练后再执行。
推荐收录：文章不是产品发布或概念介绍，而是把 Oracle 11g 到 TiDB 8.x 迁移拆成可执行阶段的工程手册，包含兼容性风险、同步工具边界、校验方法、压测调优和回退演练等直接证据。适合正在做异构数据库替换的 DBA、后端与 SRE 读者，可迁移其评估清单、DDL/SQL 改造顺序和割接回退流程；不过具体工具版本和参数仍需按实际环境验证。
文章复盘某区县级政务云 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 的工程师有直接迁移价值；但结论基于特定版本与政务云规格，参数调整需结合自身集群验证。
文章复盘一个城市大脑 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 实践：政务协同、烟草数据中台、企业知识库、异构迁移和数据库安全五类场景共用一套数据库底座。做法包括将 12 套政务系统收敛为两个隔离集群，用 RU 配额与优先级做多租户调度；烟草中台以 TiKV 行存和 TiFlash 列存同时支撑交易与分析；知识库把 SQL 权限过滤与 HNSW 向量检索结合在同一份数据上。迁移侧用 TiDTS 编排全量与增量同步，安全侧用 DBNginx 将连接入口变为访问治理入口，结论是共性数据能力应下沉为可调度、可分析、可迁移和可治理的基础设施。不足是文章为厂商实践分享，缺少性能、成本、故障和量化收益对比，方案有效性需结合自身规模验证。
推荐收录。文章给出了多系统收敛为两个集群、HTAP 行存列存协同、SQL 权限过滤与 HNSW 向量检索结合、TiDTS 迁移编排和 DBNginx 访问治理等具体证据，适合数据库平台、数据中台和安全治理工程师参考。其可迁移价值在于把重复建设问题拆成资源调度、分析、检索、迁移与安全等可治理能力；风险是厂商视角明显，缺少量化收益与失败边界，选型时仍需独立验证。
文章复盘得物将自建 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 大版本升级的操作指南，按升级前置、原地升级和迁移升级三个阶段组织。前置阶段列出 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 集群从 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、部分环境信息被脱敏，且少数步骤缺少截图和验证数据，落地前需在测试环境验证。
文章复盘在平凯 Loop 中用 5 个角色 Agent 协作交付啤酒节营销系统的实践，系统覆盖活动、促销、优惠券核销、分群、A/B 实验与看板，含 17 个 REST API 和可运行 Demo。作者关注多 Agent 如何在统一上下文和验收机制下完成需求、开发、测试与部署协同。核心做法包括：一需求一线程并前置验收标准；按 Leader、RD、QA、DevOps 等交付物划分角色；按依赖关系推进；把完成定义为静态检查、自动化测试和真实交互三层证据；将踩坑固化为规则。文中用一次 25 分钟增量变更说明上下文共享、依赖显性化和验收前置的收益，并强调该模式适合边界清晰的轻量系统，生产化仍需补齐认证、权限、审计、监控、备份和合规。
推荐收录：文章不是产品发布稿，而是给出了 5 个角色 Agent 在真实轻量业务系统中的任务拆分、角色边界、依赖排序和多层验收证据，并附 25 分钟增量变更闭环。对探索 AI 工程化、多 Agent 协作或内部工具快速交付的团队，这些实践可直接迁移；同时明确列出 Demo 到生产的安全、合规和运维缺口，避免读者误判适用范围。
文章介绍了青岛市外贸赋能中心从 MySQL 渐进式迁移到 TiDB 的完整实践。背景是业务规模和数据量持续增长，MySQL 5.6 主从架构在部分大表接近或突破 2000 万行后出现索引、分页、聚合成本上升，单机扩展受限，且分析负载与在线交易相互干扰。团队评估了分库分表等方案，认为其只是转移复杂度，最终基于 MySQL 兼容性、分布式弹性扩展、HTAP 能力以及运维工具链选择 TiDB。迁移没有一次性推倒重来，而是先从物流系统和金融平台两套核心系统开始，保留 MySQL 处理小规模业务。实际效果包括 DDL 从十几分钟缩短到秒级，复杂 SQL 从十几秒降至秒级甚至毫秒级，数据链路从分钟级缩短到秒级、人工干预率降低 90% 以上。文章也明确了边界：并非所有业务都适合分布式数据库，数据量长期稳定、低并发的小系统仍应使用单机 MySQL。
这是一个真实数据库选型与渐进式迁移案例，完整展示了从性能拐点识别、候选方案比较、迁移策略设计到效果验证和适用边界的全过程，不是单点技术技巧堆砌。适合数据库架构师、数据基础设施负责人和需要向分布式架构演进的团队参考，其中的分阶段换道、场景取舍与成本评估方法可直接迁移到类似系统。
文章以TiDB生产环境中的三个真实SQL调优案例为主线，展示从“跑不动”到“飞起来”的完整排查过程。第一个案例是因统计信息过期导致优化器误判筛选率，未走联合索引的最优范围，通过ANALYZE和配置自动收集恢复性能；第二个案例是分区表查询因NOW()等非常量表达式导致分区裁剪失效，改写为常量时间后恢复正常；第三个案例是自增主键在聚簇索引下形成写热点，通过AUTO_RANDOM或业务主键加预分裂分散写入。每个案例都给出根因判断、优化SQL和执行计划变化，并总结出先看执行计划、重视统计信息、预防写热点三条方法论，附有诊断命令速查。边界在于案例基于TiDB特定实现，部分结论对传统单机数据库不一定适用。
推荐收录。文章不是零散技巧，而是围绕具体线上问题的诊断链路：现象、根因定位、方案验证和预防措施都写得很清楚，适合TiDB/分布式数据库运维和SQL调优读者。文中关于统计信息、分区裁剪、写入热点的分析方法可迁移到其它分布式或关系型数据库，只是需要结合各自引擎特性试用。
本文基于古珀医疗在区域医疗健康平台建设中的实践，复盘其数据库架构从 MySQL 到 MongoDB、再到 TiDB 的演进历程。早期单体医院项目数据量小，MySQL 可支撑业务快速上线；当业务扩展到区域级和省级平台后，数据规模增长至数十TB，MySQL 在 DDL 变更、写入容量和运维成本上出现瓶颈。MongoDB 的文档模型提升了迭代灵活性，但复杂关联查询和空间成本限制了其适用性；Doris、ADB 等分析型数据库性能好，却因私有化部署和数据同步链路复杂而未采用。最终选 TiDB 主要看中其水平扩展、HTAP、MySQL 兼容和 TiCDC 实时同步能力，并在区域医疗健康大脑、智慧法医等四个核心场景规模落地，最大单集群 80TB。文章也说明没有绝对完美的数据库，需根据场景组合使用多种存储技术。
推荐收录，因为它呈现了真实业务约束下的数据库选型与切换过程，给出了从数百GB到80TB数据规模时的取舍依据和多个核心场景的落地形态。适合在医疗/政务等私有化部署环境下做数据架构选型、或评估分布式数据库替代 MySQL 的读者参考。文中对 HTAP、MySQL 兼容生态和同步链路需求的判断，可迁移到类似高可靠、强一致的数据平台建设中。
作者作为分布式数据库从业者，完整记录了通过 TiDB 官方 PCTA、PCTP、PCSD 三级认证的过程与备考策略。他将三个阶段分别类比为 AI 预训练、领域微调和推理增强：PCTA 覆盖集群架构、Region/Raft/TSO、部署与工具；PCTP 聚焦生产管理、备份恢复、迁移和高可用，并以首考 41 分（及格 42）失败后强化故障演练二战通过的经历说明实战的重要性；PCSD 则转向 SQL 开发侧，考察索引、执行计划、事务与在线 DDL 等细节。文章给出了各级别的知识点权重、官方课程和练习方法，对打算系统学习 TiDB 认证的人有路线图式的参考价值。其边界在于内容围绕官方认证展开，考试细节会随版本变化，未对底层原理展开深入讲解。
推荐收录。它提供了完整的 TiDB 认证路线和结合实际故障演练的备考方法，尤其记录了 PCTP 失败后的调整策略，对准备官方认证或学习 TiDB 运维/开发的读者有直接参考价值。虽然内容随版本可能时效受限，但作为入门路线图仍值得借鉴。
文章以内网环境为背景，详细演示了通过 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 助手的工程师、数据分析师或低代码团队有直接参考价值，关键的环境配置和排错步骤可迁移到类似场景。
本文记录作者基于 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 白名单与操作审计。
文章记录智慧停车平台从 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免费认证学习经历，对TiDB与OceanBase做了MySQL语法兼容性对比测试。测试围绕外键关联表、RANGE/LIST/HASH及复合分区表、在线索引DDL、前缀索引和存储过程等对象的DDL/DML展开，并检查执行计划与错误提示。结果显示两者对MySQL基本语法均兼容，都支持外键约束、普通分区和在线加索引；差异在于TiDB不支持复合分区与存储过程，OB支持；索引选择路径与报错信息也有不同。文章给出完整测试SQL、版本信息和结果截图，但未涉及性能、事务隔离、复杂查询等场景，对比深度停留在功能支持层面，且针对特定版本，结论时效性有限。
文章以可复现的SQL脚本和截图直接对比TiDB与OceanBase在MySQL兼容性上的功能差异，覆盖外键、分区、索引和存储过程等迁移常见场景，对分布式数据库选型和MySQL业务迁移评估有直接参考价值。适合DBA、架构师和迁移项目成员；测试方法可迁移，但结论基于特定版本，使用时需结合最新版本文档复核。
本文作者是一名数据库运维工程师，在一年多内先后考取 MySQL OCP、TiDB PCTA 和 PCTP 认证，并完整复盘了这段经历。文章先说明考证动机来自业务增长和团队引入 TiDB，随后分别回顾三场备考：MySQL OCP 补全了 MVCC、半同步复制等底层原理；PCTA 帮助建立对 TiDB 计算、存储、调度分离架构的认知，并记录了一次扩容磁盘告警的踩坑；PCTP 则深入分布式执行计划、TiKV 底层和集群调优。作者总结了认证是系统化学习的起点，MySQL 与 TiDB 互补而非替代，分布式数据库对 DBA 能力提出新要求，并强调动手实验的重要性。最后给出夯实 MySQL 基础、以认证为脚手架、多动手、关注社区等建议。文章适合数据库运维人员和计划学习分布式数据库的工程师参考，但属于个人经验分享，深度和通用性有限。
文章以真实考证经历为基础，具体描述了从单机数据库到分布式数据库的学习路径和常见陷阱，对数据库运维人员有直接参考价值。它强调了认证考试作为知识体系化工具的价值，并给出了可执行的实验和学习建议，可迁移到其他数据库技术栈的学习中。主要风险是个人经验成分较多，部分结论需结合实际场景验证。
本文是宁波金唐与平凯数据库（TiDB企业版）在医疗行业落地实践的技术复盘。文章首先分析医疗国产化的特殊挑战，如系统数量多、新旧兼容、7×24小时高可用和海量数据混合负载，然后介绍宁波金唐的选型策略，强调分布式与集中式数据库需按业务规模取舍，并看重TiDB对中小型至大型机构的全场景覆盖、HTAP能力和MySQL生态。通过宁波市全民健康信息平台和海曙区一体化医疗云平台两个案例，作者给出具体性能数据，如诊断匹配查询从109秒降至0.281秒，年度收入报表从350秒降至6秒，并指出性能提升来自数据库能力、冷热分区和持续调优的共同作用。文章也提到迁移后仍需依赖厂商协同调整SQL和索引，并展望医疗AI对高质量数据底座的需求。总体以真实系统规模和多组对比数据为基础，但视角偏厂商合作方，可能弱化迁移中的风险和成本。
本文提供了一手医疗行业数据库国产化迁移的工程案例，包含选型判断、架构决策、真实系统规模和对比性能数据，对负责数据库选型、迁移或医疗信息系统的读者有直接参考价值。可迁移的不仅是具体优化技巧，更是从业务需求出发评估分布式vs集中式数据库、以及迁移后持续调优的思路。由于文章由TiDB社区发布，部分表述带产品宣传倾向，读者应关注其方法和数据，而非单纯的产品结论。
文章复盘了 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 协同排查方式的反思也提供了可迁移的人机协作模式，但读者需注意文中操作涉及直接修改系统表和重启集群，须在受控环境验证后使用。
文章记录了某数据库集群在运行过程中出现响应时间突增、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团队近两年服务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 企业版）替换传统集中式数据库的实践为主线，总结了从架构落地到开发治理的完整经验。作者提出按业务等级差异化设计部署架构：普通系统采用单集群多副本，重要系统采用“3+1 副本”与自动同步复制，核心系统则按“5+1 副本”建设“两地三中心”容灾体系，实现 RPO=0、RTO 不超过 30 秒。在开发治理方面，文章重点说明了数据库对象命名、数据类型映射（如 Oracle 的 Number 与 ZHS16GBK 向 Decimal 与 UTF8MB4 的转换）、索引数量控制、联表数量和事务拆分等规范，并通过自研 DAP 平台将规范嵌入开发测试发布流程，以强控和提醒规则保证执行。文章还提到连接池生命周期配置、慢 SQL 日志关联和常态化巡检等运维治理手段。整体上这是一次金融级分布式数据库国产化的系统实践，但对于小型系统或非金融场景，部分设计可能偏重，需要结合实际业务等级裁剪。
推荐收录，因为文章基于真实金融核心系统上线案例，提供了从部署架构、容灾设计、SQL 规范到平台管控的完整闭环，具有明确的约束条件和取舍逻辑，不是泛泛的产品宣传。适合正在从事分布式数据库选型、迁移或国产化改造的架构师、DBA 和开发管理者参考，其中的分级部署思路、开发规范落地方法和连接池配置策略可迁移到其他数据库工程实践。
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
文章详细介绍了平凯 Loop 多 Agent 协作开发环境的搭建与使用，涵盖架构概览、Agent 角色设计（架构师、开发者、双审查者、测试、文档工程师等）、Skill 技能库准备、Agent 与 Skill 绑定、频道组织、任务工作流以及需求文档转 Markdown 的多种方式。文中给出了具体的 Agent 系统提示词、配置参数和操作步骤，强调角色分离、交叉审查等实践，并提供了从需求分析、编码、审查到测试、文档的完整示例。文章面向从零搭建多 Agent 开发团队的用户，适用于私有化或 SaaS 部署，但内容高度绑定 Loop 产品，部分建议依赖平凯/TiDB 生态，模型可用性受部署环境限制。
本文提供了可复用的多 Agent 协作开发配置模板，包括角色设计、提示词编写、审查流程和技能绑定，对希望构建 AI 辅助开发工作流的团队有直接借鉴价值。适合正在探索 Agent 协作开发、代码审查自动化或工程效率提升的开发者与技术负责人。主要风险是内容高度绑定平凯 Loop 产品，部分 Skill 和模型建议依赖特定生态，读者需抽取其团队设计思想与工作流模式，而非照搬操作步骤。
文章围绕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恢复方法具备可迁移性，但需注意版本差异和数据一致性风险，建议结合官方文档使用。
文章记录了永康市卫健委全民健康平台为解决业务高峰负载过高与容灾需求，采用平凯数据库物理复制能力进行架构改造的实践。改造将主集群专注核心事务，备集群承担报表查询等读操作和容灾角色，实现读写分离。上线后故障切换低于15秒且数据零丢失，系统负载下降，运维操作秒级完成。文章解释了物理复制基于日志实时同步所有数据库对象，支持最大保护、最大可用、最大性能三种模式，并与 TiCDC 逻辑复制对比，指出物理复制适合集群级容灾和读写分离，逻辑复制适合异构同步与数据管道。实际指标依赖网络拓扑和负载，且相关能力仍在演进。
推荐收录，因为文章提供了真实医疗场景下的数据库高可用与读写分离改造案例，包含明确的问题定义、技术选型依据、实施效果和方案对比。适合关注核心系统容灾、分布式数据库选型或架构优化的读者。可迁移价值在于展示了物理复制在强一致需求下的应用边界，但需注意厂商案例可能带有一定推广成分。
文章记录了在 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 或学习分布式数据库基准测试和初步排障的工程师，文中命令和排查路径可直接迁移到类似环境。主要风险是部分优化建议如降低隔离级别需结合业务正确性验证，不宜直接照搬生产环境。