蹭蹭

我一般都是直接restart tidb节点 反正是分布式的，反正都慢的不得了了，快速重启就好

直接delete即可，等GC时会自动回收并compaction释放空间的，无需rebuild

哈哈哈，要不要用这个工具瞅一眼：https://github.com/realcp1018/tidb-toolkit/blob/main/scripts/tk_pdctl.py 填个IP和Port即可

低版本是木有的，看下prometheus的metric里有没有同名的metric就知道啦 我也是前段时间才发现7.0多了好多详细的指标

停掉exporter就知道了，tidb的延迟指标应该使用tidb-server:10080里获取的，没啥影响

类似吧，通过读取meta.yaml修改并覆盖原内容，reload之后所有tidb实例的配置文件都会显示已同步修改。

补充： 这几天排查下来发现还有一个6.5.1版本的集群有相同的现象，一直以来我们binlog的安装方式是安装好pump组件之后，修改tidb实例的binlog.enable参数然后reload tidb。 开始我认为是pump组件的安装有问题，reload tidb之后应该restart一次，因为两个集群的共同现象是只有1个tidb实例的binlog生效，可能是reload滚动重启带来的问题。 但后来想想这种修改tidb配置后进行reload也没啥逻辑缺陷，在一个7.0的集群上试了一下装好的binlog在所有tidb也都生效了。 目前是怀疑某些版本的tiup/tidb/binlog在r…

回复楼上两位好心人 ： 统计信息现在看正常，没有analyze历史，我们每天会有定时任务手动更新统计信息。此外我这边gc间隔较短，并发只有25个，每个并发一次删1000条数据，不容易产生堆积。 数据量方面也应该不到足以放弃tableRangeScan转为走唯一键的程度，因为要删除的数据实际还很多，相比1000条的rowid范围算很小了。 但目前确实也只看作是统计信息有变动导致执行计划有变，我觉得优化器没有对这方面做专门的加强。 当前改进是先加了hint，看看以后还会不会出问题了，针对本次效果还是很好的： [image]

[image] 嗯 如楼上所示，默认就是不限制

以前收藏了一个大规模删除实践，现在居然失效了。不过你可以通过information_schema.cluster_config查看相关指标的生效值。 我把我收藏的截个图你可以参考下： [image]

你说的真的是一个很巧妙的办法，可以新建表并导入统计信息！ 如果能有内置的虚拟索引并自动生成统计信息的功能那就太好了。

类似如此，我大致描述下使用场景： 我有一个数十亿的表，现在发现有一个SQL执行会导致IO打满，因此在查看了相关列的histogram和buckets统计信息后决定加一个索引，我可以大致推测出这个索引可能会起到效果，但是我无法100%预测SQL优化器面对此索引的反应，如果我最终耗费时间建好了索引却发现未如预期那样生效，那就做了很多无用功。 我理想中的处理手段： 创建一个虚拟索引，并为此虚拟索引收集统计信息(自动or手动皆可，甚至可以导入)，然后观察优化器对此的反应。

嗯嗯 我想我要的功能是模拟给表新建索引并生成虚拟的统计信息，然后据此观察SQL优化器的反应

你这么一提，我突然发现我的表述可能是错的，我想的是伪造索引，然后根据新索引进行执行计划查询。

额，我们的实践也是2个副本即可。 但性查询性能主要和节点数有关，多加节点才能利用MPP架构实现加速。

问题找到了，孤儿tidb没找到，找到一个显示binlog enable但是其实没开的tidb实例，就是上边截图里那3个binlog.enable为true的其中之一。 3个tidb都试了下，其中两个能正常产生binlog，一个不能，不知道有没有更直接的办法(例如日志等)来证明某个tidb在输出binlog。 在极端异常的场景下，information_scheme.cluster_config表显然也不可信。

[image] 重装还得等到业务低峰期，现在还在找方向，目前感觉可能存在什么孤儿tidb实例，可能会是集群配置方面的问题导致。 上图显示binlog都开了，但我感觉不可信。

[image] [image] 步入玄学领域了，两个DDL之间夹杂一个DML，DML就是被隐藏。