update 一直没执行过成功，应用程序超时终止了，无法通过历史执行计划来创建binding 根据SQL创建强制索引bind没生效，最后还是收集表索引统计信息完后才走索引正常 mysql> ANALYZE TABLE xxxx_data INDEX idx_standard_xxxx; Query OK, 0 rows affected (4 hours 16 min 57.41 sec)

并发是早上已经增大4倍多到18了 mysql> show global variables like '%tidb_build_stats_concurrency%'; +------------------------------+-------+ | Variable_name |…

目前问题已解决，关掉计算节点执行计划缓存后，页面报表查询响应快，符合预期（走到了正确联合索引）

还真可能和plan cache有关，我验证下，之前另一套高TPS的TiDB集群计算节点内存一直涨，关闭执行计划缓存后内存就正常了

是的了

TiDB冷数据我们已经有用SAS机械盘的了，但机械盘可靠性不是很高，机械盘我们已经维护换盘过几次了，而且机械盘基本在自建idc才有，对象存储的可靠性，适配性更好

我之前打开tidb的general_log查过，没发现有set会话变量的设置（之前怀疑有，也可能tidb general_log没输出set会话变量语句）

是dashboard里慢SQL，我之前打开tidb的general_log看记录的和dashboard里一样

降低SSD tikv存储成本，如把冷数据存放在低成本的对象存储，未来，基于对象存储的数据库落地应该会比较多（降本增效的需求多 ）

写入量很大，推荐用批量写，我们有个业务写入量每天1亿多，开始性能跟不上，后面改造成批量写

我们生产CDC同步用的2.3版本kafka，没有使用鉴权，也没遇到这问题

没有最好数据库，只有最合适业务数据库；数据库也是为了支撑业务服务，有不同业务需求就会有不通类型数据库产生，祝愿国产数据库越来越好。

yyds

TiKV火焰图已上传 [mem]

已填写

生产环境白天流量高比较耗tidb节点内存+白天自动收集统计信息可能导致tidb节点OOM，之前生产出现过

一波未平，一波来袭:rofl: [image]

我要挑战