ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Анализ плана выполнения запроса
4 сообщений из 4, страница 1 из 1
Анализ плана выполнения запроса
    #38418854
structorias
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
structorias
Гость
Сравнительно недавно занялся изучением планов выполнения запросов и еще не совсем освоился. Надеюсь на вашу помощь.
Раньше я думал, что при составлении запроса нужно следить, чтобы mysql просматривал как можно меньше строк. Но сегодня столкнулся с обратным результатом. Может, кто из опытных, подскажет в чем дело?
Возможно из-за того, что таблицы маленькие их полное сканирование работает быстрее, чем прыжки по индексам?
Кеши для чистоты эксперимента отключены.

Таблицы (лишние поля опущены):
Код: plsql
1.
2.
3.
4.
5.
6.
CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `reg_date` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `key_reg_date` (`reg_date`)
) ENGINE=InnoDB


Код: plsql
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE `user_data` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_user_data_users` (`user_id`),
  CONSTRAINT `fk_katalog_sprache` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=351 DEFAULT CHARSET=utf8



А вот три равнозначных запроса и планы их выполнения:


1. Используется подзапрос вместе с IN, тип соединения ALL (сканирует все 53 строки) выполняется за 0.02s.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT * 
    FROM user_data 
    WHERE user_id IN 
           (
             SELECT id 
                FROM users 
                WHERE reg_date > '2013-07-03'id,select_type,table,type,possible_keys,key,key_len,ref,rows,Extra    
          )



idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra 1PRIMARYuser_dataALL53Using where2DEPENDENT SUBQUERYusersunique_subqueryPRIMARY.id.key_reg_datePRIMARY4func1Using where



2. Подзапрос в JOIN, работает тоже быстро 0.02s. Если я не ошибаюсь получается, что сканирует (17+17)*17 строк. Поправьте, пожалуйста, если ошибаюсь.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT * 
       FROM user_data 
            JOIN (
                 SELECT id 
                     FROM users 
                     WHERE reg_date > '2013-07-03'
                     ) AS a 
            ON user_data.user_id=a.id


idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra 1PRIMARY<derived2>ALL171PRIMARYuser_datarefuser_id.fk_user_data_usersuser_id4a.id12DERIVEDusersrangekey_reg_datekey_reg_date817Using where; Using index



3. Обычный JOIN. Простое соединение по внешнему ключу. Посравнению с предыдущими очень медленный: 0.69s. Сканирует 17+17 строк. (т.е. меньше всего). Опять же, поправьте, если ошибаюсь.

Код: plsql
1.
2.
3.
4.
     SELECT user_data.* 
           FROM user_data 
               JOIN users ON user_data.user_id=users.id 
               WHERE reg_date > '2013-07-03'



idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra 1SIMPLEusersrangePRIMARY.id.key_reg_datekey_reg_date817Using where; Using index1SIMPLEuser_datarefuser_id.fk_user_data_usersuser_id4webosx_master.users.id1

Т.е. в итоге самый медленный запрос - третий, хотя, как мне казалось, он должен работать быстрее подзапросов. Просветите, кому не жалко, почему так?
...
Рейтинг: 0 / 0
07.10.2013, 13:43:25
| Ответить | Цитировать | Написать  
Анализ плана выполнения запроса
    #38418858
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
structorias,

Такие эксперименты всегда нужно сопровождать точной версией MySQL.
...
Рейтинг: 0 / 0
07.10.2013, 13:46:16
| Ответить | Цитировать | Написать  
Анализ плана выполнения запроса
    #38418859
structorias
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
structorias
Гость
Не нашел кнопки "редактировать сообщение". В первый запрос случайно попал заголовок плана (id,select_type,table,type,possible_keys,key,key_len,ref,rows,Extra )

В столбце possible_keys я запятые заменил точками, т.к. они не экранировались
...
Рейтинг: 0 / 0
07.10.2013, 13:46:34
| Ответить | Цитировать | Написать  
Анализ плана выполнения запроса
    #38418862
structorias
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
structorias
Гость
miksoft, версия 5.5
...
Рейтинг: 0 / 0
07.10.2013, 13:48:33
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Анализ плана выполнения запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&gotonew=1&tid=1835933]:
 0ms
get settings:
 10ms
get forum list:
 19ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 55ms
get topic data:
 9ms
get first new msg:
 5ms
get forum data:
 2ms
get page messages:
 39ms
get tp. blocked users:
 1ms
others: 202ms
total:  350ms
созд. / загр.: 350ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]