Просто выключите брандмауэр и удалите конфигурацию экземпляра. Добавьте новый экземпляр для сервера.! [Disable Firewall] [1] Дайте ему номер порта правильно, как 3306 по умолчанию
Использование хешей - один из способов, которыми ядро базы данных может выполнить соединение. Очень редко вам придется писать собственное соединение на основе хэша; это определенно не Он выглядит как один из них, с таблицей 900 тыс. строк с некоторыми агрегатами.
Судя по вашему комментарию, этот запрос может делать то, что вы ищете:
SELECT cur.source_prefix,
cur.source_name,
cur.category,
cur.element_id,
MAX(cur.date_updated) AS DateUpdated,
AVG(cur.value) AS AvgValue,
SUM(cur.value * cur.weight) / SUM(cur.weight) AS Rating
FROM eev0 cur
LEFT JOIN eev0 next
ON next.date_updated < '2009-05-01'
AND next.source_prefix = cur.source_prefix
AND next.source_name = cur.source_name
AND next.element_id = cur.element_id
AND next.date_updated > cur.date_updated
WHERE cur.date_updated < '2009-05-01'
AND next.category IS NULL
GROUP BY cur.source_prefix, cur.source_name,
cur.category, cur.element_id
GROUP BY выполняет вычисления для каждого источника + категории + элемента.
JOIN служит для фильтрации старых записей. Он ищет более поздние записи, а затем оператор WHERE отфильтровывает строки, для которых существует более поздняя запись. Подобное соединение выигрывает от индексации по (source_prefix, source_name, element_id, date_updated).
Есть много способов отфильтровать старые записи, но этот, как правило, работает достаточно хорошо.
а затем оператор WHERE отфильтровывает строки, для которых существует более поздняя запись. Подобное соединение выигрывает от индексации по (source_prefix, source_name, element_id, date_updated).Есть много способов отфильтровать старые записи, но этот, как правило, работает достаточно хорошо.
а затем оператор WHERE отфильтровывает строки, для которых существует более поздняя запись. Подобное соединение выигрывает от индексации по (source_prefix, source_name, element_id, date_updated).Есть много способов отфильтровать старые записи, но этот, как правило, работает достаточно хорошо.
Итак, 900K строк - это не массивная таблица, она достаточно большая, но и ваши запросы действительно не должны занимать так много времени .
Перво-наперво, какое из трех приведенных выше утверждений занимает больше всего времени?
Первая проблема, которую я вижу, связана с вашим первым запросом. Ваше предложение WHERE не включает индексированный столбец. Это означает, что он должен выполнить полное сканирование всей таблицы.
Создайте индекс для столбца «data_updated», затем снова запустите запрос и посмотрите, что это даст вам.
Если вы этого не сделаете. Мне нужны хеши, и они используют их только для того, чтобы воспользоваться темной магией, а затем полностью удалить их.
Редактировать: Кто-то, у кого больше SQL-fu, чем у меня, вероятно, сократит весь ваш набор логики в один оператор SQL без использования временные таблицы.
Редактировать: Мой SQL немного устарел, но вы дважды присоединяетесь к третьему этапу SQL? Может быть, это не будет иметь значения, но не должно быть:
SELECT temp1.element_id,
temp1.category,
temp1.source_prefix,
temp1.source_name,
temp1.date_updated,
AVG(temp1.value) AS avg_value,
SUM(temp1.value * temp1.weight) / SUM(weight) AS rating
FROM temp1 LEFT JOIN temp2 ON temp1.subcat_hash = temp2.subcat_hash
WHERE temp1.date_updated = temp2.maxdate
GROUP BY temp1.cat_hash;
или
SELECT temp1.element_id,
temp1.category,
temp1.source_prefix,
temp1.source_name,
temp1.date_updated,
AVG(temp1.value) AS avg_value,
SUM(temp1.value * temp1.weight) / SUM(weight) AS rating
FROM temp1 temp2
WHERE temp2.subcat_hash = temp1.subcat_hash
AND temp1.date_updated = temp2.maxdate
GROUP BY temp1.cat_hash;