Mysql 确定使用地点；使用临时设备；使用文件排序

我有两个简单的表格：

CREATE TABLE cat_urls (
  Id int(11) NOT NULL AUTO_INCREMENT,
  SIL_Id int(11) NOT NULL,
  SiteId int(11) NOT NULL,
  AsCatId int(11) DEFAULT NULL,
  Href varchar(2048) NOT NULL,
  ReferrerHref varchar(2048) NOT NULL DEFAULT '',
  AddedOn datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  GroupId int(11) DEFAULT NULL,
  PRIMARY KEY (Id),
  INDEX SIL (SIL_Id, AsCatId)
)

CREATE TABLE products (
  Id int(11) NOT NULL AUTO_INCREMENT,
  CatUrlId int(11) NOT NULL,
  Href varchar(2048) NOT NULL,
  SiteIdentity varchar(2048) NOT NULL,
  Price decimal(12, 2) NOT NULL,
  IsAvailable bit(1) NOT NULL,
  ClientCode varchar(256) NOT NULL,
  PRIMARY KEY (Id),
  INDEX CatUrl (CatUrlId)
)

我有一个非常简单的问题：

SELECT cu.Href, COUNT(p.CatUrlId) FROM cat_urls cu
       JOIN products p ON p.CatUrlId=cu.Id
       WHERE sil_id=4601038
GROUP by cu.Id

解释说：

id  select_type table   type    possible_keys   key     key_len ref                     rows    Extra
1   SIMPLE      cu      ref     PRIMARY,SIL     SIL     4       const                   303     Using where; Using temporary; Using filesort
1   SIMPLE      p       ref     CatUrl          CatUrl  4       blue_collar_logs.cu.Id  6       Using index

---

请告诉我是否有任何方法可以修复在何处使用；使用临时设备；使用文件排序并改进此查询的性能？

出于某种原因，MySQL选择在第一个表上使用索引SIL，并将其用于SIL_id=4601038的查找和按cu.id分组

您可以告诉它使用表的PK

SELECT cu.Href, COUNT(p.CatUrlId) FROM cat_urls cu
    USE INDEX FOR JOIN (PRIMARY)
JOIN products p ON p.CatUrlId=cu.Id
WHERE sil_id=4601038
GROUP by cu.Id

它将产生这个执行计划：

id | select_type | table | type  | possible_keys | key     | key_len | ref              | rows | Extra
---+-------------+-------+-------+---------------+---------+---------+------------------+------+-------------
1  | SIMPLE      | cu    | index | PRIMARY       | PRIMARY | 4       | NULL             | 1    | Using where
1  | SIMPLE      | p     | ref   | CatUrl        | CatUrl  | 4       | cbs-test-1.cu.Id | 1    | Using index

忽略列行中报告的值；它们不正确，因为我的桌子是空的

注意，额外的列现在只包含usingwhere，还注意到连接类型列从ref very good更改为index full index scan，但不是很好

一个更好的解决方案是在SIL_Id列上添加一个索引。我知道，SIL_Id是索引SIL_Id，AsCatId的前缀，理论上，在SIL_Id列上的另一个索引是完全无用的。但它似乎解决了这个案件的问题

ALTER TABLE cat_urls
  ADD INDEX (SIL_Id)
;

现在在查询中使用它：

SELECT cu.Href, COUNT(p.CatUrlId) FROM cat_urls cu
    USE INDEX FOR JOIN (SIL_Id)
JOIN products p ON p.CatUrlId=cu.Id
WHERE sil_id=4601038
GROUP by cu.Id

查询执行计划现在看起来好多了：

id | select_type | table | type | possible_keys | key    | key_len | ref              | rows | Extra
---+-------------+-------+------+---------------+--------+---------+------------------+------+-------------
1  | SIMPLE      | cu    | ref  | SIL_Id        | SIL_Id | 4       | const            | 1    | Using where
1  | SIMPLE      | p     | ref  | CatUrl        | CatUrl | 4       | cbs-test-1.cu.Id | 1    | Using index

---

缺点是我们有一个理论上无用的额外索引。每次添加、删除一行或修改其SIL_Id字段时，它都会占用存储空间并消耗处理器周期。

如何解释选择href，从cat_URL求和c join select cu.Id，sumsil_id=4601038作为cat_URL的总和cu JOIN products p ON p.CatUrlId=cu.id GROUP by cu.id t ON t.id=c.idid select_type table type可能的_keys keys key key key ref len ref rows EXTRASS 1 PRIMARY ALL null null null null null 178525398 null 1 PRIMARY c eq_ref PRIMARY 4 t.id 1 null2派生cu索引主，SIL主4 null 29754233 null 2派生p ref CatUrl CatUrl 4蓝领日志。cu.Id 6使用索引此查询执行时间非常长