因为慢查询记录的方式是 SQL 每执行一次超阈值就记录，所以生产上慢SQL量很大也不好分析，所以借鉴mysqldumpslow、pt-query-digest 等分析慢查询的工具思路，以聚合的方式展示结果，你可以看看

我要挑战

没有。除非只校验条数，写个count脚本

停止DM，重构此表，在开启DM

是的，校验本质上是对范围的列进行hash值运算。字段不同，就算出来肯定不同。不过印象中syncdiff是有注释忽略某列的功能的。可以把多的列注释掉试试。

底层存储逻辑不同，一个是BTREE单机 一个是LSM分布式，先考虑底层适合什么在谈上层redo undo吧。鱼和熊掌不可兼得

字增列需看看你DML语句是什么，你所谓的12345，1001，1002这些是否通过DML语句显示的修改（一般来说字增列都是自动填充的），自动填充两边则会存在自增列不一致的状态。更建议TIDB这边开始就使用AUTO_ID_CACHE 1。DM同步表结构后是可以手动修改的

1、减少并发。2、业务层优化逻辑，减少冲突。3、优化SQL本身，缩短执行时长。其实本质上都是减少锁冲突时间。

因为没有GC，随着delete进行,数据是越来越多的（底层的delete不是删除数据，而是将数据标记为垃圾数据，在GC时才回清理），所以region数量不停在涨。GC卡住的原因，看一下GC时间设置，以及是否有其他的事物堵塞了GC。

单从TIDB层面（计算层）是可以的，但TIKV暂时还做不到，读写分离在MYSQL本质上是主从的读写分离，TIDB架构本身就是分布式的，读写在KV层以及平均打散在三台机器上，理论上这种模式比主从更优。如果非要搞成跟mysql主从一样的读写分离，读写事物互相不影响情况下，整两套集群使用CDC同步，一套写，一套读也可以。

我要挑战

仅仅是单表的操作分区表可以的，没说不行。但多表关联分区表确实容易出问题

没办法的，变更类型需要把数据全部load到tidb再回写回去，肯定慢。可以实时查看ddljob，admin show ddl_jobs 看下实时进度。

TIDB不支持存储过程。。

如果业务涉及此表多表关联，不建议使用分区表，执行计划不稳定。如果仅仅是单表的增删改查，以及历史数据维护，分区表没问题。