9.3.8.2. Оптимизатор запросов

Оптимизатор запросов преследует несколько целей, но главная цель – применять индексы везде, где это возможно, и использовать наиболее строгий индекс для того, чтобы максимально минимизировать количество просматриваемых строк. Чем быстрее оптимизатор исключает строки из рассмотрения, тем быстрее будут найдены строки, удовлетворяющие условию. Запросы будут обрабатываться быстрее, если более строгие тесты будут отработаны в первую очередь.

Положим, запрос тестирует два проиндексированных столбца:

WHERE col1=’одно значение’ AND col2=‘другое значение’

Положим также, что тест по столбцу col1 дал 900 строк, а тест по столбцу col2 дал 300 строк. А объединение дало 30 строк. Если протестировать сначала col1, надо просмотреть 900 строк, а затем найти из них 30 строк, которые будут совпадать со значениями в столбце col2. Это составит 870 ошибочных тестов. Если проверку начать со столбца col2, предстоит проверить 300 строк, чтобы найти 30, которые будут совпадать со столбцом col1. Это всего 270 ошибочных тестов. Очевидно, второй вариант требует меньше вычислений и операций ввода/вывода.

Кроме того, можно упростить работу оптимизатора, придерживаясь следующих правил:

• Сравнивать столбцы, имеющие одинаковый тип;

• Желательно выбирать для сравнений независимые проиндексированные столбцы. Нельзя индексировать столбцы, которые используются в качестве параметра функции или операнда арифметического выражения. Это вынудит СУБД MySQL вычислять выражение для каждой строки таблицы. Необходимо написать запрос так, чтобы он обращался к проиндексированному столбцу непосредственно;

• Не следует использовать образцы в начале шаблона LIKE. Это приводит к необходимости перебора всех строк таблицы. Так, символ ‘%’ в начале строки заставляет перебирать все строки;

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

9.3.8.3. Выбор типа столбцов и эффективность запросов

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

• Отдавайте предпочтение столбцам фиксированной длины. Это особенно полезно для таблиц, которые модифицируются часто. Например, тип CHAR предпочтительнее VARCHAR. Такая таблица занимает больше места на диске, но строки фиксированной длины обрабатываются быстрее, чем строки переменной длины.

• Не пользуйтесь длинными столбцами, когда вполне достаточно коротких. Не делайте столбцы типа CHAR необоснованно длинными. Используйте наиболее короткие целые типы там, где это возможно (SMALLINT, MEDIUMINT, INT, BIGINT).

• Объявляйте столбцы NOT NULL. Это обеспечит быструю обработку данных, уменьшит потребление памяти. Скорость обработки данных увеличится, поскольку при этом отпадает необходимость проверять столбцы на пустые значения.

• По возможности пользуйтесь столбцами типа ENUM. Строки, имеющие ограниченный набор строго определенных значений, можно объявлять с типом ENUM. Эти значения обрабатываются очень быстро, так как они имеют числовое внутреннее представление.

• Пользуйтесь функцией PROCEDURE ANALYSE(…). Эта процедура дает предложения по оптимальным типам всех столбцов таблицы.

Пример использования функции:

SELECT * FROM tbl_name PROCEDURE ANALYSE()