您可以拥有任意多个索引。但是，每个额外的索引在更新、插入或删除时都要付出代价。
1.找到共同的部分并为它们建立索引。
1.或者在查询太慢时根据需要创建它们。
例如，如果您“需要”ABCDE、ABDEF和ABGIH的索引，则仅在AB上创建索引

InnoDB支持每个表最多64个索引（参见https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html）。
如果你尝试为N列的每一个排列创建一个复合索引，你将需要N-阶乘索引。所以对于8列，你将需要40，320个索引。显然这超过了InnoDB所支持的。
你可能不需要那么多的索引。实际上，我很少看到一个给定的表中有6个以上的索引。所有需要的查询都被其中一个优化了。
我知道您说过，有时您会更改查询的WHERE子句中的项，因此可能需要具有不同列的复合索引。
你可以依赖于那些拥有所有列的子集的索引，这将是最优的，虽然不是100%的优化，但总比没有索引好。
在编写给定查询之前，您无法预测该查询的最佳索引集。

• 二级索引的数量限制为64个（至少在InnoDB中）。
• 对索引进行排序，以便使用=测试的列排在前面。（这些列在INDEX中的顺序无关紧要。）
• 索引中最左边的列是最重要的。
• 包含多个将按范围搜索的列几乎没有或现在没有用处。
• 研究您可能的查询，并找到2或3列的最常见组合;从这些开始建立索引。
• 在您的两个示例（ABCDEFGH和ABCEF）中，ABC对这两种情况都有效（假设至少A和B用=测试），如果您添加了更多列，那么一个INDEX仍然可以用于这两种情况。
• 也许你想知道ABCDEFGH和BCEFA的声明;这将处理ABCDEF案例，以及包含B但不包含A的案例。（记住“leftmost”。）
• 使用 SlowLog 查找最慢的查询并为它们创建更好的索引。
• 有关索引的详细信息：Index Cookbook

每个索引都需要磁盘上的存储空间，并且在每次更新（/insert/delete）索引列值时都需要更新时间。
因此，只要您没有耗尽存储空间或写操作太慢（因为您必须更新太多索引），就不会限制您创建所需数量的特定索引。
这取决于您的用例，并且应该使用类似生产的数据进行衡量。
一个常见的解决方案是为您最重要的查询创建一个特定的索引，例如在您的情况下ABCDE。
其他查询仍然可以从左到右使用相同数量的列，直到出现第一个差异。例如，搜索ABCEF的查询仍然可以在前面提到的索引上使用ABC。
要使用列E，您可以在查询中添加一个where条件到D，您知道它匹配所有值，例如，如果您知道只有值1-99，则D〈100。