В MySQL ли порядок столбцов в предложении WHERE влияет на производительность запросов?

У меня возникают проблемы с производительностью для определенных запросов к базе данных, которые имеют большие возможные наборы результатов.

В рассматриваемом вопросе у меня есть три AND s в предложении WHERE

Означает ли порядок пунктов?

Как и в случае, если я сначала поставлю предложение ASI_EVENT_TIME (так как это удалит большую часть результатов из любого из предложений.

Будет ли это улучшать время выполнения запроса?

QUERY

SELECT DISTINCT  activity_seismo_info.* 
FROM `activity_seismo_info` 
WHERE 
    activity_seismo_info.ASI_ACTIVITY_ID IS NOT NULL  AND 
    activity_seismo_info.ASI_SEISMO_ID IN (43,44,...,259) AND 
    (
        activity_seismo_info.ASI_EVENT_TIME>='2011-03-10 00:00:00' AND 
        activity_seismo_info.ASI_EVENT_TIME<='2011-03-17 23:59:59'
    ) 

ORDER BY activity_seismo_info.ASI_EVENT_TIME DESC

EXPLAIN запроса:

+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
| id | select_type | table   | type  | possible_keys             | key          | key_len | ref  | rows  | Extra                       |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
|  1 | SIMPLE      | act...o | range | act...o_FI_1,act...o_FI_2 | act...o_FI_1 | 5       | NULL | 65412 | Using where; Using filesort |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+

Использование:

PHP 5.2

MySQL 5.0.51a-3ubuntu5.4

Propel 1.3

Symfony 1.2.5

35 голосов | спросил Patrick 17 MarpmThu, 17 Mar 2011 23:56:41 +03002011-03-17T23:56:41+03:0011 2011, 23:56:41

6 ответов


21

Я так не думаю. Оптимизатор запросов должен быть достаточно умным.

Вы можете попробовать переупорядочить предложения WHERE и увидеть, что EXPLAINS сообщает вам то же самое в каждом случае.


О том, что можно сделать для оптимизации этого запроса: есть ли индекс ASI_EVENT_TIME? (это наиболее важно для этого запроса, так как вы также сортируете результаты, используя его).

Существуют ли индексы для двух других полей (ASI_SEISMO_ID и ASI_ACTIVITY_ID)?

Было бы полезно, если бы вы разместили структуру таблицы.

ответил ypercubeᵀᴹ 18 MaramFri, 18 Mar 2011 00:31:33 +03002011-03-18T00:31:33+03:0012 2011, 00:31:33
13

Из документации :

  

Если таблица имеет несколько столбцов   index, любой левый префикс   индекс может использоваться оптимизатором для   найдите строки. Например, если у вас есть   индекс с тремя столбцами (col1, col2,   col3), вы индексировали поиск   возможности на (col1), (col1, col2),   и (col1, col2, col3).

     

MySQL не может использовать индекс, если   столбцы не образуют левый префикс   индекса.

Итак, да, он должен быть таким же, как порядок столбцов в составной индекс .

ответил Gaius 18 MaramFri, 18 Mar 2011 00:07:26 +03002011-03-18T00:07:26+03:0012 2011, 00:07:26
7

Нет, это не имеет значения.

Оптимизатор выполняет кучу простых преобразований сразу после того, как он анализирует SQL - это один из них.

ответил Morgan Tocker 21 MarpmMon, 21 Mar 2011 23:48:48 +03002011-03-21T23:48:48+03:0011 2011, 23:48:48
6
  

WHERE foo AND bar

оптимизирует то же, что и

  

WHERE bar AND foo

Однако

  

ГДЕ не равно # 1 И не равно # 2

Невозможно оптимизировать обе части. Например,

  

ГДЕ МЕЖДУ 1 и 3 И b> 17

не может эффективно использовать INDEX (a, b) или INDEX (b, a)

Чтобы сформулировать это по-другому, сначала используются все '=' тесты AND'd вместе в предложении WHERE, а затем one non - '=' (IN, BETWEEN, & gt ;, и т. д.) может обрабатываться. Не более чем можно эффективно оптимизировать.

В вашем запросе есть 3 таких предложения.

Как оказалось, INDEX (EVENT_TIME), вероятно, самый полезный - он поможет с одним из AND, и его можно использовать, чтобы избежать «filesort» для ORDER BY.

Если нет повторяющихся строк (почему это так?), тогда избавиться от DISTINCT. Это вызывает еще большее усилие.

Пожалуйста, предоставьте SHOW CREATE TABLE и SHOW TABLE STATUS, задавая вопросы производительности.

ответил Rick James 21 Mayam11 2011, 02:33:50
0

MySQL, где doc говорит:

  

У вас может возникнуть соблазн переписать ваши запросы, чтобы сделать арифметические операции быстрее, при этом жертвуя удобочитаемостью. Поскольку MySQL делает подобные оптимизации автоматически , вы часто можете избежать этой работы и оставить запрос в более понятной и поддерживаемой форме. Некоторые из оптимизаций, выполняемых MySQL, следующие:

     
  • ...

  •   
  • Для каждой таблицы в соединении более простая WHERE построена , чтобы получить быструю оценку WHERE для таблицы, а также как можно скорее пропустить строки .

  •   
  • Каждый индекс таблицы запрашивается, и лучший индекс используется, если оптимизатор не считает, что эффективнее использовать сканирование таблицы . В свое время сканирование использовалось на основании того, что лучший индекс охватывает более 30% таблицы, но фиксированный процент больше не определяет выбор между использованием индекса или проверки. Оптимизатор теперь более сложный и основывает свою оценку на дополнительных факторах, таких как размер таблицы, количество строк и размер блока ввода-вывода.
  •   

Таким образом, для оптимизатора запросов рационально опускать HOW-порядок, мы использовали столбцы в запросе (не только MySQL, но SQL является декларативным языком ) и должны делать то, что мы не хотим, как мы хотите).

Однако мне все еще нравится иметь одинаковый вид для столбцов составного ключа в запросе, но иногда это неизбежно, например, когда мы используем ORM или ActiveRecord, в некоторых рамках, таких как yii2, настройка критериев отношений будет добавлена ​​к конец «on», но нам все еще нужны возможности QueryBuilders в разных частях приложения.

ответил Alix 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 28 Sep 2016 17:18:56 +0300 2016, 17:18:56
-2

ЛЮБОЕ , которое используется в ваших предложениях WHERE /HAVING и имеет высокую избирательность (количество уникальных значений /общее количество записей> 10% ~ 20%) MUST .

Итак, если ваш столбец ASI_EVENT_TIME имеет множество возможных значений, сначала проиндексируйте их все. Затем, как сказал @ypercube, попробуйте переставить их и посмотреть, что говорит вам EXPLAIN. Должно быть все вокруг.

Кроме того, вы хотите, чтобы вы взглянули на Индексирование SQL LIKE Filters . Хотя это не то, на что вам нужен ответ, но вы все равно узнаете, как индексирование работает под капотом.

* Edit: Обратитесь к ссылкам, приведенным ниже, в комментариях, чтобы узнать больше об индексации.

ответил Eye 18 MaramFri, 18 Mar 2011 04:34:09 +03002011-03-18T04:34:09+03:0004 2011, 04:34:09

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132