我有以下 MySQL 表：
CREATE TABLE IF NOT EXISTS `pics` (
`id` mediumint(8) unsigned NOT NULL auto_increment,
`bnb_id` mediumint(7) unsigned NOT NULL,
`img_path` varchar(128) NOT NULL,
`img_path_gallery` varchar(128) NOT NULL,
`img_path_thumb_small` varchar(128) NOT NULL,
`img_path_thumb_large` varchar(128) NOT NULL,
`img_path_thumb_grid` varchar(128) NOT NULL,
`title` varchar(80) NOT NULL,
`order` tinyint(2) NOT NULL,
`upload_date` datetime NOT NULL,
`state` enum('LOCAL','S3') NOT NULL default 'LOCAL',
`is_cover` tinyint(1) unsigned default NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `bnb_id_2` (`bnb_id`,`is_cover`),
KEY `bnb_id` (`bnb_id`),
KEY `is_cover` (`is_cover`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=30371 ;
is_cover是我创建的一个字段，用于为每张图片选择一张图片bnb_id：当图片被选为封面时，它设置为 1，NULL否则设置为 1。我需要把LEFT JOIN桌子换到另一个，让我们称之为bnb；pics每个条目在表中可能有多行bnb（有一个参照完整性约束bnb_id），但在这种情况下，我必须从表中只提取一行pics，因此需要is_cover列和所有索引（我每隔一个解决方案尝试产生持续 10 到 50 秒的查询）。
但是，即使在这种情况下，查询也非常慢，并且在表中大约 10000 个元素和bnb表中大约 30000个元素的数据池上，每个查询都需要 5 到 8 秒的执行时间pics。从 where = 1 的表中选择is_cover非常快速和直接，但是当放入更大的查询时，一切都会中断。
SELECT subbnb.*,
3956 * 2 * ASIN(
SQRT(
POWER(
SIN((_LAT - abs(lat)) * pi()/180 / 2),
2) +
COS(_LAT * pi()/180 ) *
COS(abs(lat) * pi()/180) *
POWER(
SIN((_LNG - abs(lng)) * pi()/180 / 2),
2)
)
) AS distance,
prices.price,
pics.img_path_thumb_grid,
reviews.count reviewsCount,
likes.count likesCount
FROM
(SELECT
bnb.*,
bnbdata_a.*,
pos.lat,
pos.lng
FROM bnb
JOIN bnbdata
ON (bnb.id = bnbdata.bnb_id)
JOIN positions pos
ON (bnb.id = pos.bnb_id)
) subbnb
LEFT JOIN (
SELECT *
FROM pics
WHERE is_cover = 1
) pics
ON (subbnb.id = pics.bnb_id)
LEFT JOIN (SELECT price, bnb_id FROM prices WHERE category = "DAILY") prices
ON (subbnb.id = prices.bnb_id)
LEFT JOIN (SELECT COUNT(*) AS count, bnb_id FROM reviews GROUP BY bnb_id) reviews
ON (subbnb.id = reviews.bnb_id)
LEFT JOIN (SELECT COUNT(*) AS count, bnb_id FROM likes GROUP BY bnb_id) likes
ON (subbnb.id = likes.bnb_id)
WHERE
lng BETWEEN _LNGA AND _LNGB
AND lat BETWEEN _LATA AND _LATB
HAVING distance < 10
ORDER BY distance
LIMIT 0, 25
（您看到的带有 _ 前缀的字符串是实际数值）
EXPLAIN查询产生以下结果：
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived5> system NULL NULL NULL NULL 0 const row not found
1 PRIMARY <derived6> system NULL NULL NULL NULL 0 const row not found
1 PRIMARY <derived2> ALL NULL NULL NULL NULL 10522 Using where; Using temporary; Using filesort
1 PRIMARY <derived3> ALL NULL NULL NULL NULL 7040
1 PRIMARY <derived4> ALL NULL NULL NULL NULL 1
6 DERIVED likes index NULL PRIMARY 6 NULL 1 Using index
5 DERIVED reviews index NULL bnb_id 5 NULL 1 Using index
4 DERIVED prices ALL NULL NULL NULL NULL 1 Using where
3 DERIVED pics ref is_cover is_cover 2 11760 Using where
2 DERIVED pos ALL PRIMARY NULL NULL NULL 10543
2 DERIVED bnbdata eq_ref PRIMARY PRIMARY 3 db.pos.bnb_id 1
2 DERIVED bnb eq_ref PRIMARY PRIMARY 3 db.pos.bnb_id 1
看起来is_cover索引被 MySQL ( Using where, id 4) 忽略了，但是当我对pics表运行小选择时也会发生同样的情况，一切都发生得很快。我在这个查询中找不到瓶颈，删除 JOIN 以pics使一切变得更快，但是 JOIN 子查询本身非常快，大查询的其余部分也是如此 - 即使在开始时使用数学计算代码，它也永远不会去远远超过 2 秒的执行时间。
有谁知道瓶颈在哪里，以及如何解决这个问题？