扩容后热点不会自动均摊完。PD 日志里 transfer-leader 慢，说明调度在排队或被限流。先看 hotspot scheduler、store limit、region count 是否打满老节点。可临时提高调度限制、对热点 region 手动 split/transfer；长期要打散热键，避免写入仍集中在旧 key 范围。

Oracle 分区裁剪和 TiDB 的 Region 分布不是一回事，原样迁过来范围扫容易变宽。用 EXPLAIN ANALYZE 看是否扫了过多 Region，核对分区键是否出现在查询里。可补分区/索引、改写范围条件，或把分析查询丢 TiFlash。机器内存 12G 对 500GB 表也偏紧，先确认 TiKV 没在换页。

批量高频改同一分区，Region 会打热，TiFlash 也要消化同样写入，延迟会一起涨。先限流、拆小事务、按主键打散；看 TiKV busy、write stall 和 TiFlash replay。手动 split 只是止痛，长期改写入模式、索引和分区键，避免反复打同一段。

同等双节点堆配置迁过来，不一定更快。医院核心表更适合 TiDB 8.5 LTS，硬件按 TiKV 多节点、存算分离来规划，不要两台 RAC 对等替换。先做 SQL 评估和热点改造，分区表按主键/业务键重新分布，高峰压测后再切。

Oracle 经验能复用备份、容量和故障思路，但要补分布式：Region、PD 调度、TiKV/TiFlash、GC。建议先官方课程加一套测试集群做扩容、备份、热点和升级演练。中小规模独立值守通常两三个月密集实践，生产值班还要跟几次真实故障。

长事务会挡住 GC、堆 MVCC、占内存和锁，严重时拖复制。用 INFORMATION_SCHEMA.TIDB_TRX / 慢日志找超长事务，设 tidb_max_txn_ttl 并监控 lock wait。业务拆批、尽快提交；分析类查询不要包在大事务里。

热点先看 Dashboard 流量可视化和 tikv_hot_write。业务侧避免自增主键、时间热键，改用离散主键或加盐。库侧可开 hotspot scheduler、合理 split、控制事务大小。事务尽量短、少跨行、冲突键分开提交。

游标只降低客户端取数，服务端仍可能把大结果放进内存。可调大 tidb_mem_quota_query 或打开 oom-use-tmp-storage，并确认会话级 tidb_enable_tmp_storage_on_oom。长期仍建议服务端下推过滤/分区裁剪。改 JDBC 不够时，用资源组或限流保护集群。

region is unavailable 多半是 leader 在切或短暂不可达，不是整节点挂了。高峰先看 PD 调度、TiKV 心跳和该 region 所在 store 的 CPU/IO。排查 region_id 的 leader、是否在 split/merge、网络丢包。临时可降并发、避开热点键；根因常是热点或调度过猛。

toml 已变但查到的还是 20，多半是看的不是运行中配置，或该参数要进程真正重启才生效。用 SHOW CONFIG 按 tikv 和参数名对每台核对，并确认 reload 没有跳过重启。若文件对、进程也重启过仍旧值，把完整配置查询结果和集群 display 贴出来，排查是否改到了别的实例。

可以。max_execution_time 只在 TiDB 侧掐断 SQL，TiKV coprocessor 默认仍可能跑到约 60s 的 deadline。把 tikv_client_read_timeout 调到比语句超时略大（例如 3s）能更快取消对 TiKV 的 RPC。不要设得过小，以免正常慢查询被误杀；改完用一条会超时的 scan 看 TiKV CPU 是否尽快回落。

不会取消 TiKV 上已经在跑的 cop task，两者管的是不同层级的超时，机制不一样。

那你就连续打卡100天

这个好，搞下来试试去

帖子里没有完整报错文本，需要把 tiup 的完整错误和 topo.yaml 贴出来。常见是 SSH 失败、端口或目录冲突、架构不匹配。先看报错第一行和失败的那台主机。

tiup reload 在生成配置时缺镜像文件，说明本地或离线源里没有该版本组件包。补全对应版本的 server 包后再 reload，或检查 tiup 镜像目录是否拷全。不要只重试同一条命令。

PD 短暂把两个节点的 leader 迁走又迁回，通常是心跳抖动、调度器或 store 短时间不可达，不一定是 CPU/IO 已经打满。去 PD 日志里对时间点查 evict/transfer 原因，并核对 TiKV store 状态。CDC 主节点掉线也可能是这次 region 迁移触发的 owner 重选。

单机最小拓扑可以用来试用，确认拓扑后输入 y，并保证 SSH、端口和目录都不冲突。卡在 Generate SSH key 时检查本机 ssh-keygen 和到目标机的免密。生产不要把 PD、TiKV、TiDB 全堆在一台机器上。

Follower 的 PD gRPC P50/P99 到 10 秒，TSO 慢多半出在 follower 代理而不是 leader。先关 open-tso-follower-proxy 或别让客户端打到不健康的 follower，再查该 PD 的 CPU、磁盘和到 leader 的网络。max-tso-batch-wait-interval=10ms 只会叠加等待，治不好 10 秒级延迟。