QPS 多少

看下分区的 region 分布。如果集中 1 个节点就试试 scatter。https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md

我理解当前是在 sync 同步阶段了。看起来是拉 binlog 拉不到了？上游 MySQL 日志流程多久的？

[image] CREATE TABLE `t1` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '', `u` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '', `p` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '', `k` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '', `c` date NOT NULL DEFAULT '0…

(root@127.0.0.1) [test]>CREATE TABLE t1 ( -> id BIGINT PRIMARY KEY AUTO_INCREMENT, -> name VARCHAR(32) -> ); Query OK, 0 rows affected (0.07 sec) (root@127.0.0.1) [test]>SPLIT TABLE t1 BETWEEN (0) AND (18446744073709551615) REGIONS 12; ERROR 1690 (22003): constant 184467440737095516…

ROW 格式 会记录所有被更改的行——包括主表的删除以及因外键约束被自动删除的子表中的所有记录。所有受影响的行都会被单独写入 binlog。 你是不是有做过滤？

服务器 IP 有变化么？

不加 index name 就是 table 的 handle id。要么是主键要么是 _tidb_rowid; 加了 index 就是打散索引，就是索引最大最小值。

感觉比较奇怪，我找个研发老师帮忙看看。

哈哈 我感觉也没有必要。 不过可能和语义有关系，所以这个回表不能消掉。感觉可以让优化组老师看看。

看起来是非聚簇表。id 相当于索引列,执行计划多了一次回表。感觉这个回表没必要啊

热点写的话，看下盘的压力，CPU 等资源是不是很高。 可以考虑加个 shard 来打散热点。看看效果。

rawkv 不推荐使用。 主要现在这个产品支持不在我们的主线上。

当前 tiup 还没有完全支持你需要的这个功能。 后续应该会做，整体支持，关注下 tiup 的功能出来吧。 grafana 相关的 args 相关参数已经提了，你可以试试来绕过部分验证/运维。 https://github.com/pingcap/tiup/pull/2516

看看监控，当时 tikv 的压力大不大或者有没有热点。 感觉就是单纯压力大 导致 region 在分裂等，忙不过来。

内部问了下，默认单线程执行的。发现一个 batch on sql 的 cpu 消耗很多？

1： 因为走 tiflash 还是 tikv 默认是根据 cbo 选择的，也就是表健康度低，统计信息不准，代价模型认为 tiflash 的代价更低。你可以 explain verbose 看下代价 2： 你要不是事别名改为表名。或者 session 级别 set 下 engine 为 tidb,tiflash 看看能不能干扰走。报错感觉不应该。

目前 RU 只会考虑存储层面的资源，中长期来看可能也不会考虑 tidb-server 这一层。 是因为TiDB 内的资源限制存在一些技术挑战，在 TiDB bound 的场景下还没法很好的控制。 中期看，主要利用 独占TiDB+弹性 在 next-gen 上隔离 TiDB bound 的场景