Mysql MariaDB-索引未提高字符（255）字段的性能

我试图在一个只有一百万条记录的表上执行这个SQL查询：

SELECT * FROM enty_score limit 100;

它让我在大约600毫秒内得到结果

在字段

`dim\u agg\u strategy`char（255）DEFAULT NULL

上添加where子句后，需要40秒执行：

SELECT * FROM enty_score WHERE dim_agg_strategy='COMPOSITE_AVERAGE_LAKE' limit 100;

我已尝试创建索引，但没有任何改进—执行同一查询仍需要40秒：

ALTER TABLE `enty_score` ADD INDEX `dim_agg_strategy_index` (`dim_agg_strategy`);

SELECT INDEX_NAME, COLUMN_NAME, CARDINALITY, NULLABLE, INDEX_TYPE 
FROM information_schema.statistics where INDEX_NAME = 'dim_agg_strategy_index';


INDEX_NAME            |COLUMN_NAME     |CARDINALITY|NULLABLE|INDEX_TYPE|
----------------------+----------------+-----------+--------+----------+
dim_agg_strategy_index|dim_agg_strategy|        586|YES     |BTREE     |

还有一点信息，我放在where子句中的这一列只包含6个不同的值：

select distinct dim_agg_strategy from enty_score;

dim_agg_strategy         |
-------------------------+
COMPOSITE_AVERAGE        |
COMPOSITE_AVERAGE_ALL    |
COMPOSITE_AVERAGE_LAKE   |
COMPOSITE_AVERAGE_NONLAKE|
NORMALISED_AVERAGE       |
SIMPLE_AVERAGE           |

---

优化器注意到该索引列几乎没有不同的值。所以它意识到需要很多行。因此，它决定简单地浏览表格，而不必为索引操心。（使用索引需要在索引的BTree和数据的BTree之间来回跳跃很多次。）

因此，您可以指出

限制100

来进行反击。这是一个正确的问题。唉，这指出了优化器中的一个缺陷

它在两者之间摇摆不定

• 忽略索引，如果需要扫描整个表，则索引可能是最佳的。注意：如果所需的100行恰好位于表的末尾，则会发生这种情况
• 使用索引，但要支付额外的开销。在这里，它没有意识到100远低于100万，因此提高了指数通常是最佳方法的可能性

让我们试着愚弄它。。。删除该索引并添加另一个索引。这次放两列：

 (dim_agg_strategy, xx)

其中，

xx

是另一列

（如果此技巧对您有效，请告诉我。）