如何加快这个SQL索引查询？

Question

给定以下SQL表：

员工（ ssn ，姓名，部门，经理，薪水）

您发现以下查询明显慢于预期。 有一个关于salary的索引，您已经验证了查询计划正在使用它。

SELECT * 
FROM Employee
WHERE salary = 48000

请说明此查询比预期慢的可能原因，并提供解决该原因的调优解决方案。

我有两个想法，为什么这个查询比预期慢。 一个是我们尝试SELECT *而不是SELECT Employee.salary ，这会减慢查询速度，因为我们必须搜索所有列而不是一列。 另一个想法是salary指数是非集群的 ，我们想要使用聚集索引，因为公司可能非常庞大，并且通过salary字段组织表是有意义的。

这两个解决方案中的任何一个都会加速这个查询吗 即将SELECT *更改为SELECT Employee.salary或显式设置要聚集的salary的索引？

Answer 1

你现在有什么指数？

它真的“慢”吗？ 你有什么证据？

评论“SELECT *而不是SELECT Employee.salary” -

• *是不好的形式，因为明天您可能会添加一列，从而破坏任何期望按特定顺序排列一定数量的列的代码。
• 在找到行之后才会处理*与salary的比较。
• 找到行是昂贵的部分。
• 另一方面，如果您有INDEX(salary)并且仅查看salary则索引是“覆盖”。 这意味着不需要获取“数据”（其他列）。 因此，更快。 但这可能超出了老师告诉你的内容。

评论“工资指数是非集群的，我们想要使用聚集索引” -

• 在MySQL（不一定在其他RDBMS中），InnoDB只有一个PRIMARY KEY ，它总是UNIQUE和“集群”。
• 也就是说，“聚集”意味着“独特”，这似乎不适合“薪水”。
• 在InnoDB中，“二级密钥”隐含地包括PK（ ssn ？）的列，它可以用来到达数据中。

“验证了查询计划” - 您是否了解了EXPLAIN SELECT ... ？

有关为给定SELECT创建最佳索引的更多提示 。

Answer 2

我会尽量简单，

你不能简单地将薪水作为聚集指数，除非你把它作为一个独特的或主要的，既有愚蠢又无意义，因为两个人可以有相同的薪水。

根据MYSQL文档，每个表只能有一个聚簇索引。 默认情况下，数据库选择主键作为聚簇索引。

如果没有为表定义PRIMARY KEY，MySQL会找到第一个UNIQUE索引，其中所有键列都是NOT NULL，而InnoDB将它用作聚簇索引。

为了加快您的查询，我有一些建议 ，去二级索引，

如果你想通过直接值搜索薪水，那么基于哈希的索引是一个更好的选择，如果MYSQL已经支持了。

如果要使用大于，小于或某个范围搜索值，则B树索引是更好的选择。

第一个选项比第二个选项更快，但仅限于相等运算符。

希望能帮助到你。