目前 tiup dm 没有等价于 tiup cluster show-config 的只读命令，查看拓扑只能走 tiup dm edit-config 或读 ~/.tiup/storage/dm/clusters/<name>/meta.yaml。edit-config 会进编辑器，生产上务必 :q 退出，避免误保存后 reload 把变更打到集群。需求可以提 feature request，现阶段按只读文件查看更稳。

先 tiup dm list 拿到集群名，再 tiup dm edit-config <name> 打开拓扑 YAML。只看配置时在 vi 里 :q 退出，误改用 :q!，不要 :wq，否则会写本地元数据，随后 tiup dm reload 就会下发到集群。只读导出可直接看 ~/.tiup/storage/dm/clusters/<name>/meta.yaml。

Tombstone 只表示 PD 已摘除该 store，RocksDB 的 SST 不会随 region 迁走自动删掉，所以磁盘占用可以一直不变。多 AZ 下 placement rule 常让副本优先留在本 AZ，迁出更慢，空间回收也更不明显。先确认 tombstone store 上 region 已到 0，用 pd-ctl store remove-tombstone 清掉记录；空间仍不降就对残留数据目录做 compact，或确认无副本后直接销毁该节点数据目录再释放云盘。单 AZ 往往迁得更快，看起来像“没有这个问题”。新增节点涨空间是在接副本，属于预期。

8.5.7 的 S3 客户端校验和头与华为 OBS 对不上，所以 PutObject 报 XAmzContentSHA256Mismatch。可先继续用 7.5.7 做日志备份，或查该版本是否支持关闭校验/改签名方式。endpoint 和 path-style 要与 OBS 文档一致，单改密钥解决不了。

医院核心库很难真正零停机。TMS 可走全量+增量，切流前用对账和只读流量验证，Oracle 先保留可回滚。SQL 上重点核对空串与 NULL、序列、分页和过程函数。窗口尽量缩到秒级切换，而不是承诺全程无感。

日志是 TiFlash 计算内存打到上限后 OOM。先降 MPP 并发和单查询扫描范围，避免超大 join/聚合打到 TiFlash。可调 TiFlash 内存相关配额，并把过重的 AP 拆批或加过滤。重启只是止血，不改查询和并发还会再炸。

扩容后热点不会自动均摊完。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天