varchar类型字段业务需要设计长度16,384，如果使用此字段作为索引查询，性能下降多少

[TiDBer_ELe3cM5P]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】varchar类型字段业务需要设计长度16,384，如果使用此字段作为索引查询，性能下降多少
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

[Miracle]

我的理解是没有影响的
存储的空间是根据实际的字符来的，跟设计长度没有直接关系。不会长度16384存100个字符就比长度1000存100个字符占用空间大了。

[啦啦啦啦啦]

别用了，这肯定不行，这么大字段varchar建都建不出来吧，更别说直接建索引了，不如用text，不过tidb也是不支持全文索引的，考虑考虑es呢。

[cassblanca]

此类长尾词个人建议 用全文检索 比如ES会比较好 分词太多索引维护恐怕效率难以接受

[哈喽沃德]

索引本身没啥影响，主要你取数据费劲。

[TiDBer_ELe3cM5P]

4096呢，现在主要是超过了InnoDB 存储引擎允许的最大索引长度，不让建

[Kongdom]

关键实际存储长度是多少，如果实际存储长度就是这么长，那感觉加索引没什么意义，后期大概率都是like语句，也不会走索引。

[zhaokede]

这个很难有量化的分析

[舞动梦灵 (Ti D Ber Nckmz Hmh)]

关键是看实际上存放的数据长度，如果里面放的是很长的字符串，那建索引性能并不会得到提高。