Александр Машин (alex_mashin) wrote,
Александр Машин
alex_mashin

Category:

Доверяйте планировщику запросов, говорили они

После апгрейда MariaDB до 10.2 на одном сетевом проекте стало как-то холодно и неуютно.

Изучая лог ошибок, обнаружил, что некий запрос к базе данных, который (с точностью до критериев выборки) на отдельных страницах проекта мог выполняться по дюжине раз, отваливается по таймауту, а страница, соответственно, не отображается.

Запустив запрос прямо из консоли mysql, я с ужасом увидел, что он выполнялся 4 минуты 19 секунд. Вот этот запрос:
SELECT COUNT(*) FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t2.u = '(some integer)' AND t1.n = '(some integer)';

В обеих таблицах t1 и t2 было менее миллиона строк. Все индексы имелись. Первое подозрение, конечно, вызвал COUNT(*), но дело оказалось не в нём. Выборка по отдельным таблицам проходила быстро, COUNT(*) по ним по отдельности работал тоже быстро, даже с WHERE.

Разгадка оказалась в соединении таблиц. MariaDB 10.2 перестала использовать там индекс таблицы t2. Стоило добавить USE INDEX (t1_id_and_some_other_columns), как запрос стал исполняться менее, чем за секунду.

Вот как в 2017 году можно было поломать простой JOIN?

Tags: ИТ
Subscribe

  • Око за око

    Справедливо было бы делать с журналистами, сочиняющими истории о недоеденных еврейках и лозунгах, написанных зелёнкой «ниже спины», именно то, что…

  • Ryssä

    На мысль записи о национальном унижении, что русские могут выбирать между быстрым проигрышем и медленным, после первоначальных успехов, да и первой…

  • Национальное унижение

    Думаю, российскую космическую программу надо закрыть. I was fun while it lasted, but now it's over. Теперь она превратилась в источник национального…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment