从报错信息看是NEXT_GLOBAL_ROW_ID这个的字段值“12844501496393138768”超过了int64最大值，把字段类型改成无符号的bigint试试

tidb: performance.txn-entry-size-limit: 12582912 tikv: raftstore.raft-entry-max-size: '16MB' 这样调一下试试，reload tidb和tikv节点。

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。

用 PingCAP MetricsTool提供一下详细的tikv监控数据吧

你需要这篇文章：

我觉着在tikv中实现不了你说的这种操作，要不然全乱套了。

我觉得用Cursor Fetch去流式读取的时候结果集是已经全部在tidb server中了的，并不是说他能改变你的SQL实现limit offset那种效果。 所以解决办法就是上面kongdom说的，要么优化SQL，要么提高mem quota的阈值

max-thread-count可以调大点，你这扫描数据扫的太厉害了

有少量cancel一直都存在，数量在10以下，这种我感觉是正常的吧

都是正常的

是的，可以参考tiup cluster详细说明： https://docs.pingcap.com/zh/tidb/dev/tiup-component-cluster

tiup cluster display的输出信息里，Prometheus的data dir就是监控数据目录

reload会把中控机上的配置发送到各节点，restart不会。

配置文件参数都会持久化的。 如果你改的是监控节点上的Prometheus.yaml那么reload时候会被覆盖，tiup会把.tiup目录下的配置文件复制过去

是指哪些参数

查这个有啥需求嘛

你要是数据量小，并且一次性迁移，用最简单的办法。 1、mysqldump导出sql文件 2、mysql客户端加载sql文件到tidb 大数据量推荐用dumpling+lightning（一次性全量迁移）。 增量同步推荐用DM。

有一说一，TiDB很容易OOM这点确实不太扛造，真血泪史。

以toml为准，比如用pd-ctl修改参数的时候是不加引号的： config set enable-cross-table-merge false json展示的样式我猜测是和go struct字段类型定义有关，没有严格和toml的一致，能看懂就行。