两个索引上的mysql连接需要很长时间！

大家好
我在dripal中有一个自定义查询，该查询是：

select count(distinct B.src) 
from node A, url_alias B 
where concat('node/',A.nid)= B.src;

现在，节点中的nid是主键，我已经将src作为url\u别名表中的索引。 等了一分钟多后，我发现：

+-----------------------+  
| count(distinct B.src) |  
+-----------------------+  
|                325715 |  
+-----------------------+  
1 row in set (1 min 24.37 sec)  

通过勾选“解释”，我得到了：

******************* 1. row ***************************  
           id: 1  
  select_type: SIMPLE  
        table: A  
         type: index  
possible_keys: NULL  
          key: PRIMARY  
      key_len: 4  
          ref: NULL  
         rows: 325716  
        Extra: Using index  
*************************** 2. row ***************************  
           id: 1  
  select_type: SIMPLE  
        table: B  
         type: ALL  
possible_keys: src_language_pid,src  
          key: NULL  
      key_len: NULL  
          ref: NULL  
         rows: 325928  
        Extra: Range checked for each record (index map: 0xC)  
2 rows in set (0.00 sec)  

现在我的问题是：为什么这个查询没有使用src的索引，以及如何优化它

---

感谢您的帮助

性能问题与使用concat有关 如果nid是一个整数，这将导致大量的工作

我认为您必须在url\u别名中添加索引nid列

不幸的是，您的表将不再规范化。

1）对此查询进行解释，然后使用explain SLECT count启动它

2） 尝试将您的连接条件（位置）移动为连接：

 select count(distinct B.src) from node A inner join url_alias B ON concat('node/',A.nid)=B.src

3） 为了加快速度，索引对象应该是节点表中的“concat（'node/'，nid）”。在这里，必须为每一行节点推荐这一点。根据您的MySQL版本，您可能无法使用表达式（仅列）构建索引。因此，您可以有一个专门存储“concat（'node/'，nid）”的列，您可以将其称为node_nid并对其进行索引。并检查您是否尚未获得它

COUNT（DISTINCT something）

对于非平凡查询，如果计数表达式上不存在唯一索引，则在运行查询时强制查询在其上构建唯一索引

这本身就是缓慢的，在大多数情况下：

• 不必要-解决方案：重写查询以便不需要distinct

• 如果确实需要使用unique，那么通常将查询一分为二会更快，一个查询将获得有用的查询结果，该查询将创建重复的

  B.src

  ，另一个查询将不需要distinct

---

最后，学习如何使用，这样您就可以开始学习如何执行查询以及如何优化查询。

您在联接条件中使用函数（实际上在您的情况下是WHERE子句，但在运行查询之前会被重写为联接），这意味着查询不能为此联接使用任何索引。