当前位置：文江博客话题详情

MySQL解释中eq_ref和ref类型是什么意思

发布于 2024-10-08 11:12:27 字数 119 浏览 1 评论 0原文

当我们在 SQL 查询中添加关键字“explain”作为前缀时，我们会得到一个包含一些列的表。请告诉我“类型”栏是什么。在这种情况下，eq_ref 和 ref 意味着什么。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不回头走下去 2024-10-15 11:12:27

我将尝试解释...

eq_ref – 假设您有两个表。表 A 包含列（id、text），其中 id 是主键。表 B 具有相同的列（id、text），其中 id 是主键。表 A 具有以下数据：

1, Hello 
2, How are

表 B 具有以下数据：

1, world!
2, you?

想象 eq_ref 作为 A 和 B 之间的 JOIN：

select A.text, B.text where A.ID = B.ID

此 JOIN 非常快，因为对于表 A 中扫描的每一行，表 A 中只能有 ONE 行表 B 满足 JOIN 条件。一且不超过一。那是因为 B.id 是唯一的。
这里是：伪代码，它说明了服务器端的处理：

foreach (rowA in A)
{
    if (existsInBRowWithID(rowA.id)
    {
        addToResult(rowA.text, getRowInBWithID(rowA.id).text);
    }
}

ref - 现在想象另一个带有列（id，text）的表 C，其中 id 是索引，但不是独一无二的。表 C 具有以下数据：

1, John!
1, Jack!

将 ref 想象为 A 和 C 之间的 JOIN：

select A.text, C.text where A.ID = C.ID

这里是：说明服务器端处理的伪代码：

foreach (rowA in A)
{
    foreach (rowC in C)
    {
        if (rowA.id == rowC.id)
        {
            addToResult(rowA.text, rowC.text);
        }
    }
}

此 JOIN 不如前一个快，因为对于表 A 中扫描的每一行，都有SEVERAL 行可能满足 JOIN 条件（嵌套循环）。这是因为 C.ID 不是唯一的。

I'll try an explanation...

eq_ref – imagine that you have two tables. Table A with columns (id, text) where id is a primary key. Table B with the same columns (id, text) where id is a primary key. Table A has the following data:

1, Hello 
2, How are

Table B has the following data:

1, world!
2, you?

Imagine eq_ref as JOIN between A and B:

select A.text, B.text where A.ID = B.ID

This JOIN is very fast because for each row scanned in table A there can be only ONE row in table B which satisfies the JOIN condition. One and no more than one. That is because B.id is UNIQUE.
Here you are: pseudo code which illustrates the processing at server side:

foreach (rowA in A)
{
    if (existsInBRowWithID(rowA.id)
    {
        addToResult(rowA.text, getRowInBWithID(rowA.id).text);
    }
}

ref - Now imagine another table C with columns (id, text) in which id an index but a non UNIQUE one. Table C has the following data:

1, John!
1, Jack!

Imagine ref as JOIN between A and C:

select A.text, C.text where A.ID = C.ID

Here you are: pseudo code illustrating the server side processing:

foreach (rowA in A)
{
    foreach (rowC in C)
    {
        if (rowA.id == rowC.id)
        {
            addToResult(rowA.text, rowC.text);
        }
    }
}

This JOIN is NOT as fast as the former one because for each row scanned in table A there are SEVERAL possible rows in table C which may satisfy the JOIN condition (nested loops). That is because C.ID is NOT UNIQUE.

回复收藏 0 原文