Быстрые запросы типа «как», нуждаются в объяснении - PullRequest
0 голосов
/ 25 февраля 2020

У меня следующий sql запрос:

select a,b from table left join table2 on ... 
   where
     table.date > (some date) and 
     table.date < (some date) and
     table.first not like '%condition1%' and
     table.first not like '%condition2%' and
     table.first not like '%condition3%' and
     table.first not like '%condition4%' and
     table.first not like '%condition5%'
limit 500 offset 500

"таблица" - это очень большая секционированная таблица, например, применяется индекс AFTER на дату, мы получаем около 4,2 млн строк для сканирования для дальнейшего где фильтрация.

Итак, этот запрос работает очень быстро - примерно за 250 мс, как это возможно? Разве мы не научились не использовать как-либо на больших столах, особенно таким образом, когда% применяется в обоих направлениях?

Также, конечно, «таблица» - не имеет никакого индекса для «первого» столбец Версия Percona довольно старая - 5.5.61-38.13.

Как это поведение можно объяснить?

Ответы [ 2 ]

1 голос
/ 23 марта 2020

Я рекомендую вам избегать LIKE Поисков с ведущим символом подстановки. База данных не будет использовать индекс при использовании похожих поисков с лидирующим подстановочным знаком (например, '%condition1%'). Хотя это не всегда удовлетворительное решение, рассмотрите возможность использования шаблонов LIKE с префиксным соответствием (например, 'TERM%').

Пример оптимальной практики:

SELECT
  id,
  text
FROM
  tbl
WHERE
  text LIKE 'TERM%';

Пример плохой практики:

SELECT
  id,
  text
FROM
  tbl
WHERE
  text LIKE '%TERM%';

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

Пример оптимальной практики:

SELECT
  name,
  age,
  department
FROM
  employees
WHERE
  (id, age) > (5000, 40)
ORDER BY
  id,
  age
LIMIT
  10;

Пример неправильной практики:

SELECT
  name,
  age,
  department
from
  employees
where
  age > 40
ORDER BY
  age
LIMIT
  10 OFFSET 5000;

Отказ от ответственности: Я всегда являюсь соучредителем SQL, и вы можете автоматически ускорить ваш запрос @ Ever SQL онлайн SQL оптимизатор

1 голос
/ 25 февраля 2020

Хорошо, я понял. Проблема заключалась в том, что в моем запросе не было "order by" Добавление порядка к этому запросу увеличивает время запроса до 6 секунд - что сейчас ОЧЕНЬ имеет смысл.

Так что в предыдущей ситуации mysql просто искал ЛЮБЫЕ данные, соответствующие 5-образному шаблону, независимо от сортировки, что теперь объясняет, почему это работало так быстро в дополнение к 500 смещения предела

...