Александр Машин (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

  • Остановка

    Дискуссия о том, следовало ли штурмовать Берлин в феврале 1945 года, напоминает польский ой-вей о том, как Красная Армия не атаковала Варшаву, когда…

  • Битва за Москву

    «Сибирские дивизии» — просто кадровая армия. Дело не в том, что они были привычны к морозам, или лучше одеты. Просто, это — не спешно мобилизованные…

  • Люди — новая нефть: тоже кончаются

    Выношу из комментариев и упорядочиваю свои мысли по поводу человеческих ресурсов, повод высказать которые дала реплика «Как можно снять сливки с…

  • 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