可以看第二个日志，日志刷的太多。tiflash一直重复蹦了半个小时，直到强制下线才稳定 [image]

profile 文件 profiling_2025-06-26_17-02-39.tgz (2.0 MB)

生产7.5.4，先观察8.5.2有没有大坑，再决定升不升

【大家的 TiDB 集群数有多少】 生产4个，测试1个 【所在的公司有用海光服务器吗？使用数量有多少？】 没有 【除了海光服务器，目前在用的服务器品牌有哪些？】 浪潮、戴尔

8.5 没问题，看来是已知问题。7.5的小版本修复了吗

可以不用新建任务重新开始 1、 停止异常的任务 stop-task 任务名 2、找到最接近异常binlog 的position， 这里就是mysql-bin.018513，position 4。 3、在下游tidb修改dm_meta.任务名_syncer_checkpoint, 在schema和table为空的行，修改binlog_name和binlog_pos为你希望的起始点。 同时删除 exit_safe_binlog_name和exit_safe_binlog_pos 记录 [image] 4、启动任务，start-task

o ,现在就是这么处理的。 我还以为是别的方法，在原有的任务进行修改。 比如怎么修改dm_meta库的数据，来指定binlog 和position

咋跳啊，能帮忙指导下吗

设置的每个binlog大小是1G, 所以这个512肯定是损坏了。该怎么修复dm同步呢

设置engine 为tidb，tiflash，就会走tiflash [image] [image] 如果用hint的话就是报错 [image] 走tikv 看到warnings [image]

可能我没描述清楚，这个bug可以复现。 1、建立表board_material_rebate_daily_fox和dept_level_fox 2、添加board_material_rebate_daily_fox表 tiflash副本数为2 3、tiflash副本数正常后，用样例SQL查询，可以看到board_material_rebate_daily_fox表走的tiflash 4、 对表board_material_rebate_daily_fox 进行analyze 之后，再用SQL查询，执行计划就走了tikv 5、样例SQL添加 hint，/*+ read_from_st…

【PingCAP 10周年祝福语 】 下个十年见 【你对TiDB 印象最深刻的事情】 开源和社区环境非常棒！

[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]