Question

再次问好Stackoverflow的人。根据类似问题的几个答案，我相信在我的表中添加索引将有助于下面的查询。挑战是，我不太熟悉或不习惯使用索引，因为如果使用太多索引，似乎有可能减慢其他查询的速度。只是找人来帮我引导我朝着正确的方向前进。提前感谢您的帮助。

查询：

SELECT
    territories.territoryID,
    territories.territory_name,
    territories_meta.tm_color,
    territories.territory_description,
    territories.territory_state,
    GROUP_CONCAT(distinct(territories_zips.tz_zip)SEPARATOR ', ' ) AS ZipCodes,
    count(distinct(users.userID)) as AgentsAssigned,
    GROUP_CONCAT(distinct(concat(users.user_Fname,' ',users.user_Lname))SEPARATOR ', ') 
         AS AgentName,
   a.sumTerr as TotalOpp
from(
   SELECT
       territories_zips.tz_terrID as terrID,
       sum(boundaries_meta.bm_opportunity) as sumTerr
   FROM territories_zips
   INNER JOIN boundaries ON boundaries.boundary_name = territories_zips.tz_zip
   INNER JOIN boundaries_meta ON boundaries.boundary_id = boundaries_meta.bm_boundariesID
   where tz_status = 1
   group by tz_terrID
)as a
inner join territories on territories.territoryID = a.terrId
INNER JOIN territories_zips ON territories.territoryID = territories_zips.tz_terrID
INNER JOIN territories_assign ON territories.territoryID = territories_assign.ta_territoryID
INNER JOIN users ON users.userID = territories_assign.ta_repID
INNER JOIN territories_meta ON territories_meta.tm_territoryID = territories.territoryID
WHERE
   territories_zips.tz_status = 1 AND
   territories_assign.ta_repStatus = 1 AND
   users.user_status = 1
GROUP BY territoryID

说明：

id  select_type table   typw    possible_keys   key key_len ref rows    extra
1   PRIMARY <derived2>  ALL                 97  Using temporary; Using filesort
1   PRIMARY territories_meta    ALL                 121 Using where; Using join buffer
1   PRIMARY territories_zips    ALL                 1739    Using where; Using join buffer
1   PRIMARY territories_assign  ALL                 138 Using where; Using join buffer
1   PRIMARY users   eq_ref  PRIMARY PRIMARY 8   msb_db.territories_assign.ta_repID  1   Using where
1   PRIMARY territories eq_ref  PRIMARY PRIMARY 8   msb_db.territories_meta.tm_territoryID  1   Using where
2   DERIVED territories_zips    ALL                 1739    Using where; Using temporary; Using filesort
2   DERIVED boundaries_meta ALL                 42995   Using join buffer
2   DERIVED boundaries  eq_ref  PRIMARY PRIMARY 4   msb_db.boundaries_meta.bm_boundariesID  1   Using where

我认为罪魁祸首是子查询的这一部分，因为与上面的整个查询相比，运行该部分只需要少2秒。

SELECT
   territories_zips.tz_terrID as terrID,
   sum(boundaries_meta.bm_opportunity) as sumTerr
FROM territories_zips
INNER JOIN boundaries ON boundaries.boundary_name = territories_zips.tz_zip
INNER JOIN boundaries_meta ON boundaries.boundary_id = boundaries_meta.bm_boundariesID
where tz_status = 1
group by tz_terrID

并且它解释了：

 id select_type table   typw    possible_keys   key key_len ref rows    extra
 1  SIMPLE  territories_zips    ALL                 1739    Using where; Using temporary; Using filesort
 1  SIMPLE  boundaries_meta ALL                 42995   Using join buffer
 1  SIMPLE  boundaries  eq_ref  PRIMARY PRIMARY 4   mb_db.boundaries_meta.bm_boundariesID   1   Using where

我已经为这个子查询包含了下面的表格，如果我需要重新发布其他表结构，请告诉我

表：

CREATE TABLE `boundaries` (
      `boundary_id` int(11) NOT NULL AUTO_INCREMENT,
  `boundary_name` varchar(20) DEFAULT NULL,
  `geometry_type` varchar(12) DEFAULT NULL,
  `boundary_geometry` mediumtext,
  `boundary_type` varchar(5) DEFAULT NULL,
  `boundary_state` varchar(4) DEFAULT NULL,
  PRIMARY KEY (`boundary_id`)
 ) ENGINE=MyISAM AUTO_INCREMENT=64504 DEFAULT CHARSET=utf8;

 CREATE TABLE `boundaries_meta` (
   `boundaries_metaID` bigint(20) NOT NULL AUTO_INCREMENT,
   `bm_boundariesID` bigint(20) NOT NULL,
   `bm_opportunity` int(5) NOT NULL,
  PRIMARY KEY (`boundaries_metaID`)
) ENGINE=MyISAM AUTO_INCREMENT=51201 DEFAULT CHARSET=utf8;


 CREATE TABLE `territories_zips` (
  `terr_zipsID` bigint(10) NOT NULL AUTO_INCREMENT,
 `tz_terrID` bigint(10) NOT NULL,
 `tz_zip` varchar(5) CHARACTER SET latin1 NOT NULL,
 `tz_status` smallint(1) NOT NULL,
 PRIMARY KEY (`terr_zipsID`)
) ENGINE=MyISAM AUTO_INCREMENT=2576 DEFAULT CHARSET=utf8;

再次感谢您的帮助。

编辑：我用索引更新了一些表并获得了令人难以置信的改进（再次感谢King Isaac）。我在子查询中包含了新的解释，因为我仍然不满意这有何以及为什么这有用，或者我是否真的在正确的部分创建了索引。给一个人一条他一天吃的鱼，教他如何钓鱼......

  id    select_type table   type    possible keys   key key_len ref    rows   extra
1   SIMPLE  territories_zips    ALL                 1739      Using where; Using temporary; Using filesort
1   SIMPLE  boundaries  ref PRIMARY,bndIDindex,bndNameindex bndNameindex    63  func    1   Using where
1   SIMPLE  boundaries_meta eq_ref  bmBndIDindex    bmBndIDindex    8   mb_db.boundaries.boundary_id    1   Using where

Answer 1

看起来您的第一步是处理tz_zip和boundary_name加入。我的第一个问题是：这些是独一无二的吗？对这些表应用UNIQUE索引应该可以显着加快子查询的速度。如果它们不是唯一的，那么标准索引仍然会为您提供足够高的基数来查看速度增加。

还应对所有表中的“状态”字段编制索引。尽管这些最终会成为低基数索引，但它会使查询受益，而不会导致很多索引开销。

您可能还想查看是否可以重构此查询以消除“from”子句中的子查询。这导致整个查询依赖于临时表，在查询过程可以继续之前必须完全建立该临时表。我会走出困境并说这也是你看到这么多'所有'类型的原因。查询分析器无法对数据的子集进行操作，因此它正在进行全表扫描。当它发生在一张桌子上时这很糟糕，在你的情况下它发生在五张桌子上。

我会将处理boundary_meta视为另一个连接并处理SELECT中的SUM(boundaries_meta.bm_opportunity)。它可能需要是一个依赖子查询，但你仍然应该看到性能的提高。

至于您对索引速度的担心：在向表中添加多个索引时，过度索引可能会成为一个问题，但除非您索引几个基于“char”的列，否则通常不会引起关注。由于我们只讨论两个varchar(5)列，因此不应该成为问题。

是否索引列始终是成本/收益问题。成本以大小来衡量，而效益可以用基数来衡量。

这里最好的选择是使用查询结构和索引。如果有必要（和一个选项）将数据库克隆到一个单独的服务器，只需尝试不同的解决方案，直到找到有效的解决方案。

MySql，索引和加速查询

1 个答案: