多副本的，坏了一个节点数据不会丢失

学习了

3节点损坏一个节点，数据会丢失吗

过多的索引会增加写入开销，并占用额外的存储空间。

一般推荐： INDEX(a, b) 原因： 联合索引遵循最左前缀原则 执行顺序是： a = xx → 精确定位 b range → 在 a 的范围内扫描

确认 PD 调度器是否开启 查看当前调度器： pd-ctl -u http://pd:2379 scheduler show 正常应该有： balance-region-scheduler balance-leader-scheduler balance-hot-region-scheduler 如果缺少，可以添加： pd-ctl scheduler add balance-region-scheduler 说明： scheduler 作用 balance-region-scheduler 均衡数据 balance-leader-scheduler 均衡 …

1 调整 PD replica 调度并发 默认很小： replica-schedule-limit = 4 可以调大： pd-ctl config set replica-schedule-limit 64 作用： 同时补副本任务数量 文档说明： 该参数直接影响节点故障后的副本恢复速度

在麒麟 V10 是否必须设置 一般数据库服务器结论 参数 是否必须 ip_local_port_range 推荐 rmem_default 可不调 rmem_max 可不调 wmem_default 可不调 wmem_max 可不调 原因： 现代 Linux TCP autotuning 会自动调整缓冲区 默认值已经比较合理

两阶段提交，保证分布式事物一致性

TiDB GC 是分布式并行执行的，不是串行。 TiDB 3.0 以后默认使用 Distributed GC。 GC流程： PD / GC Leader 只负责： 计算 safe point 更新到 PD 每个 TiKV 节点 自主执行 GC： 扫描本节点 Region Leader 删除旧版本 所以并行度是： TiKV节点数 × Region数量 假设： 3 TiKV 每个 TiKV 1000 Region GC时： 3000 Region 并行处理 不是： 表1 → 表2 → 表3 也不是： Region1 → Region2 → Region…

默认迁移比较慢，可以临时调高： tiup ctl pd -u http://pd:2379 config set region-schedule-limit 64 tiup ctl pd -u http://pd:2379 config set leader-schedule-limit 64 tiup ctl pd -u http://pd:2379 config set replica-schedule-limit 64 查看： tiup ctl pd -u http://pd:2379 config show 这样 PD 会自动把 region 从 tikv001 迁移到 …

[Screenshot_20260313_100625_com.huawei.browser] 这里，有按照版本的相关文档

在新版本 TiDB 中： parser_driver 已经 不在这个路径了。 老版本： github.com/pingcap/tidb/types/parser_driver 后来 TiDB 重构源码后变成： github.com/pingcap/tidb/pkg/parser_driver 或者直接使用 parser 模块。

链接可以打开

以后都得国产系统

Merge 任务占用大量内存 例如： background merge 当很多 small part 合并时。 可以查看： SELECT * FROM system.merges;

[server] collation-server = “utf8mb4_bin” new-collations-enabled = false # 强制用旧框架

tidb兼容mysql协议，应该为啥问题

这个工具是tidb自带的吗