你这个应该是非聚簇表，这个索引后边要➕上主键列 F_SOURCE_SYSTEM, F_SERVICE_DATE, F_PROCESS_FLAG, 主键 上建立复合索引

看 gc_safe_point 的位置，前的就找不到了，后的就可以

尝试用下 flink 看能解决你的问题不

1.因为是活跃内存，算子执行过程中会用到的，所以不能释放 2.优化SQL 3.建议升级到最新LTS，新版本更强大

https://github.com/pingcap/tidb/issues/52592 point_get 在设计上不支持列裁剪，有时或许比 cop 更慢，titan 或许是一个好办法

点一个看一下，不看不知道

从执行计划来看，感觉这 SQL 写的烂，明明就一个查询一个表，查来查去的 你把完整的 SQL 和 explain analyze 结果发出来

太棒了，新版本发布都不用看官方文档，看他发的文章就好啦

想要这个 帮帮我 [image]

看你业务压力大小和重要程度了吧，估计业务压力很低，不然 16g 也扛不住

重建 drainer 就好了

执行如下 SQL 看下 show config where type='tikv' and name like '%log.%';

可以哦，使用逻辑导入模式就不用写，参考：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-logical-import-mode-usage

默认监控没带这个告警，我这边也没手动添加过 默认我记得 token 是 1500 吧，如果是 token 不够用了导致耗时长，我服务器 cpu 早就满了，所以也没加过这个监控

现在比较常用的功能 1、句子润色，错别字查找 2、写简单代码，shell 啥的 非常的好用，工作效率提升大大滴

你需要了解下隔离级别这个概念，TiDB 支持 RR （快照隔离）隔离级别，在快照隔离级别下 begin; -- 开启一个事务 select xxx; -- 接下来的几个查询，都是查询同一快照，所以数据不会变化 select xxx; commit; -- 最后 commit

版本快速迭代有利于产品的快速发展，发版速度变慢，新功能上的就慢了 看了下大家的建议，大多数是从运维去考虑的，认为追不上新版本，可是为什么要追新版本呢？ 如果是因为产品生命周期到了，那跟发版速度没啥关系了，你期望的是增加产品生命周期 如果是想用新功能，那应该期望版本快速迭代啊

这才十几 MB/s ，就这么点 IO，需要关注不均衡的问题吗

参考这里，盘一般是分开用，官方建议单块不要超过 4 T https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#生产环境 PD 一般部署 3 个，这个是分布式共识算法要求的最小数量，也是最常用的数量，具体根据你的高可用需求可以增加至 5、7 等基数个