Как обрабатывать левые соединения на больших столах? Неожиданное поведение

Question

Как обрабатывать левые соединения на больших столах? Неожиданное поведение

0

У меня проблема с моим запросом SQL:

Таблица цен насчитывает миллионы строк и должна запрашиваться правильно. Все работало нормально, и загрузка страницы заняла ~ 400 мс, пока я не обновил БД (обновил ее новой БД из нашей Prod DB), и она все сломала. Теперь загрузка страницы занимает 120 секунд.

Он отлично работает в наших средах prod и pre prod, но очень медленный в моей среде разработки. Я работаю с той же версией mysql и версией php. Использование Symfony 4 с доктриной 2 ORM.

Запрос, над которым я работаю, следующий:

SELECT 
c0_.id AS id_0, 
c0_.ticker AS ticker_1, 
c0_.name AS name_2, 
p1_.id AS id_3, 
p1_.rank AS rank_4, 
p1_.price_usd AS price_usd_5, 
p1_.1d_volume_usd AS 1d_volume_usd_6, 
p1_.change_1h AS change_1h_7, 
p1_.change_1d AS change_1d_8, 
p1_.change_7d AS change_7d_9, 
c2_.id AS id_10, 
c2_.market_cap AS market_cap_11, 
s3_.id AS id_12, 
s3_.score_buzz AS score_buzz_13, 
s3_.score_average AS score_average_14 
FROM coins c0_ 
LEFT JOIN prices p1_ ON c0_.id = p1_.ticker_id 
AND (p1_.last_updated >= ?) LEFT JOIN cmc c2_ ON c0_.id = c2_.ticker_id 
AND (c2_.last_updated >= ?) LEFT JOIN scores s3_ ON c0_.id = s3_.ticker_id 
AND (s3_.to_datetime >= ?) 
WHERE c0_.is_active = 1 ORDER BY c0_.rank_cmc ASC, p1_.last_updated DESC, c2_.last_updated DESC, s3_.to_datetime DESC

проблема исходит из этой части:

LEFT JOIN prices p1_ ON c0_.id = p1_.ticker_id AND (p1_.last_updated >= ?)

Если я уберу эту часть, она будет работать нормально. Откуда может появиться ПБ? почему у меня 2 разных поведения (prod и dev) для одного и того же запроса? Как вы обычно обрабатываете левое соединение на больших столах?

Спасибо

РЕДАКТИРОВАТЬ: Вот объяснение запроса в DEV:

Вот объяснение запроса в PROD:

EDIT2: Dev индексы по цене:

Miles M. 31 янв. 2019, в 12:33

Источник

0

Вы используете MySQL или MS SQL Server?
jarlh 31 янв. 2019, в 11:12
0

Я использую mysql
Miles M. 31 янв. 2019, в 11:13
3

Вы пытались использовать ключевое слово EXPLAIN, чтобы увидеть, какие индексы используются? и покажет, как можно его оптимизировать
mukund 31 янв. 2019, в 11:21
1

Можете ли вы просмотреть план запросов на рабочем сервере, а затем сравнить его с планом запросов на сервере разработки? Это может помочь найти основную причину. Это может быть проблема с индексом, так как ваше неравное соединение всегда будет проблематичным. Может быть, что производственная статистика отличается от вашей базы данных разработки, или что сами данные отличаются?
Richard Hansell 31 янв. 2019, в 11:22
2

Проверьте, есть ли у вас индекс, определенный в столбце ticker_id таблицы цен. Также определите раздел в столбце last_updated.
GauravS 31 янв. 2019, в 11:24
0

@mukund: Спасибо, я добавил результат EXPLAIN
Miles M. 31 янв. 2019, в 13:47
0

@Richard: Спасибо, как я могу просмотреть план запроса на сервере? Они должны быть идентичными (одинаковая версия, одинаковая структура).
Miles M. 31 янв. 2019, в 13:49
0

План запроса = ОБЪЯСНИТЕ, это просто терминология. Я хочу сказать, что если серверы производства / разработки действительно идентичны, то это, вероятно, является проблемой из-за различий в статистике и т. Д. В разных средах, что может привести к двум разным ОБЪЯСНЕНИЯМ.
Richard Hansell 31 янв. 2019, в 14:22
0

@GauravS: я создал индекс для ticker_id, но он мало помог (+ 25% быстрее, но все еще слишком медленно). Должен ли я смотреть на параметры MySQL может быть? сколько памяти я должен выделить с учетом базы данных 10Go?
Miles M. 31 янв. 2019, в 15:15
0

@Richard: Спасибо, я предоставил оба скриншота и обновил свой вопрос. На ценовой линии действительно есть другое, например, использование Join Buffer (в prod), но в dev говорится, что Range проверяется для каждой записи. Это откуда это? Как я мог это изменить? Спасибо
Miles M. 31 янв. 2019, в 15:18
0

@MilesM. Пожалуйста, предоставьте список ключей, я не вижу, чтобы большинство полей были index, которые используются в объединении и предложении where. Попробуйте добавить индекс в поле, которое используется для предложения "on" и "where"
mukund 01 фев. 2019, в 05:17
0

Конечно, для таблицы цен last_updated и идентификатор тикера индексируются в индексе search_idx, как показано на скриншоте (см. Edit2). Спасибо
Miles M. 01 фев. 2019, в 09:11

Показать ещё 10 комментариев

Теги:

php

mysql

sql-server

sql

symfony

2 ответа

Ещё вопросы

Вы пытались использовать ключевое слово EXPLAIN, чтобы увидеть, какие индексы используются? и покажет, как можно его оптимизировать
Можете ли вы просмотреть план запросов на рабочем сервере, а затем сравнить его с планом запросов на сервере разработки? Это может помочь найти основную причину. Это может быть проблема с индексом, так как ваше неравное соединение всегда будет проблематичным. Может быть, что производственная статистика отличается от вашей базы данных разработки, или что сами данные отличаются?
Проверьте, есть ли у вас индекс, определенный в столбце ticker_id таблицы цен. Также определите раздел в столбце last_updated.
@mukund: Спасибо, я добавил результат EXPLAIN
@Richard: Спасибо, как я могу просмотреть план запроса на сервере? Они должны быть идентичными (одинаковая версия, одинаковая структура).
План запроса = ОБЪЯСНИТЕ, это просто терминология. Я хочу сказать, что если серверы производства / разработки действительно идентичны, то это, вероятно, является проблемой из-за различий в статистике и т. Д. В разных средах, что может привести к двум разным ОБЪЯСНЕНИЯМ.
@GauravS: я создал индекс для ticker_id, но он мало помог (+ 25% быстрее, но все еще слишком медленно). Должен ли я смотреть на параметры MySQL может быть? сколько памяти я должен выделить с учетом базы данных 10Go?
@Richard: Спасибо, я предоставил оба скриншота и обновил свой вопрос. На ценовой линии действительно есть другое, например, использование Join Buffer (в prod), но в dev говорится, что Range проверяется для каждой записи. Это откуда это? Как я мог это изменить? Спасибо
@MilesM. Пожалуйста, предоставьте список ключей, я не вижу, чтобы большинство полей были index, которые используются в объединении и предложении where. Попробуйте добавить индекс в поле, которое используется для предложения "on" и "where"
Конечно, для таблицы цен last_updated и идентификатор тикера индексируются в индексе search_idx, как показано на скриншоте (см. Edit2). Спасибо

mukund · Answer 1 · 2019-02-01T04-17-00.000Z

Там может быть множество причин. Вы видите быстрый результат на своем сервере разработки, так как меньше записей, в то время как ваш живой сервер состоит из большого количества записей (см. Столбец rows в операторе объяснения).

Я рекомендую проверить все ключи и тип вашего столбца join. Каждый столбец, используемый в соединении с предложением " on ", должен иметь сходный тип, иначе он будет замедлен. Поэтому убедитесь, что столбцы int+unsigned или varchar и т.д.

Найдите в вашем выводе possible_key, key and extra столбец и попытайтесь понять по следующей ссылке, которая поможет вам найти правильное решение.

https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

Также см. Раздел "ПОЯСНИТЕ ИНТЕРПРЕТАЦИЮ ВЫХОДА" по вышеуказанной ссылке

Спасибо mukund за этот ответ, между dev и prod одинаковое количество результатов, dev DB - это экспорт / импорт prod с точно такой же структурой и данными. Я проверил все ключи и индексы моих соединенных столбцов (таблица цен), и они совпадают. Из того, что я понимаю, глядя на объяснение, кажется, что SQL не использует индекс в запросе выбора в dev, когда он использует его в prod. Почему так?
Я вижу, добавлены индексы для: rank, ticker_id and last_updated Какое здесь rank, ticker_id and last_updated ? LEFT JOIN prices p1_ ON c0_.id = p1_.ticker_id AND (p1_.last_updated >= ?) Попробуйте добавить индекс к указанным выше столбцам id, ticker_id, last_updated
Вы также можете форсировать это `FROM X WITH (INDEX (search_idx))`
id - это первичный ключ, нужно ли его индексировать?
Затем уберите ранг по крайней мере, так как он нигде не используется
Спасибо за помощь, к сожалению, это не так много. Я немного невежественен: / Как ты думаешь, куда мне обратиться?

Lasouze · Answer 2 · 2019-01-31T16-42-00.000Z

Посмотрите на запрос prod и dev объясните, на строчке p1_ для столбца 'key': в dev это NULL, в prod это search_idx.

Вывод: если вы запускаете "bin/console d: s: u --dump-sql" в среде prod и dev, вам нужно найти некоторую разницу в схеме дБ.

Спасибо Lasouze, но, к сожалению, структура БД точно такая же, от Dev до Prod, поэтому, почему я борюсь с этим, мне кажется, что это что-то отличается от выбора объяснения, но я не могу понять, как это исправить и изменить настройки моей БД, чтобы вести себя как на продукт. Спасибо
Можем ли мы заставить sql использовать индекс? Потому что я думаю, что вы правы, вот откуда возникла проблема, но по какой-то причине он не использует индекс в запросе выбора, где он должен его использовать.