MySQL долгое время отклика
У меня есть действующий запрос MySQL, который выбирает последний процент занятости таблицы из каждого сообщества, введенного в мою БД, но, похоже, он сканирует всю БД записей, поскольку время поиска занимает примерно 3-4 секунды.
Может ли кто-нибудь предоставить мне более быстрый / лучший способ поиска в поле последней отметки времени для каждого сообщества с подробностями, указанными в запросе ниже? - Мне нужен запрос для выбора каждого введенного сообщества с последней меткой времени, но предел для каждого выбранного сообщества должен быть 1 (это означает, что сообщество с именем «Тестовое сообщество», возможно, будет иметь сотни представлений, но мне нужно выбрать последнюю введенную метку времени, а также с одинаковым выбором для каждого сообщества, указанного в таблице)
SELECT t1.reportID, t1.communityID, t1.region, t1.percentOccupied,
t1.TIMESTAMP, Communities.fullName
FROM NightlyReports t1
INNER JOIN Communities On t1.communityID = Communities.communityID
WHERE t1.TIMESTAMP = ( SELECT MAX( TIMESTAMP ) FROM NightlyReports WHERE
t1.communityID = NightlyReports.communityID )
AND t1.region = 'GA' ORDER BY percentOccupied DESC
Ответы 2
По моему опыту, коррелированные подзапросы часто имеют довольно низкую производительность; попробуйте вместо этого:
SELECT t1.reportID, t1.communityID, t1.region, t1.percentOccupied
, t1.TIMESTAMP, Communities.fullName
FROM NightlyReports AS t1
INNER JOIN Communities ON t1.communityID = Communities.communityID
INNER JOIN (
SELECT communityID, MAX( TIMESTAMP ) AS lastTimestamp
FROM NightlyReports
WHERE region = 'GA'
GROUP BY communityID
) AS lastReports ON t1.communityID = lastReports.communityID
AND t1.TIMESTAMP = lastReports.lastTimestamp
WHERE t1.region = 'GA'
ORDER BY percentOccupied DESC
Вы можете присоединиться к сколь угодно большому количеству таблиц (или вложенных последовательностей) (в пределах разумного, конечно), если каждая из них имеет уникальный идентификатор / псевдоним. В нескольких соединениях нет ничего особенного, так же как a + b + c на самом деле не более особенный, чем a + b.
Ну ладно, в этом есть смысл, я буду помнить на будущее, еще раз спасибо!
Ваш запрос в порядке. Для этого запроса (который немного переписан):
SELECT nr.reportID, nr.communityID, nr.region, nr.percentOccupied,
nr.TIMESTAMP, c.fullName
FROM NightlyReports nr INNER JOIN
Communities c
ON nr.communityID = c.communityID
WHERE nr.TIMESTAMP = (SELECT MAX(nr2.TIMESTAMP)
FROM NightlyReports nr2
WHERE nr.communityID = nr2.communityID
) AND
nr.region = 'GA'
ORDER BY percentOccupied DESC;
Вам нужны индексы:
NightlyReports(region, timestamp, communityid)NightlyReports(communityid, timestamp)Communities(communityID)(может уже существовать)
Коррелированный подзапрос не является проблемой как таковой.
Хм ... Оглядываясь назад на этот вопрос, мне любопытно. Вы хотите сказать, что предоставленный вами альтернативный запрос с включенным коррелированным подзапросом так же быстр, как и ответ @Uueerdo? Я протестирую это, но мне любопытно, потому что вы упомянули, что подзапрос можно использовать по-другому, когда он «сам по себе не является проблемой».
@ViaTech. . . Может быть быстрее, особенно с данными индексами. Я дал этот ответ, потому что он ближе к вашему исходному запросу.
Потрясающе, этот запрос - именно то, что я искал, вот почему я люблю ТАК .... спасибо! Не могли бы вы описать двойное ВНУТРЕННЕЕ СОЕДИНЕНИЕ? Я немного не напутал с запросами, но я не использовал это раньше