MySQL - 加速查询避免文件排序和临时
MySQL - speed up query avoid filesort and temporary
我的 MySQL 查询很慢。我有 3 个表:jobs(200k 记录),locations(300k),positions(700k)。
SELECT
j.job_offerid
FROM `job_offer` AS j
INNER JOIN `job_offer_localitymap` AS d ON d.`job_offerid` = j.`job_offerid` AND
`gps_localityid` IN(35, 3301, 3302, 3303, 3305, 3306, 3307, 3308, 124, 3811, 3805, 3709, 3808, 3809)
WHERE
j.`status` = 1 AND
j.`job_offerid` IN(
SELECT `job_offerid`
FROM `job_offer_positionmap`
WHERE `cb_job_positionid` IN (1001, 6, 629, 7, 8, 9, 10, 11, 12, 13, 1, 15, 16, 17))
ORDER BY j.`job_offerid` DESC
LIMIT 3
我必须过滤职位和地区,所以我使用了 IN。
解释:使用哪里;使用索引;使用临时的;使用文件排序;开始临时
Table 仅使用行的方案:
CREATE TABLE `job_offer` (
`job_offerid` int(13) NOT NULL AUTO_INCREMENT,
`status` int(13) NOT NULL DEFAULT '1',
PRIMARY KEY (`job_offerid`),
KEY `status` (`status`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `job_offer_localitymap` (
`job_offer_localitymapid` int(13) NOT NULL AUTO_INCREMENT,
`gps_localityid` int(13) NOT NULL,
`job_offerid` int(13) NOT NULL,
PRIMARY KEY (`job_offer_localitymapid`),
KEY `gps_localityid` (`gps_localityid`),
KEY `job_offerid` (`job_offerid`),
KEY `gps_localityid_job_offerid` (`gps_localityid`,`job_offerid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
CREATE TABLE `job_offer_positionmap` (
`job_offer_positionmapid` int(13) NOT NULL AUTO_INCREMENT,
`cb_job_positionid` int(13) NOT NULL,
`job_offerid` int(13) NOT NULL,
PRIMARY KEY (`job_offer_positionmapid`),
KEY `cb_job_positionid` (`cb_job_positionid`),
KEY `job_offerid` (`job_offerid`),
KEY `cb_job_positionid_job_offerid` (`cb_job_positionid`,`job_offerid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
索引无处不在。
感谢您的任何建议
您的加入将从复合中受益
job_offer_localitymap.(job_offerid,gps_localityid)
也就是说,在 table.
中,与您目前的组合相反
因此你可以放弃这两个:
KEY `gps_localityid` (`gps_localityid`),
KEY `job_offerid` (`job_offerid`),
因为你会留下两个复合索引,最左边的每个都被其他查询使用,这些查询受益于上述两个我刚刚说要删除
在您的查询第 5 行中,保持一致并使用别名 j
,因为我不得不寻找(不长)以查看哪个 table
在我看来 job_offer 中的 KEY status
(status
) 可能相对没用,但我不知道你还有其他疑问。但是,由于您的数据类型很薄,因此 job_offer(job_offerid,status) 上的复合可能会使您的许多查询飞起来,因为 covering index
不需要在数据页之后进行.
至于 job_offer_positionmap
,这可能是一个删除缓慢子查询的连接和开发人员选择在那里添加一个组合。该连接在概念上类似于第一个连接。
我认为 in 子句一般没有问题,因为 mysql CBO 基于成本的优化器应该处理这个问题。
但这些只是建议,因为添加索引并非完全没有缺点。这是一个脆弱的平衡行为,但最终您可能会发现不仅这个查询成功了,您的其他查询也成功了。
您正在使用 join
进行过滤。所以我会将该逻辑移至 where
子句:
SELECT j.job_offerid
FROM `job_offer`
WHERE j.`status` = 1 AND
j.`job_offerid` IN (SELECT jop.`job_offerid`
FROM `job_offer_positionmap` jop
WHERE `cb_job_positionid` IN (1001, 6, 629, 7, 8, 9, 10, 11, 12, 13, 1, 15, 16, 17)
) AND
j.`job_offerid` IN (SELECT jop.`job_offerid`
FROM `job_offer_localitymap` jol
WHERE jol.gps_localityid IN (35, 3301, 3302, 3303, 3305, 3306, 3307, 3308, 124, 3811, 3805, 3709, 3808, 3809)
)
ORDER BY j.`job_offerid` DESC
LIMIT 3;
然后,对于此查询,您需要以下索引:
- job_offer(status, job_offerid desc)
- job_offer_positionmap(cb_job_positionid, job_offerid)
- job_offer_localitymap(gps_localityid, job_offerid)
生成的查询应使用第一个索引进行过滤和 order by
子句。然后它将使用其他两个索引进行过滤。
我的 MySQL 查询很慢。我有 3 个表:jobs(200k 记录),locations(300k),positions(700k)。
SELECT
j.job_offerid
FROM `job_offer` AS j
INNER JOIN `job_offer_localitymap` AS d ON d.`job_offerid` = j.`job_offerid` AND
`gps_localityid` IN(35, 3301, 3302, 3303, 3305, 3306, 3307, 3308, 124, 3811, 3805, 3709, 3808, 3809)
WHERE
j.`status` = 1 AND
j.`job_offerid` IN(
SELECT `job_offerid`
FROM `job_offer_positionmap`
WHERE `cb_job_positionid` IN (1001, 6, 629, 7, 8, 9, 10, 11, 12, 13, 1, 15, 16, 17))
ORDER BY j.`job_offerid` DESC
LIMIT 3
我必须过滤职位和地区,所以我使用了 IN。
解释:使用哪里;使用索引;使用临时的;使用文件排序;开始临时
Table 仅使用行的方案:
CREATE TABLE `job_offer` (
`job_offerid` int(13) NOT NULL AUTO_INCREMENT,
`status` int(13) NOT NULL DEFAULT '1',
PRIMARY KEY (`job_offerid`),
KEY `status` (`status`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `job_offer_localitymap` (
`job_offer_localitymapid` int(13) NOT NULL AUTO_INCREMENT,
`gps_localityid` int(13) NOT NULL,
`job_offerid` int(13) NOT NULL,
PRIMARY KEY (`job_offer_localitymapid`),
KEY `gps_localityid` (`gps_localityid`),
KEY `job_offerid` (`job_offerid`),
KEY `gps_localityid_job_offerid` (`gps_localityid`,`job_offerid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
CREATE TABLE `job_offer_positionmap` (
`job_offer_positionmapid` int(13) NOT NULL AUTO_INCREMENT,
`cb_job_positionid` int(13) NOT NULL,
`job_offerid` int(13) NOT NULL,
PRIMARY KEY (`job_offer_positionmapid`),
KEY `cb_job_positionid` (`cb_job_positionid`),
KEY `job_offerid` (`job_offerid`),
KEY `cb_job_positionid_job_offerid` (`cb_job_positionid`,`job_offerid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
索引无处不在。
感谢您的任何建议
您的加入将从复合中受益
job_offer_localitymap.(job_offerid,gps_localityid)
也就是说,在 table.
中,与您目前的组合相反因此你可以放弃这两个:
KEY `gps_localityid` (`gps_localityid`),
KEY `job_offerid` (`job_offerid`),
因为你会留下两个复合索引,最左边的每个都被其他查询使用,这些查询受益于上述两个我刚刚说要删除
在您的查询第 5 行中,保持一致并使用别名 j
,因为我不得不寻找(不长)以查看哪个 table
在我看来 job_offer 中的 KEY status
(status
) 可能相对没用,但我不知道你还有其他疑问。但是,由于您的数据类型很薄,因此 job_offer(job_offerid,status) 上的复合可能会使您的许多查询飞起来,因为 covering index
不需要在数据页之后进行.
至于 job_offer_positionmap
,这可能是一个删除缓慢子查询的连接和开发人员选择在那里添加一个组合。该连接在概念上类似于第一个连接。
我认为 in 子句一般没有问题,因为 mysql CBO 基于成本的优化器应该处理这个问题。
但这些只是建议,因为添加索引并非完全没有缺点。这是一个脆弱的平衡行为,但最终您可能会发现不仅这个查询成功了,您的其他查询也成功了。
您正在使用 join
进行过滤。所以我会将该逻辑移至 where
子句:
SELECT j.job_offerid
FROM `job_offer`
WHERE j.`status` = 1 AND
j.`job_offerid` IN (SELECT jop.`job_offerid`
FROM `job_offer_positionmap` jop
WHERE `cb_job_positionid` IN (1001, 6, 629, 7, 8, 9, 10, 11, 12, 13, 1, 15, 16, 17)
) AND
j.`job_offerid` IN (SELECT jop.`job_offerid`
FROM `job_offer_localitymap` jol
WHERE jol.gps_localityid IN (35, 3301, 3302, 3303, 3305, 3306, 3307, 3308, 124, 3811, 3805, 3709, 3808, 3809)
)
ORDER BY j.`job_offerid` DESC
LIMIT 3;
然后,对于此查询,您需要以下索引:
- job_offer(status, job_offerid desc)
- job_offer_positionmap(cb_job_positionid, job_offerid)
- job_offer_localitymap(gps_localityid, job_offerid)
生成的查询应使用第一个索引进行过滤和 order by
子句。然后它将使用其他两个索引进行过滤。