|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Доброго времени суток, Коллеги!
Поделитесь соображениями по сабжу плиз.
Есть таблица, содержащая измерения чего либо за единицу времени (в ней 10000 записей).
mysql> explain SELECT t, (SELECT `d` FROM `e10000` `in` where `in`.t < `out`.`t` order by t desc limit 1 ) prev, d FROM e10000 `out` ORDER BY t; +----+--------------------+-------+------+---------------+------+---------+------+-------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+-------+------+---------------+------+---------+------+-------+-----------------------------+ | 1 | PRIMARY | out | ALL | NULL | NULL | NULL | NULL | 10000 | Using filesort | | 2 | DEPENDENT SUBQUERY | in | ALL | NULL | NULL | NULL | NULL | 10000 | Using where; Using filesort | +----+--------------------+-------+------+---------------+------+---------+------+-------+-----------------------------+ 2 rows in set (0.00 sec)
и сам запрос отрабатывает 11 секунд.
Если же (и казалось бы логика это сильно подсказывает - добавить ключик на поле t), то explain становится
mysql> explain SELECT t, (SELECT `d` FROM `e10000` `in` where `in`.t < `out`.`t` order by t desc limit 1 ) prev, d FROM e10000 `out` ORDER BY t; +----+--------------------+-------+-------+---------------+------+---------+------+-------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+-------+-------+---------------+------+---------+------+-------+----------------+ | 1 | PRIMARY | out | ALL | NULL | NULL | NULL | NULL | 10000 | Using filesort | | 2 | DEPENDENT SUBQUERY | in | index | t | t | 4 | NULL | 1 | Using where | +----+--------------------+-------+-------+---------------+------+---------+------+-------+----------------+
а сам запрос отрабатывает 59 секунд.
За счет чего наличие индекса настолько тормозит выполнение запроса? Ведь казалось бы наоборот - если без индекса, то MySQL переберет суммарно 10000 * 10000 строк, а с индексом-то пошустрее должно пройти.
Профилирование:
В первом запросе sending data как было очень быстрым, так таким и оставалось, а во втором сначала было гораздо медленнее, но постепенно уменьшалось.
В первом запросе Sorting data постепенно росло, во втором как было очень маленьким, так и оставалось до конца. Прикладываю результаты профилированиия.
Отредактированно deadka (20.11.2011 13:04:54)
Неактивен
Наверное это неэффективность LIMIT в подзапросе, который реально не ограничивает число выбираемых строк. Проверь в MariaDB - там обещали оптимизировать работу подзапросов.
P.S. EXPLAIN приведен два раза один и тот же (с индексом).
Неактивен
Да, с подзапросами беда какая-то ). Но даже если так (в смысле что limit реально не ограничивает количество строк, то есть нету оптимизации в этом смысле) - почему так медленно выполняется запрос с индексом? Профилирование показало, что самый длительный процесс - sending data, оно гораздо медленнее, чем sorting data в безиндексном варианте, почему так?
P.S. Поправил explain
Неактивен
Наверное sending data просто ждет чего-то и само не является причиной торможения. Почему с индексом медленнее, сказаь трудно.
Неактивен
Спасибо. Надо правда что пощупать на MariaDB. В то же время как-то абыдна! что ли. Не дружит MySQL c подзапросами, словом...
Неактивен
deadka, А разве с переменными не быстрее будет ?
Неактивен
Конечно быстрее 
. Да и на любом процедурном языке получилось бы быстрее. Но здесь хотелось сравнить именно в рамках реляционной модели.
Неактивен
Страниц: 1
