6.1.4. SELECT: [STRAIGHT_JOIN]

Использование ключевого слова STRAIGHT_JOIN позволяет указать оптимизатору запросов, что в JOINзапросе таблицы надо обрабатывать в том порядке, в котором они перечислены в списке таблиц в SELECT.

В таком запросе оптимизатор теоретически может сначала прочитать вторую таблицу:

SELECT * FROM `firstT` JOIN `secondT`

ON `firstT`.`id` = `secondT`.`id`

А в таком запросе всегда сначала будет прочитана первая таблица:

SELECT * FROM `firstT` STRAIGHT_JOIN `secondT`

ON `firstT`.`id` = `secondT`.`id`

В руководстве сказано…

Использование STRAIGHT_JOIN не даёт эффекта с таблицами, которые оптимизатор считает таблицами вида «const» или «system». В результате обращения к таким таблицам получается один ряд, данные извлекаются на стадии оптимизации запроса, а ссылки на поля такой таблицы заменяются конкретными значениями перед выполнением JOIN. НО! Это исключение не актуально для «NULL-

стороны» OUTER JOIN («правой» в LEFT JOIN или «левой» в RIGHT JOIN).

Таблица, полученная в результате такого запроса, будет считаться таблицей типа const (если вы вдруг забыли, напоминаем: запросы в SQL возвращают таблицы ):

SELECT * FROM `tbl_name` WHERE `primary_key`=1;

Стр: 140/248

6.1.5. SELECT: [SQL_SMALL_RESULT] [SQL_BIG_RESULT]

Используется с GROUP BY и / или DISTINCT, чтобы «подсказать» MySQL, что в результирующей выборке будет мало или много или записей.

В руководстве сказано…

Вслучае SQL_BIG_RESULT будет использована временная таблица на диске и временная таблица с ключами на результатах GROUP BY.

Вслучае SQL_SMALL_RESULT MySQL будет выполнять операции с временными таблицами в оперативной памяти вместо «дисковой сортировки».

Проведём небольшое исследование (на самом деле, это «небольшое» ис-

следование вылилось в почти месяц тестов). Используем таблицу:

CREATE TABLE IF NOT EXISTS `t_small_big`

(

`id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `money` int(11) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Добавим в таблицу данные и выполним запросы:

SELECT `name`, SUM(`money`)

FROM `t_small_big` GROUP BY `name`

SELECT SQL_SMALL_RESULT `name`, SUM(`money`)

FROM `t_small_big` GROUP BY `name`

SELECT SQL_BIG_RESULT `name`, SUM(`money`)

FROM `t_small_big` GROUP BY `name`

Предварительные результаты:

Стр: 141/248

Правка конфигурации включала в себя следующие изменения в my.ini (на мысли о которых навело изучение готового варианта конфигурации my-innodb- heavy-4G.ini):

# 2  20 innodb_additional_mem_pool_size=20M

# 1  8 innodb_log_buffer_size=8M

# 8  348 innodb_buffer_pool_size=348M

После изучения предварительных результатов было решено провести более масштабное исследование.

Сначала тест был проведён при условии, что идентификаторы пользователей, добавляемые к имени (слову ‘user’) генерировались в диапазоне 1-10000000, тест проводился на объёме данных от 1000 до 1000000 записей с шагом в 1000. Время выполнения запросов приведено в секундах.

Графики в одном масштабе

Стр: 142/248

Затем тест был проведён при условии, что идентификаторы пользователей, добавляемые к имени (слову ‘user’) генерировались в диапазоне 1-10, тест проводился на объёме данных от 1000 до 1000000 записей с шагом в 1000. Время выполнения запросов приведено в секундах.

Графики в одном масштабе

И «финальный штрих».

Идентификаторы пользователей: 1-10000000. Записей: 1 миллиард.

Конфигурация: изменена (см. ранее – как). Время выполнения запроса («BIG»): 9:29:58.34

Идентификаторы пользователей: 1-10. Записей: 1 миллиард.

Конфигурация: изменена (см. ранее – как). Время выполнения запроса («BIG»): 0:56:3.81

Стр: 143/248