任务状态是Paused的，已经停掉的

tiup dm display这个查看版本也是v2.0.4 [image] dm-worker上没任何记录输入

数据源还有其他的任务在跑，不能直接删除掉数据源

这个版本号是执行tiup dm list查看到的 [image] 执行删除操作命名，dm-master输入如下的日志：就这一条 [2025/02/28 17:23:03.715 +08:00] [INFO] [server.go:2206] [payload="op:7 name:"tidb-xlg-mysql" "] [request=OperateTask]

最近准备在数据流转中大量使用TiCDC，需要提前完成TiCDC的吞吐量和性能

嗯嗯，是这个原因导致的，设置max_execution_time这个比较小，导致超过个这个时间被中断了

一周一次，实践案例、问题和解决方案等

场景描述： 物化视图可以说是目前某一类业务强需求，之前业务明确提过，当前的主要用在获量业务，涉及营销数据、各类游戏分析大盘等； 物化视图的基表5~10张左右，单个表的数据量大概在3000万左右，宽表，基表的数据有实时或定时的写入、更新和删除操作；针对当前TiDB不支持无法视图，业务采取其他的方案替代，按照目前的情况，延迟在10min以内应该是可以接收，具体可能还需要和业务确认 痛点描述： 您的系统是如何支持这些业务的，有遇到哪些痛点？ 1、当前业务采用中间表的方式，预先将多表复杂查询的结果存储在中间表中，并且该表数据会更加业务时效性的要求，定时的进行更新； 2、子查询通过CTE表达…

最大4点收益： 1、高可用切换更加丝滑 2、减少很多对复杂AP类SQL语句的改写和优化 3、弹性扩缩容，业务几乎无感 4、数据迁移、流转、日常运维更加方便

七夕礼物很有心，一定喜欢

tab2上和tab1也一样，有一个复合主键索引，只是没有用到索引

sorry，贴的有点问题

在里面，是这个dim_timeslice字段

有一个复合主键 PRIMARY KEY (dim_timeslice,dim_blid,dim_plid,dim_apptype,dim_appid,dim_dwsiteid,dim_advsiteid,dim_djid,dim_videoid)

确实是客户端加了 limit限制，没有limit限制也不快，这个字段timeslice是bigint类型，这种情况下有优化的方案吗

这升级后的效果确实明显

每位老师讲的都不错，收益颇丰

所有集群从5.0.3替换成6.5.x版本

升职加薪