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进去找一下是否存在你写的这个目录。

s3和共享磁盘不是一回事。 当br使用s3的时候，不需要在tikv上创建什么东西。 但共享磁盘需要，在所有tikv上都有一个统一的共享磁盘挂载目录路径。

rawkv可以通过专门的客户端访问。除了go其他语言的也有。

感觉是bug。cdc的日志能提供一下吗？可能对修复会有些帮助。

原来如此，难怪tidb上看不到慢查询。 juicefs有卡顿的感觉吗？ 要是没感觉就算了。有感觉这个问题也很难查了。 看看其他大佬有没有办法。

https://docs.pingcap.com/zh/tidb/stable/tidb-functions#tidb_decode_key 这个函数也可以decode key

你可以这么理解，2pc执行事务是标准配置，1pc和异步提交属于优化。 这个报错就是说，因为某些原因不能使用1pc和异步提交，要退回2pc执行了。属于有些性能优化的手段没用上。不过整体又没有慢查询，我觉得这个错误可以忽略。 如果要往下查的话，要看看这个key属于那个表，到底是写什么表的时候有问题。 也许可以缩小一下排查的范围。 用这个工具decode一下key，也许能找到table id，就能定位到是在写那个表的时候出现的这个问题。

就是真喝西北风，也建议找个有仪式感的地方，比如山顶，量大管饱。 保证来年再也不想喝西北风了。

看着没啥问题。实际写入也不慢，也没有慢查询，就是报错，退回2pc执行事务。 查查ntp时间同步有问题嘛？

看看这个。prewrite的图表是什么情况？ 奇怪的地方在于你没有看到有insert的慢查询。这里我也没想通是为啥。

我碰到过一次，是升级的时候会额外建这个表，但因为时间太短（tiup 2分钟限制）没有建完。

这个需要你去apifox提个需求，让他们支持tls链接了。 从上面的文档上看，他们认可的安全链接方式是ssh隧道。根本就没有tls链接的介绍。

没啥问题吧，就是选择度太差。一共近500w数据有400w都符合你这个like条件，走索引回表400w次效果不是更差。

https://docs.pingcap.com/zh/tidb/stable/information-schema-columns#columns 查columns表。另外tidb或者ticdc的日志里面也有可能有报错的sql。

可以给一些官方人员明显的标志，比如说 xxx@pingcap，这种回答就很负责任，内容也很可靠。 这个建议特别好。

这其实是个开源和商业的问题。 如果要保证回答的时效性和准确性，这个应该是商业负责的内容，指望大家用爱好来做到这个程度也不是不可能，但确实非常困难。可以往这个方向上努力，但没法作为承诺。 就如同每个开源软件的协议内都会写清 [588766e49b47c9bb97e76c62be77d2bc] 这两个都属于开源的局限性。

已经在开始内部测试了，个人感觉就是生成的速度有点慢。准确性还是不错的。