基于 WHERE 子句的 SELECT 查询的性能答案

【问题标题】：Performance of SELECT Query based on WHERE clause基于 WHERE 子句的 SELECT 查询的性能
【发布时间】：2020-06-03 04:38:21
【问题描述】：

我在 session 表中有一些数据，其中包含 用户位置 以及与用户相关的一些其他数据

会话表由多个列组成，例如

id - PRIMARY KEY AUTO-INCREMENT
session_id - UNIQUE KEY（每次都是唯一的，即使用户多次登录，也会生成UNIQUE）
user_id（此用户 ID 对每个用户都是唯一的）
user_location（保存用户的坐标）

问题说明

我想知道以下两个查询之间是否存在性能差异。

第一个查询

SELECT user_location FROM session WHERE session_id = 'some-session-id-goes-here';

第二次查询

SELECT user_location FROM session WHERE session_id = 'some-session-id-goes-here' AND user_id ='usome-user-id';

这两个查询都提供了正确的数据，但如果假设此会话表中存在数百万个数据，是否会对性能产生任何影响。

在 smaller 的 data < 4000 集合上运行两个查询not 并没有给 fetching time 带来任何差异。

【问题讨论】：

由于 user-id 不是键并且 session-id 是唯一键，这两个查询不会有任何性能差异。您也可以使用explain 进行检查
@ruhul 好的，我会试试这个。
如果 session_id 是主键（假设它也不为空）而不是唯一键，那么性能将是相同的，并且可能比当前的两个查询更好。需要id 吗？
session_id 不是 NULL，每次都会有一些 UNIQUE 值。你能说出在 SELECT 操作中PRIMARY KEY 会比UNIQUE 更好吗？ @danblack 和id 不需要太多，只是为了正常的自动增量
如果在另一个表中引用了id，或者您编写了代码，则可能不需要它。 AI 确实可以很容易地在表的末尾插入，而不是在添加非顺序 PK 时重新平衡。这个doc 有一点关于主键和辅助键。基本上，辅助键以主键 id 隐式结束，通过辅助键获取需要返回主（集群）键以检索不在索引中的字段，如 user_location。以session_id 作为PK，它已经找到了。但是可能会增加插入惩罚。

标签： mysql

【解决方案1】：

通常，当您使用UNIQUE Key 声明列时，默认情况下它会被索引。正如你没有提到你的user_id 是否被声明为unique（你说user_id 是唯一的，我假设它的值在你的create table 脚本中没有定义）。因此，从这个意义上说，它们将提供相同的性能。但是，如果您也索引您的user_id，那么情况可能会有所不同。当您有多个列索引并使用它们进行查询时，您必须在where 子句之后维护它们的index-sequence，并且您的查询性能将优于当前的查询性能。否则，不保持序列顺序的效果将是负面的。您可以通过

show index from your_table_name

查看列索引顺序

如需了解更多信息，请点击此处MySQL: unique field needs to be an index?

【讨论】：

user_id 在此 session 表中不是 UNIQUE，但在称为 users 的其他表中是 UNIQUE。我不认为这对这张桌子很重要session。
你是对的，没关系，因为你没有为这个表声明它。
所以在目前的场景下，我写的两个查询不会有太大的区别。也有任何机会让这个获取更快或者这是最佳解决方案？
我想是的。现在，除了索引列之外，我看不到任何更好的解决方案。