索引占用磁盘空间过大，并且严重影响性能

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】

在一个五十亿的表中添加一个复合索引（datetime + uuid string）和 普通索引（uuid string），占用将近1TB空间，同时在某个时刻插入突然从400ms 涨到4s，我是使用的batch insert 批量插入。

2

索引1T，表🉐多大？是还有很多其他索引吧？

3

建索引时候最好没有大数据量写入

5

索引的优点就是查询快，缺点就是占空间并且影响高并发插入修改

6

是这张表加索引整个加起来1t吗？光索引不可能这么大的，大规模数据插入到后面肯定是越来越慢的

7

datetime=8字节
uuid=36字符*4字节 (utf8mb4)=144字节

50亿索引=5,000,000,000*152=760,000,000,000大致760g，你还弄了2条，1T存储没问题。

问题在于uuid string存储。
https://docs.pingcap.com/zh/tidb/stable/uuid#uuid-最佳实践
最佳实践就建议你使用BINARY(16)而不是string.

甚至你在b站上，搜索一下uuid+mysql。应该有一大堆面试宝典告诉你，不要在mysql中使用uuid主键。

而mysql8中添加的 BIN_TO_UUID() 和 UUID_TO_BIN()这两个函数应该就是从某种程度上解决这个问题。

1 个赞
8

dashboard里看下慢SQL 时间消耗在哪

9

这个数据量太庞大了

10

说的应该是数据+索引 一共1T吧。
大量并发 灌数据，索引是需要不停的维护的，所以，数据量越大，就灌入越慢。
要不就先把索引删除了，数据灌好后在建立。

11

删索引之前3T 之后 2T

12

commit log duration 涨到 600ms

13

得看tikv 网络、磁盘IO性能

1 个赞