tidb v6.5.0 引入的包有 bug，需要升级到 v6.5.1。 不过升级之后 host 的 IP 是对的，port 一直为 0。

现在只考虑了连接数，不支持配置权重。上面的规划里考虑了 CPU、内存等。你说的资源应该主要指 CPU？如果考虑 CPU 使用率的时候结合了 TiDB 实例的核数，应该也能满足你的需求。

Reactor 模型

可以用 bin/tiproxyctl，它会连 3080。tiproxyctl --help 可以看到支持的命令，例如 tiproxyctl config get 获取 config。 直接连 3080 的话，跟 tidb 的 10080 一样可以用 curl 127.0.0.1:3080/xxx 获取，常见的接口有： /api/admin/config/ 获取配置 /metrics 获取监控 /debug/pprof/xxx 获取 profile

TiDB Serverless 在开发了，但是线下和 TiDB Dedicated 版本没有计划。

tidb 代码里很多地方强依赖 tikv 和 pd，并没有很好地解耦，替换不现实。 之前 foundationdb 想过直接用 tidb 做上层的 SQL 引擎，后来放弃了：Use FoundationDB as an alternative of TiKV for TiDB · Issue #19111 · pingcap/tidb · GitHub

受教了，让 TiProxy 自己管理 VIP 确实更好。 不过我想调整一下，把 raft 选举改为在 PD 上的 etcd 选主，因为 TiDB 的正常运行都是依赖于 PD 的。在网络分区的情况下，etcd 选主总能选到和 PD leader 在同一个分区的 TiProxy，也就能路由到正常的 TiDB；而 raft 可能会路由到另一个分区，导致集群完全不可用。 另外我在想，也许让用户选择 primary 偏好，或者像 keepalived 一样配置权重能适应更多场景： 因为只有一台 primary 实例，它的硬件配置可能需要很高。用户为了省成本，可能想要 primary 32C，s…

参见官网的性能测试报告：https://docs.pingcap.com/zh/tidb/dev/tiproxy-performance-test

这个 PR 让它从 1 开始了：https://github.com/pingcap/TiProxy/pull/348 backend conn id 只能主动从 backend 查 select connection_id()，因为 tidb 在握手时发给客户端的 conn id 是被 truncate 过的。有 issue 了：https://github.com/pingcap/TiProxy/issues/310

开启 proxy-protocol 后用 select host from information_schema.processlist where id=connection_id();

可以通过 tiproxy 日志，有 [new connection] [connID=0] [client_addr=127.0.0.1:63187]，可以根据 client_addr 找客户端地址。 如果没有开启 proxy-protocol，也可以通过 show processlist 看 host，这里的 host 就是 tiproxy 地址，因为对 tidb 来说，tiproxy 就是客户端。 目前没有其他办法，有什么建议吗

statements_summary 最大保存条数 tidb_stmt_summary_max_stmt_count 指的是保留的所有 SQL 的种类，而不是单个时间段的种类。也就是说，可能由于新的 SQL 进来，把旧的 SQL 刷下去了。 可以查询 select count(distinct schema_name, digest, plan_digest) from information_schema.statements_summary_history where digest_text != ‘commit’; 先看看大体的种类。

5.0 开始有控制 fsync 频率的功能，之前的版本都是通过 batch 去平摊 fsync 的开销。从 4.0.7 开始将会移除 sync-log 配置。 还没有具体的资料，关于 batch 部分，有一篇介绍的文档 https://pingcap.com/blog-cn/tikv-source-code-reading-17/

你好，4.0 最新版本已优化过，sync-log 打开对性能的影响也不大。建议一直打开。

你好，不需要手动下载，是 gopath 配置问题。可以阅读 go 相关文档。

麻烦把所有节点的 slow log 和 tikv log 发上来，我仔细分析下，谢谢！

本地测试的特征能否描述一下？ 是否也是 TiKV 慢？该 SQL 的 process_time 是否长？ 最好也有 slow log 和 tikv log。

MAX_EXECUTION_TIME 分三种：hint，global 变量，session 变量。 设置 global 变量后，不重启 tidb 的情况下，对内部 sql 不生效。因为内部 sql 都是启动时开单独的 session 运行的，global 变量只对新开的 session 生效。 设置 global 变量后，重启 tidb 之后对所有 sql 都生效。 设置 session 变量后，对内部 sql 不生效，因为用户 session 里不会有内部 sql。 目前无法按用户维度设置。如果有对用户维度配置的需求，建议可以到 https://github.com/pingcap/…

14:19:06 有一条大查询，时间戳是 419152827524055063，有 13 次查 106 这个 tikv，每次读 96 万条数据，每次耗时 1s 以上。这导致了后面的 cop task 都等待。 我在你给的 tidb 的 slow log 里没有搜到这个时间戳，麻烦在 172.31.18.96 这台 tidb 里按时间戳 419152827524055063 搜一下 slow log，看看是哪条 SQL。