一般有以下几种情况不推荐建立索引：

1）对于数据量很小的表

• 当表的数据量很小（如几百条记录）时，建立索引并不会显著提高查询性能，反而可能增加管理的复杂性；

2）频繁更新的表

• 对于频繁进行插入、更新和删除操作的表，索引会导致额外的维护开销，因为每次数据变更时都需要更新索引，这会影响性能；

3）执行大量的 SELECT

• 此时二级索引可能不会显著提升性能，因为需要大量的回表查询，开销大，数据库最终可能会选择走全表扫描；

4）低选择性字段（高度重复值的列）

• 当索引字段的取值重复度高（如性别字段“男”、“女”），索引的效果不明显，且会增加存储空间的浪费；
• 但是，还有一种场景可以考虑，比如表里任务 status 列就 2 个类型，90 % 都是 1（已完成），10%（待执行） 是 2，这个场景会频繁查询 2（待执行）的任务来执行，此时可以建立索引，毕竟能过滤 90 % 的数据；

5）低频查询的列

• 对于查询频率极低的字段，建立索引的成本和维护负担可能超过带来的性能提升；

6）长文本字段（非常长的 varchar 或 JSON、BLOB 和 TEXT 类型，这些类型的列通常包含大量数据）

• 数据量大排序时都无法用内存排，只能利用磁盘文件，排序很慢；
• 数据量大，每个页能存放的行数就少，扫描查询可能会涉及大量的 I/O；
• 文本字段过大都需要额外 blob 页存储，每次查询还需要查额外的页，也是随机 I/O 效率低；
• 这种类型的数据如果有查询需求，不应该放到 MySQL 中，可以需要采用 es 等组件来实现查询。