缩容自动就不会往这几个 tikv 中调度了

了解下ticdc 的 gc-ttl 参数

没有搞过 k8s 【你认为容器化 K8s 部署 TiDB 有哪些优势和挑战？】 优势 交付速度快 更高的资源利用率 挑战 k8s 增加了运维复杂性（最好有一个又懂数据库，又懂 k8s 的人，PS：k8s 本身感觉也很复杂） k8s 的高资源利用率最终是否能带来成本降低？ 最好企业里有整套的云解决方案，深度定制才能玩好。 k8s带来的性能回退问题。

已创建的集群，PD 参数要用 pd-ctl 工具修改

网络的问题

优化器的事情怎么能叫 bug 呢 ，只能说不是最优执行计划 首先：count(1) 和 count(id) 含义不一样，count(id) 会忽略 id 为 null 的列 当 id 列定义中带 not null 时，count(1) 和 count(id)返回结果是一样的，但是 tidb 逻辑优化时好像没有意识到这点 所以 count(id) 的时候不用回表，像第一个执行计划就好了

你这集群不满足官方建议吧，才用了这么点整体使用率都 70% 多了

tidb server 默认是监听在机器所有 IP 的端口的，你用私网 IP 部署就好了，配置文件中都要用私网的 IP 地址

看下前边大佬提醒你的，在文档中为蓝色注意的地方

两个不同组件的不同参数 TiKV 通过在 Key 后面添加版本号实现 MVCC机制，通过 GC 机制将无用的老旧版版数据做物理回收，tidb_gc_life_time 能保证一段时间以内的数据不会回收，tidb_gc_life_time 不是越长越好，太长会额外占用空间，且扫描数据是会多扫历史数据影响性能 TiCDC 依赖 TiKV 的 MVCC 机制来抽取历史一段时间的数据变化，所以 tidb_gc_life_time 对 TiCDC 很重要，当同步延迟超过 tidb_gc_life_time 时，就无法保证数据同步的连续性，导致同步中断，所以 TiCDC 增加了 gc-ttl 参数，在…

不是所有的 tikv 参数都能在线修改，在线修改也是用 set config 方式，能在线修改的，肯定不用重启生效，要重启就不叫在线了 storage.block-cache.capacity 是可以在线修改的 参考：https://docs.pingcap.com/zh/tidb/stable/dynamic-config/#在线修改集群配置

全局读锁，当然对数据库影响比较大了，执行后表只能读取，无法更新了

文档就是官方文档，官方文档写的很好 https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements/

生产环境配置参考官方文档 https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements/#生产环境 各组件尽量不要混合部署，要用 tiflash 一定要单独部署，不用就别部署 tiflash 磁盘要好，分布式数据 TiDB 对磁盘要求高，并且磁盘可能达不到云厂商承诺的性能要求

为什么会有这种担心，各 TiDB 节点是对等的啊，单机房部署，客户端到各 TiDB 节点的网络延迟也是一样的啊

格式不对，用 mysql < 这种方式搞

那不是写了不兼容外键，你自己删一下喽

不能信研发的，开日志看吧，或者去dashboard 看 sql 语句分析