[image] 正常

[image] 嗯，是升级上来的。当时改这个是因为7.5 刚开始不稳定 mpp老崩。 后面我再验证下吧。

你tidb版本新一点的话（好像是7.3之后 集群版本是7.5.4 [image] 其他的感觉也不会加太多的cast 查了一下，基本都是bigint 和varchar转义，典型的一时找不出。找到了再发帖吧。 再次感谢回复

感谢回答。 1、加了group by 确实会去走mpp [image] 2、关于优化器问题， 有排查的建议吗 3、关于tiflash的类型推导，是不是为了兼容mysql，来确保行为一致。这边业务大量依赖tiflash，现在有很多的cast，导致优化的时候比较茫然（应该重新设计字段类型，还是显式的cast）。最好有文档能详细描述tikv和tiflash的差异。目前的文档还是不够详细。 [image]

[image] 我这不行， 就算走mpp，tiflash也是转义成decimal啊，为什么bigint类型不是直接求和呢

关闭 tidb_enable_historical_stats drop stats 之后重新analyze，还是报错 [image]

集群是4版本开始 慢慢升上来的， 这次7.5 是从6.1 升上来的。 这个分区表都有2020年的数据，所以基本没有变更，操作就是把历史分区合并 tidb 错误日志 analyze-tidb.log.gz (1.3 MB) [image] 错误表iD 是分区 209616 [image] 2879028 [image] 健康度 [image]

我这里环境是稳定复现，换个集群或者复现步骤 就不行了 [image] [image]

尝试建新表 analyze之后没有复现出来

老版本的kill 如果不好使， 可以找owner 去kill 或者重启 1、找出 DDL owner 节点： 通过 curl http://{TiDBIP}:10080/info/all 获取当前集群的 Owner， 2、如果 Owner 不存在，尝试手动触发 Owner 选举： curl -X POST http://{TiDBIP}:10080/ddl/owner/resign

对，你要先扩容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]