Базы данных |
БГУИР, ПОИТ |
|
|
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`
Предварительные результаты:
|
|
До правки конфигурации |
После правки |
||||||||
|
|
|
|
|
|
|
конфигурации |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SELECT |
SMALL |
|
BIG |
SELECT |
SMALL |
|
BIG |
||
|
|
|
|
|
|
|
|
|
|
|
|
1000 |
MIN |
0.00999 |
0.00997 |
0.00433 |
|
0.00973 |
0.00995 |
0.00434 |
|
||
записей |
|
|
|
|
|
|
|
|
|
|
|
MAX |
0.10967 |
0.05353 |
0.02233 |
|
0.11025 |
0.05321 |
0.02242 |
|
|||
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
AVG |
0.01142 |
0.01129 |
0.00496 |
|
0.01023 |
0.01086 |
0.00455 |
|
||
|
|
|
|
|
|
|
|
|
|
|
|
1000000 |
MIN |
30.25444 |
29.37332 |
|
163.7262 |
|
30.66679 |
30.27623 |
|
10.0718 |
|
|
|
|
|
||||||||
записей |
|
|
|
|
|
|
|
|
|
|
|
MAX |
60.28489 |
37.37515 |
|
177.7415 |
|
53.21383 |
41.92533 |
|
14.16798 |
|
|
|
|
|
|
||||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
||
|
AVG |
35.36835 |
33.18135 |
|
169.2353 |
|
35.93486 |
33.30988 |
|
10.81355 |
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
Стр: 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