MySQL Long Response Time

0

У меня есть действительный MySQL Query, который выбирает последний процент заполнения таблицы из каждого сообщества, введенный в моей БД, но, похоже, сканирует весь БД записей, поскольку время поиска занимает примерно 3-4 секунды.

С подробностями, представленными в нижеприведенном запросе, может ли кто-нибудь предоставить мне более быстрый/лучший способ найти последнее временное поле для каждого сообщества? - Мне нужен запрос, чтобы выбрать каждое введенное сообщество с самой последней отметкой времени, но ограничение для каждого выбранного сообщества должно быть 1 (это означает, что сообщество с именем "Test Community" будет иметь сотни представлений, но мне нужна последняя введенная отметка времени, с тем же выбором для каждого сообщества, внесенного в таблицу)

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 ответа

1
Лучший ответ

По моему опыту, коррелированные подзапросы часто имеют довольно низкую производительность; попробуйте это вместо этого:

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
Поделиться
  • 0
    Круто, этот запрос - именно то, что я искал, вот почему я так люблю .... спасибо! Можете ли вы описать двойной INNER JOIN, хотя? Я не разобрался с запросами, но это не то, что я использовал раньше
  • 0
    Вы можете объединить столько таблиц (или вложенных запросов), сколько необходимо (конечно, в пределах разумного), если каждая из них имеет уникальный идентификатор / псевдоним. Ничего особенного в множественных объединениях нет, точно так же, как a + b + c на самом деле не более особенный, чем a + b.
Показать ещё 1 комментарий
1

Ваш запрос в порядке. Для этого запроса (который переписан немного):

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) (это может уже существовать)

Коррелированный подзапрос сам по себе не является проблемой.

Поделиться
  • 0
    Хм ... Оглядываясь назад на этот вопрос, мне любопытно. Вы говорите, что предоставленный вами альтернативный запрос с еще включенным коррелированным подзапросом так же быстр, как и ответ @Uueerdo? Я протестирую это, но мне любопытно, потому что вы упомянули, что подзапрос можно использовать по-другому, где он «сам по себе не является проблемой».
  • 0
    @ViaTech. , , Может быть быстрее, особенно с учетом индексов. Я дал этот ответ, потому что он ближе к вашему исходному запросу.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню