你要改的到底是tidb集群，还是dm集群?

统计信息不准啊， [image] 预测行数，和实际行数差异这么大，能选择对执行计划吗？ 他以为你只有428条，那你limit 10000也就返回428条，全部返回后排序就行，但是实际你有21W条，需要排序后返回前10000条，肯定走不对执行计划

【大家所在的行业是什么？】 运营商 【所在行业对数据库容灾有哪些具体需求？】 高可用性+快速恢复 【目前正在采用的容灾方案是什么？】 oracle 是rac+归档/rman；tidb是集群+br备份；mysql是主备；

执行tiup命令都是通过ssh连接到各个机器的，你ssh到各个机器，然后执行下ulimit -a看下

测试下tikv机器的io看下，磁盘是是磁盘，通过什么方式挂载到服务器上的

统计信息看下准吗

这不是默认的执行效率比强制指定的索引还要高吗？那选idx_seller_id_create_time_us这个索引肯定的啊

贴下卡死的sql执行计划看下

[image] 在这里配置

replication.max-replicas参数设置为1，所有数据保持1份副本，可以存放84T的数据

如果你是oltp和olap的混合使用的系统的话，肯定上tiflash更合适，一般聚合类的sql自动会走tiflash，对你的oltp业务影响更小，当然如果你的数据会通过其他方式同步到数据仓库或者数据湖里面的话，纯粹的oltp业务，只是用tikv就可以了。

1.确认表是否使用了聚簇索引，以及主键的第一列是否为可分割类型（整数或二进制字符串），对于具有非可分割主键的表（如非整数或非二进制字符串的第一列），TTL 任务会在单个 TiDB 节点上顺序执行，可能导致性能瓶颈。 2. tidb_ttl_job_interval,控制 TTL 后台清理任务的执行频率，如是上面问题，可调小，让任务执行跟频繁，减少单次 TTL 任务处理的数据量 3. tidb_ttl_scan_worker_count，控制用于扫描过期数据的并发工作线程数，可调大，但是要注意对生产的影响 4. tidb_ttl_delete_worker_count，控制用于删除过期数据…

TopSQL 的数据保存期限大家一般会设置多久？ 一个月 除了现有的 cpu 指标，大家觉得哪些指标比较有必要体现在 Top SQL 里，在定位问题/监控时，大家需要看哪些常用指标？ 语句执行次数，执行时间，总占用时间，执行计划，占用内存 有没有一些在其他数据库看到的比较有价值/有帮助的指标，在 TiDB 里没有的（也可以分享下，我们多多进行优化改进！） 这个暂时还没关注到。

日志就这么多，下面没有了？

新增集群状态时怎么样的？tiup cluster display 集群名看下，如果其他两个pd正常，只有这一个异常，直接scale-in缩容掉，然后再scale-out扩容一下就行。

就是统计信息太旧了，优化器感觉数据量太小，不需要用 Hash Aggregation， Hash Aggregation算法采用多线程并发优化，执行速度快，但与 Stream Aggregation 算法相比会消耗较多内存，所以选择了 Stream Aggregation 你收集完统计信息的最新执行计划看下，应该自动选择了Hash Aggregation

在备节点（三个机器随便找一台）安装tiup并配置原来集群的信息，topology.yaml （需要将原来集群节点的信息都录入， ip、port、配置、label都要和原来一样， 可以登陆每台机器查看一下） 然后执行 tiup cluster deploy tidb-xxx ./topology.yaml tiup cluster display tidb-xxx 看下能看到集群不能。。。

java里面的会话的这俩参数看过吗？ SHOW SESSION VARIABLES LIKE ‘%tidb_partition_prune_mode%’; SHOW SESSION VARIABLES LIKE ‘%tidb_allow_mpp%’;

SHOW GLOBAL VARIABLES LIKE ‘%tidb_partition_prune_mode%’; SHOW SESSION VARIABLES LIKE ‘%tidb_partition_prune_mode%’; SHOW GLOBAL VARIABLES LIKE ‘%tidb_allow_mpp%’; SHOW SESSION VARIABLES LIKE ‘%tidb_allow_mpp%’; SHOW SESSION VARIABLES LIKE ‘%tidb_enforce_mpp%’; 看下这些参数的配置 不行在java的连接配置中设置下tidb_e…