扩容后磁盘数据会自动搬迁，但**高写入热点 Region 受 PD 保护策略，不会自动迁移 Leader；先 split 拆分热点 Region，适度放开 PD 调度限速辅助搬迁，根本要靠业务层打散主键消除写热点。
4 天前
这种情况有多种原因造成，常见原因有以下几点：
应用连接泄漏，连接用完未归还，大量 Sleep 空闲连接堆积；
应用连接池maximumPoolSize设置过大，多实例叠加压满单 TiDB 节点；
代理（HAProxy/LVS）空闲超时与数据库wait_timeout不匹配产生僵死连接；
max_connections设置过小；
慢 SQL / 长事务占住连接不释放。
4 天前
大量全扫描慢 SQL 耗尽 TiKV 的 cop 与 raftstore 处理能力，请求排队超时引发间歇性Region is unavailable；应急 kill 慢 SQL 止损，根本上优化 SQL、设置语句超时、大查询卸载到 TiFlash，避免分析负载冲击在线 TiKV 节点。
4 天前
业务层哈希打散热点主键：避免自增 ID 单点写入，用分片键 / 前缀哈希打散，把写入分散到多个 Region，解决单 Region 写热点。
避免单行高频更新：计数器不要单条行累加，做分桶计数，内存合并再落库。
表分区拆分：时间维度热点按 Range 分区，热点数据隔离到独立分区 Region。
索引热点规避：避免时间、自增列作为唯一索引造成索引热点。
控制事务大小，大事务拆小，减少锁持有时长，减少冲突重试。
4 天前
1、学习TiDB的课程，老师讲的非常详细。
2、自己搭环境，做大量的实验。
3、如果本来是资深DBA，2周完全没问题。
4 天前
长事务风险
占用 MVCC 版本，造成版本堆积，Region 扫描变慢，CPU、内存上涨。
锁持有时间久，容易锁冲突、死锁，阻塞业务 DML。
阻碍 GC，旧快照无法回收，存储空间膨胀。
事务未提交会占用乐观锁的事务 ID，影响全局 TSO 推进。
生产管控手段
设置 tidb_max_transaction_size、tidb_long_trx_threshold 告警阈值，监控告警长事务。
开启 tidb_gc_life_time 合理 GC 窗口，避免过大。
业务拆分大事务，拆成分批小事务；禁止业务交互式长事务。
系统变量 tidb_max_execution_time 限制 …
4 天前
没有更多内容了