嗯嗯，是这个原因导致的，设置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版本

升职加薪

你上下游tidb实例的表是不是一直有数据变更？ 如果是的话，你可能就需要使用 TiDB 的 snapshot 功能，开启的话会使用历史数据进行对比 snapshot = “386902609362944000” 你可以试试

你说的没毛病，但是很多公司DBA是没有root用户登录权限的

那你可以手动设置session级别的tidb_allow_remove_auto_inc变量设置成on，然后在该session手动执行alter 删除主键的SQL语句，然后dm同步任务跳过报错的DDL语句，这样也是没问题的，我生产上很多DDL同步问题，我都是这么干的

tidb_allow_remove_auto_inc变量设置成on，允许tidb移除自增主键，然后之后在调整回去 [image]

生产环境的话，建议创建一个tidb用户，所有节点的tidb用户都相同，然后部署的时候使用tidb用户进行部署，tiup部署的时候加上-p参数，示例：tiup cluster check ./topology.yaml --user tidb -p