Question

我在2个表上有匹配的Btree索引，但解释计划说引擎正在对其中一个表进行全面扫描，而且速度非常慢。部署时，两者都以〜750,000行开始，关系是em_localitems：em_submenuitemassoc =＆gt; 1：N。我的理解是下面的**指数应该在下面的查询中运行良好，因为它们是从左到右使用的。

CREATE TABLE IF NOT EXISTS em_localitems (
  localitemid int(11) NOT NULL AUTO_INCREMENT,
  profitcenterid int(11) DEFAULT NULL,
  productid int(11) DEFAULT NULL,
  PRIMARY KEY (localitemid),
  UNIQUE KEY locationid (profitcenterid,productid),
  **KEY productid_2 (productid,profitcenterid)**
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 ;


CREATE TABLE IF NOT EXISTS em_submenuitemassoc (
  submenuitemassocid int(11) NOT NULL AUTO_INCREMENT,
  productid int(11) NOT NULL,
  profitcenterid int(11) NOT NULL DEFAULT '0',
  submenuid int(11) NOT NULL,
  enddate datetime DEFAULT NULL,
  PRIMARY KEY (submenuitemassocid),
  UNIQUE KEY productid (productid,profitcenterid,submenuid),
  **KEY productid_3 (productid,profitcenterid,submenuid)**
) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

这是查询：

SELECT * from
em_submenuitemassoc sm
LEFT outer JOIN em_localitems li2 on li2.productid=sm.productid
  and li2.profitcenterid=sm.profitcenterid
  and sm.profitcenterid is not null

我也试过索引提示：

SELECT * from
em_submenuitemassoc sm **use index(productid_3)**
LEFT outer JOIN em_localitems li2 on li2.productid=sm.productid
  and li2.profitcenterid=sm.profitcenterid
  and sm.profitcenterid is not null

“显示来自em_submenuitemassoc的索引;”返回：

+---------------------+------------+----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table               | Non_unique | Key_name       | Seq_in_index | Column_name        | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+---------------------+------------+----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| em_submenuitemassoc |          1 | productid_3    |            1 | productid          | A         |        1136 |     NULL | NULL   |      | BTREE      |         | 
| em_submenuitemassoc |          1 | productid_3    |            2 | profitcenterid     | A         |        1136 |     NULL | NULL   |      | BTREE      |         | 
| em_submenuitemassoc |          1 | productid_3    |            3 | submenuid          | A         |        1136 |     NULL | NULL   |      | BTREE      |         | 
+---------------------+------------+----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+

这是解释计划：

+----+-------------+-------+------+------------------------+-------------+---------+--------------------------------------------------+------+-------+
| id | select_type | table | type | possible_keys          | key         | key_len | ref                                              | rows | Extra |
+----+-------------+-------+------+------------------------+-------------+---------+--------------------------------------------------+------+-------+
|  1 | SIMPLE      | sm    | ALL  | NULL                   | NULL        | NULL    | NULL                                             | 1136 |       | 
|  1 | SIMPLE      | li2   | ref  | locationid,productid_2 | productid_2 | 10      | datatest.sm.profitcenterid,datatest.sm.productid |    1 |       | 
+----+-------------+-------+------+------------------------+-------------+---------+--------------------------------------------------+------+-------+

这有什么可怕的错误？

Answer 1

查看表格 sm 的查询附件type是否为“全部”。无论连接条件如何，优化器都知道它必须读取 sm 的所有行。

这可能是因为您正在使用LEFT OUTER JOIN返回所有连接中左表的行，而不管连接的右表中是否存在匹配的行

您还在使用SELECT *，因此无论如何都必须获取 sm 的所有列。如果查询只需要索引中的列，则可以跳过读取基表。

因此，使用索引在此查询中没有任何好处，并且MySQL通过跳过阅读索引来获得更高的效率。

MySql查询不使用复合索引

1 个答案: