https://docs.pingcap.com/zh/tidb/stable/latency-breakdown#tikv-快照 这是获取快照的延迟拆解。你可以看看grafana里面拆解出来是哪里慢了。 粗略感觉可能是读热点，看看表结构。

这两个执行计划是一样的。时间差异这么大，确实奇怪。 这么看还不是执行计划差异导致的变慢。 令人费解。

这么看按月分也能满足要求，热数据保留2个月份分区就行了，其他都是冷数据。 正常的执行计划看着没问题。 不过我看你提到这个，也就是说当时其实是没有通过负载均衡，直连的单独一台的tidb？空region的问题在tikv，要慢应该是大家都慢，我现在感觉单纯就是当时这台tidb的cpu忙不过来了。换一台cpu没那么高的tidb自然就没问题了。

执行计划不一样，扫描的次数太多了。 能看看具体的执行计划是有什么差异吗？

新机器肯定是更好的。 你看看读取数据量，一个9.6m一个1.66g，大了快200倍了，只慢了14s。

看上去cpu确实不均匀，可问题是热点的region仍然不知道是那个。要找到热点的region里面是什么数据，才能知道是表热点还是索引热点。 建议你看看这个文章。 这个里面也写到cpu利用率不均匀，但这是热点的一种佐证，如果不能定位到底热点在那个region上是不好对症下药的。

我也感觉不确定是创建分区造成的。需要看看当时的慢查询执行计划。 tidb的数据会自动根据region分片，其实本来就是分开的，分区在tidb存在的理由主要是2个： 1，冷热分离的调度需要用到分区 2，删除数据方便 如果需求不是这两个，只是想让数据分片的话，不用分区/粒度不用那么细都行。 这块和mysql是不一样的。

这些region是索引热点还是表热点？ 我怀疑是索引热点。 因为索引的数据少，存储的region可能更集中。再每次都要读取索引的情况下，存储索引的特定几个region容易形成热点。 表的话，时间范围都不一样，为啥会集中读取几个region。这有点怪。

我也觉的是，他给的条件太苛刻了。 https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#开发及测试环境 比要求的开发测试环境的配置低很多。都不是腰斩，是膝盖斩了。

你首先要看看这时间是什么sql跑在上面。 再来看看那些是应该tiflash跑的，那些不应该。 这1个小时呢。如果确实就是这么多数据需要跑，那也可以考虑错峰啊。10点后基本就没人用了。这种情况你让老板打钱加硬件肯定搞不定的。

不行就 -u root -p root权限用密码连上去，先把事情做了再回来研究好了。

你这不是人为制造热点么。建议好好看看文档。 完全错误，你前面说回表压力只在少数region上，不就是说这些少数region就是被集中读取的吗？这就是热点啊。怎么后面还能避免这些region成为回表热点呢？ 你把你自己说的，再理解一下？

我记得好像是2000行以下不会自动analyze，不确定是否影响手动。你看看这些analyze之后还是显示为0的，是不是不足2000行。

https://stackoverflow.com/questions/35290962/hibernate-createcriteria-is-not-valid-without-active-transaction 自己看吧，需要 @Transactional 或者显示的开启事务。

既然是OOM了，你就弄个dump出来，看看这500MB里面是什么。我怀疑可能不是buff这类的，代码需要的内存就占了几百兆，你调的这些参数还没到上限就超过500MB了。 另外里面有几个参数现在还是实验特性，就比如 rocksdb.write-buffer-limit 不如去cf上调，另外这个writecf和defaultcf上，这个write-buffer的个数都是5个。 单独调cf上的block-cache和write buffer 我在4c8g调过是确实有用的。你给的太极限了，1g-3g。我是真觉得有点悬，起码要通过dump看看代码这块到底占了多少，才好估算。

这个前提是不存在的。region超过一定的大小（https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#region-max-size ）会自己分裂的。 建议再仔细看看文档。特别是下面这个部分。 https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#tidb-高并发写入场景最佳实践

https://python.langchain.com/docs/integrations/vectorstores/tidb_vector/ 文档都有了 # Here we useimport getpass import getpass import os if "OPENAI_API_KEY" not in os.environ: os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") # copy from tidb cloud console tidb_connection_string_te…

全局索引好顶赞。期待已久。

这个报错说在storeid =1的tikv上没有找到这个目录。 要使用pd-ctl看一下，storeid=1的这个tikv是那个，上去看一下。 tiup ctl:v{你的版本} pd store 返回的json里面有id=1的。看看地址和端口，ssh进去找一下是否存在你写的这个目录。