gpt4 book ai didi

mysql - LEFT JOIN 查询太慢以至于超时

转载 作者:行者123 更新时间:2023-11-29 23:15:32 24 4
gpt4 key购买 nike

下面的查询运行时间太长,最终超时。我查看了 EXPLAIN 计划,似乎它没有使用我的一个表的索引,所以我认为这与它有关,尽管我不确定为什么会发生这种情况。这是查询:

SELECT documentID
, coID
, suiteID
, leaseID
, assetID
, vendorID
, feed_documents.did
, document_links.doid
FROM feed_documents
LEFT
JOIN document_links
ON feed_documents.did = document_links.doid
WHERE doid IS NULL
LIMIT 0, 75000

这是 EXPLAIN 的结果:

id  select_type table           type  possible_keys key   key_len ref                               rows    Extra
1 SIMPLE feed_documents ALL NULL NULL NULL 119363 NULL NULL
1 SIMPLE document_links ref doid doid 4 rladmin_rlhpsi.feed_documents.did 12 Using where; Not exists; Using index

feed_documents 表在所有 select/join 列上都有索引,而 document_links 表在所有列上都有索引。有人可以看到我在这里做错了什么吗?

更新:表定义,根据请求。

CREATE TABLE `feed_documents` (
`documentID` int(11) NOT NULL DEFAULT '0',
`documentTitle` varchar(250) COLLATE utf8_unicode_ci DEFAULT NULL,
`documentFileName` varchar(500) COLLATE utf8_unicode_ci DEFAULT NULL,
`documentDate` datetime DEFAULT NULL,
`documentArchived` int(11) DEFAULT NULL,
`documentTypeID` int(11) DEFAULT NULL,
`coID` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
`suiteID` int(11) DEFAULT NULL,
`leaseID` int(11) DEFAULT NULL,
`assetID` int(11) DEFAULT NULL,
`vendorID` int(11) DEFAULT NULL,
`did` int(11) DEFAULT NULL,
PRIMARY KEY (`documentID`),
KEY `coID` (`coID`),
KEY `suiteID` (`suiteID`),
KEY `leaseID` (`leaseID`),
KEY `assetID` (`assetID`),
KEY `vendorID` (`vendorID`),
KEY `did` (`did`),
KEY `documentTypeID` (`documentTypeID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci


CREATE TABLE `document_links` (
`dlid` int(11) NOT NULL AUTO_INCREMENT,
`daid` int(11) NOT NULL COMMENT 'Dataset ID',
`linkid` int(11) NOT NULL COMMENT 'ID value of linked item',
`doid` int(11) NOT NULL COMMENT 'Document ID',
PRIMARY KEY (`dlid`),
KEY `daid` (`daid`),
KEY `linkid` (`linkid`),
KEY `doid` (`doid`)
) ENGINE=MyISAM AUTO_INCREMENT=148767 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

最佳答案

我发现您希望查询中的 doidNULLfeed_documents.did = document_links.doid

据我了解,这意味着将feed_documents.did = null的所有行joindocument_links.doid的所有行。这是多对多关系,查询速度很慢也就不足为奇了,特别是如果 feed_documents 中有许多行 did = null 且 document_links 中有许多行 doid = null >.

如果第一个表中有 n 匹配行,第二个表中有 m 匹配行,则结果集将包含 n*m 行,这些行可以很大取决于您的数据。

无论哪种方式,为什么您一次需要 75000 行?

PS不用说,您的查询可能会很慢,如果超时,可能一个或两个表都被另一个查询锁定。

关于mysql - LEFT JOIN 查询太慢以至于超时,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27851099/

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