gpt4 book ai didi

mysql - 固定使用位置;使用临时的;使用文件排序

转载 作者:可可西里 更新时间:2023-11-01 06:49:53 26 4
gpt4 key购买 nike

我有两个简单的表:

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

EXPLAIN 说:

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 并且它同时使用它进行查找 (WHERE sil_id = 4601038) 和分组(GROUP BY 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

忽略 rows 列中报告的值;它们不正确,因为我的 table 是空的。

请注意 Extra 列现在仅包含 Using where 但还要注意连接 type 列从 ref (非常好)到 index(全索引扫描,不太好)。

更好的解决方案是在 SIL_Id 列上添加索引。我知道,SIL_Id 是索引 SIL(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 字段时,它都会占用存储空间并消耗处理器周期。

关于mysql - 固定使用位置;使用临时的;使用文件排序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27645719/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com