看起来是上游mysql的创建表语法同步至下游tidb不兼容引起报错，确定这个语法是tinyint default引起嘛？

placement-rule + label标签，应该可以满足你的需求

应该还是需要主键吧，毕竟是逻辑抽取数据。类似ogg工具，没有主键也能同步，但是都不保证数据一致性，，，

大容量sata盘本来读写就超级慢，建议检查下这些磁盘的IO性能和繁忙情况

Prometheus、grafna这两个监控组件重启或者重载一下，应该就可以了。

参考这个： TiProxy 简介 | TiDB 文档中心

information_schema.tables 表TABLE_ROWS这一列，明显是统计信息收集时的行数据，不是实时精确的。 参考这个： TABLES | TiDB 文档中心

临时空间用完会回收清理的，是否增长，要尽量在使用过程中观察。 tidb ddl都是排队通过owner节点来处理，需要观察运行时间段。 确定这在两个条件下，tmp没有增长？

扩容TiDB的tikv节点后，新增的tikv数据节点数据均衡很慢，有没有加速的办法？ - TiDB 的问答社区 这个也仔细参考下，看有没有适合你的

看下各个kv节点上的region分布情况。 如果是region分布不均衡，可以参考这个分析下： 专栏 - 【SOP 系列 19】region 分布不均问题排查及解决不完全指南 | TiDB 社区

两个视图查看 INFORMATION_SCHEMA.TIKV_REGION_PEERS和 INFORMATION_SCHEMA.TIKV_REGION_STATUS 或者 也可以通过pd-ctl查看 https://docs.pingcap.com/zh/tidb/stable/pd-control#查询-region-副本的分布情况

应该只有国家软考才可以

[image] 文档上有描述 DM 任务完整配置文件介绍 | TiDB 文档中心

scale-in –force强制缩容这个节点，再重新扩容scale-out，这样试一下是否可行

dumpling+lightning全量同步数据，然后用ticdc同步实时数据过来。这方式稳妥，方便测试，校验数据，还可以进行业务功能测试。

应该是的，通过tidb方式作为接口后，tikv组件就主要负责kv存储了。其它内部的通信由tidb分布式集群组件(tidb,tikv,pd)自己完成。

shop_id 和 end_time 刷选出来的符合条件的行数有多少，，具体得看选择率，如果符合条件得行很少，试试联合索引有没有效果，等值查询的列放在联合索引中的前面。

我记得当时是回复那个tidb数据迁移的方案问题，，，

参考这个排查热点region： PD 调度策略最佳实践 | TiDB 文档中心 另外， TIDB_HOT_REGIONS_HISTORY`表提供了关于历史热点 Region 的相关信息，参考下面文档： TIDB_HOT_REGIONS_HISTORY | TiDB 文档中心