对，你要先扩容tikv，然后再下掉。tikv至少保证3个可用

重做系统后，数据 清空了吗，你看看数据在哪。清空后就行了。另外集群现在是几副本，如果是3副本，tikv 只有3个节点 是下不掉的

看错了，这是监控组件，不是tidb ngmonitor 不是必要组件，没需求的可以忽略

那就等等吧

用这3个SQL查表名 SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA a WHERE a.table_id=‘2455218’; SELECT * FROM INFORMATION_SCHEMA.tables c WHERE c.tidb_table_id=‘2455218’; SELECT * FROM INFORMATION_SCHEMA.partitions b WHERE b.TIDB_PARTITION_ID=‘2455218’;

确实命令行没问题，看来是sqlyog 不支持

补充下表结构 表结构.txt (18.8 KB) CREATE TABLE `tb_agent_user_project` ( `user_id` bigint(20) NOT NULL, `project_id` int(10) NOT NULL, `type` int(1) NOT NULL COMMENT '0: 管理员资源，1:普通用户资源', `source_type` int(1) DEFAULT NULL COMMENT '0:权限分配，1:下级同步', `create_time` datetime DEFAULT CURRENT_TIMESTAMP CO…

有没有临时避免的方式？业务sql大多就是这种类型。现在虽然通过去掉tiflash副本解决，但是响应结果变慢了

panic 日志，只要涉及到sql 涉及到mbg_core.emarbox_project，走tiflash就会有 panic.txt (22.6 KB) plan replayer 跑不了 [image]

下游手动执行没问题 [image] [image]

就是个普通的自增表，从mysql同步到tidb。没有SHARD_ROW_ID_BITS

确定是bug,在7.5.3 修复了

查询太多会把tiflash搞down， mv 确实能修复，只能说尽量暂时 不搞跨库的分区表

这次是挨个重启tiflash 修复的，有啥临时方法避免吗， 毕竟线上重建新表是很频繁的操作

select正常的，只是batch on报错，就算把where字段加到select 里也报错

所以还是要S3,分布式的存储才能发挥作用，单机的话和别的方式没区别

新的执行计划 [2ff97f4225bf6d5da359ac7c22b93d9]

SQL改成left join,并加 (tenant_id ,link_id ,link_end_time )`的联合索引解决热点

是的，现在都是动态分区了，结果执行计划显示的内容让人疑惑