是不是开了TLS

TiFlash中没有特意看过，tikv中倒是有这个文件，作用如下： [image] 如果TiFlash也有的话作用应该类似吧。

tikv实例总共有多少核？ replace既要查询又要写入cpu使用高是预期内的。

你是想单条SQL分到多个tidb-server上去执行对吧，这种搞不了，tidb-server是无状态的。 看你是什么样的聚合运算，有部分能下推到tikv执行的话就稍微好点。

图中的那些更多体现是源码结构里的package，组件设计的思想，并不是一个个独立的进程，他们都包含在tidb-server这个进程中

每个页面都有这个下载入口，点击就是下载整个文档 [image]

你应该是想找这个 https://docs.pingcap.com/zh/tidb/stable/sql-statement-trace#trace

索引最后也是变成了key-value的形式存储在rocksdb中，和普通数据并无差别，不会新建列簇。 https://docs.pingcap.com/zh/tidb/stable/tidb-computing#索引数据和-key-value-的映射关系

TPC-C Benchmark 规定了数据库的初始状态，其中 ITEM 表中包含固定的 10 万种商品，而仓库的数量可根据测试规模进行调整，假设 WAREHOUSE 表中有 W 条记录，那么： STOCK 表中应有 W×10 万条记录（每个仓库对应 10 万种商品的库存数据）。 DISTRICT 表中应有 W×10 条记录（每个仓库为 10 个地区提供服务）。 CUSTOMER 表中应有 W×10×3000 条记录（每个地区有 3000 个客户）。 HISTORY 表中应有 W×10×3000 条记录（每个客户一条交易历史）。 ORDER 表中应有 W×10×3000 条记录（每个地区 3…

蒋总666

冲鸭！

问题已解决，最终定位原因是该表在频繁大批量写入和删除背景下导致MVCC版本堆积无法被gc，加索引时扫描key非常慢。 处理方式：关闭gc filter in compaction特性，约4小时左右rocksdb中的无效key（3亿+）全部清除完毕，加索引恢复正常。 备选方案：手动对该表做compact（未验证，理论可行） 相似问题：

加索引的时候没有元数据锁、也没有其他长事务占用

全部重启过了没有作用

没有跑lightning，那个lightning的日志应该是fast ddl的

表只有1千多行，跑了几个小时了

tidb server的源码里本身mock了一个存储引擎，我猜应该是可以对接其他存储的但是炒鸡复杂，没看到有这样的文档，只能靠啃代码了

索引可观测性和general log拆分有点意思

不支持。 升级到7.1或以上版本用资源管控就可以。