【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】看官方课程，数据都是存储在rocksdb中的，索引数据在rocksdb是怎么存储的呢
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
索引最后也是变成了key-value的形式存储在rocksdb中，和普通数据并无差别，不会新建列簇。
https://docs.pingcap.com/zh/tidb/stable/tidb-computing#索引数据和-key-value-的映射关系
1 个赞
(Key, Value) 键值
key values也是跟行数据一样
和普通数据存储一样
都是key+value结构，你表里的数据一般是key+所有列，而索引里面是key+索引列
和数据存储原理一样
是正常的数据存储，视频课中由讲解，(Key, Value) 键值，B树等
kv结构存储的
理解为和数据一样就行
索引和数据都一样的kv存储
索引数据的KV映射
对于普通索引，在MySQL中是有非聚集索引概念的，尤其innodb中，通过B+Tree形式，子节点记录主键信息，再通过回表方式得到结果数据。
在Tidb中是支持创建索引的，那么索引信息如何存储？ 它同时支持主键和二级索引（包括唯一索引和非唯一索引），且与表数据映射方式类似。
设计如下：
Tidb为表中每个索引，分配了一个索引ID，用IndexID表示。
对于主键和唯一索引，需要根据键值快速定位到RowID，这个会存储到value中
因此生成的key-value键值对为：
Key：tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue
Value: RowID
由于设计的key中存在indexedColumnsValue，也就是查询的字段值，因此可以直接命中或模糊检索到。再通过value中的RowID，去表数据映射中，检索到RowID对应的行记录。
对于普通索引，一个键值可能对应多行，需要根据键值范围查询对应的RowID。
Key: tablePrefix{TableID}_indexPrefixSep{IndexID}indexedColumnsValue{RowID}
Value: null
根据字段值，可以检索到具有相关性的key的列表，在根据key中包含的RowID，再拿到行记录。
key values，和数据表一样
可以通过show table table_name index index_index_name regions; 查看region 的分布情况。 有主键 、唯一索引和二级索引的 key value 的表现形式是有差别。
索引在rocksdb中也是以key-value形式存放
nbkls
和数据存储原理一样