会话缓慢分析如何做
刚遇到的问题。
当我用错误 SQL 查询
FROM t1
LEFT JOIN t2
ON t1.AREATYPE = t2.ID （正确方式是 t1.AREAID = t2.ID）
居然可以得到数据。
返回示例：
t1.AREATYPE 的 数据是 5，t2 是 5 开头的 32 位 uuid。
看你们的业务量，活跃用户数，以及活动高峰并发用户数，其实最重要的是看开发的技术含量，再牛的数据库，再牛的配置，一个烂sql也能整死。另外你们的业务是单纯的OLTP业务吗？如果还有OLAP的需求的话，可以上tiflash节点试试。oom的话，很多是因为OLAP业务造成的。
dashboard上找到对应的sql，先看慢在哪里
能提供最少复现脚本吗？理论上left join就是能返回数据啊？区别只在于返回t2表的数据了没
问题 按tiup部署 选择单台机器,多个实例 → [混合部署拓扑架构[简单混部配置模板]失败
环境 腾讯云单机2核4G 挂载了一个20G的云盘 操作系统ubuntu22
文档地址 https://docs.pingcap.com/zh/tidb/stable/production-deployment-using-tiup
1 云盘按照要求挂载为noatime nodelalloc
2 用新建的tidb账号 在/home/tidb目录 执行curl …命令
3 执行source .bash_profile 声明全局变量 发现没这个文件
使用source .profile命令暂时配置环境
4 https://github.com/pingcap/docs-cn/blob/master/config-templates/simple-multi-instance.yaml
根据[简单混部配置模板]配置topology.yaml
5 tiup cluster check ./topology.yaml --user root -p 检测失败
措施
1 修改所有ip为本机ip (10.0.4.9) 失败 显示Error: Failed to parse topology file ./topology.yaml (topology.parse_failed)
caused by: port conflict for ‘4000’ between ‘tidb_servers:10.0.4.9.port’ and ‘tidb_servers:10.0.4.9.port’
2 删除多个ip 只留一个的情况成功
1 个赞
3副本当1个副本down以后，2副本能正常提供服务，这个是设计的大前提吧。
但是当1副本down以后，严格来说这一个副本并没有任何问题，就是因为磁盘延迟特别高导致的副本apply比较慢，短时间内（1小时）可以继续提供服务，时间久了，其他2副本向这个副本通讯就有一场，channel full之类的日志一片一片的，然后其他2副本也就不能正常提供服务了，整个集群的tp99变大很多。
补充一下为什么磁盘延迟突然变大：
因为nvme盘有寿命，比如说2000次擦写，nvme盘有个寿命值，当寿命达到95%以上的时候，写盘会变慢，打到100%+以后就彻底不能写入了。
这种情况下，集群就会受到非常大的影响，store会被标记为is_busy=true，你们产研的同学可以自己测试下。
除了haproxy+keepalived外 有其他的高可用方案？
tidb 实际场景中olap用的多还是oltp用的多
你说的是 tidb server 前置的中间件吧？
也可以用 nginx, proxysql, tiproxy
目前我是使用keepalived作高可用服务、nginx作负载均衡。这样的话流量入口总是在keepalived vip指向的机器上。nginx负载均衡机器多的话，有点压力。
怎么针对慢SQL实现智能分析优化？
配置太低了
2套tidb集群用ticdc做异地灾备，账号怎么同步呢
领导让在tidb环境下做分库分表，这个怎么破局~
1 个赞
用tidb还分库分表的理由是啥
虚拟机环境，磁盘IO跟不上，又要做大数据分析。 主要是在长久的实践中，分库分表似乎已经成为了大数据优化的尽头~
是什么版本？ oom 的问题在 4.0.9 之前的版本会出现频率很高，在 6.5.0 后又做了一波大的优化，所以你可以看看是不是你的版本问题~
通过慢查询日志来分析会话缓慢的原因。TiDB 的慢查询日志记录了执行时间超过阈值的 SQL 语句，可以通过分析慢查询日志来找出执行时间较长的 SQL 语句，并进行优化。
以下是分析 TiDB 会话缓慢的步骤：
- 开启慢查询日志
在 TiDB 中，可以通过设置 session 变量 tidb_slow_query_file 来开启慢查询日志。例如，可以使用以下命令来开启慢查询日志：
set @@global.tidb_slow_query_file = '/path/to/slow_query.log';
set @@global.tidb_slow_query_threshold = 100;
其中，tidb_slow_query_file 指定慢查询日志的文件路径，tidb_slow_query_threshold 指定执行时间超过多少毫秒的 SQL 语句会被记录到慢查询日志中。
- 收集慢查询日志
在开启慢查询日志后，TiDB 会将执行时间超过阈值的 SQL 语句记录到慢查询日志中。可以使用 pt-query-digest 工具来分析慢查询日志。例如，可以使用以下命令来收集慢查询日志：
pt-query-digest /path/to/slow_query.log > slow_query_report.txt
该命令会将慢查询日志分析后生成一个报告文件 slow_query_report.txt。
- 分析慢查询报告
在生成慢查询报告后，可以通过分析报告来找出执行时间较长的 SQL 语句，并进行优化。慢查询报告中会列出执行时间最长的 SQL 语句，并给出执行时间、执行次数、平均执行时间等信息。可以根据这些信息来找出执行时间较长的 SQL 语句，并进行优化。
例如，可以通过添加索引、优化 SQL 语句、调整 TiDB 配置等方式来优化执行时间较长的 SQL 语句。优化后，可以再次收集慢查询日志并分析报告，以验证优化效果。