假设我有一个大小不错的MySQL表(我们称之为departments(，其中包含一堆像这样聚集在一起的列：
部门表：
| id | ds_settings | ds_reports | sales_settings | sales_reports | eng_settings | eng_reports | ops_settings | ops_reports | queryable_id | queryable_type |
|----|-------------|------------|----------------|---------------|--------------|-------------|--------------|-------------|--------------|----------------|
设置"，我们有"报告"。查询此表时，它通常只查找给定"可查询"ID 和类型的所有设置或报告。
因此，对此表的大多数查询最终将如下所示：
SELECT ds_settings, sales_settings, eng_settings, ops_settings
FROM departments
where queryable_id = 1
AND queryable_type = "User"
为什么问题是，索引此表的正确方法是什么？包含包含所有"设置"和所有"报告"的索引是否具有设计意义，例如：
UNIQUE KEY `index_on_settings` (`queryable_id`,`queryable_type`,
`ds_settings`,`sales_settings`,`eng_settings`)
。还是误解了复合索引应该如何工作？
在考虑键时，应按顺序使用以下元素作为索引。用于以下字段：
- 加入
- 其中(常量字段(
- 其中(范围字段(
- 排序
- 分组依据
在这种情况下，您按常量查找值搜索两个字段，因此请保留这些字段作为索引。没有必要强加独特的约束。
虽然您可以在索引中包含检索到的字段，但它的缺点是会增加索引中条目的大小并使搜索索引的速度变慢。如果您在一个非常常见的查询中有一个小字段，那么这可能是值得的，但是如果您的情况似乎还为时过早。
所以：
ALTER TABLE departments ADD KEY index_on_settings (queryable_id, queryable_type)
我假设id是主键。
建议通读 https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html。这里还有一个关于索引使用 https://github.com/jynus/query-optimization 的很好的介绍。
回答你的问题的两点：
索引应基于WHERE子句中的属性构建，- 而不是基于
SELECT子句中的属性构建。 - 您应该在所需的最小属性上构建索引，因为如果包含的属性多于需要的属性，则插入和更新也必须更新索引，从而导致它们变慢。