Сортировка по PRIMARY

[akxxiv]

Имеется таблица с большим количеством записей:

CREATE TABLE IF NOT EXISTS `sp_files` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `module` varchar(20) NOT NULL DEFAULT '',
  `m_id` int(10) unsigned NOT NULL DEFAULT '0',
  `title` varchar(100) NOT NULL DEFAULT '',
  `f_name` varchar(40) NOT NULL DEFAULT '',
  `f_ext` varchar(10) NOT NULL DEFAULT '',
  `user` varchar(40) NOT NULL,
  `date_created` date NOT NULL COMMENT 'Дата создания скана',
  `who_scanned` varchar(100) NOT NULL COMMENT 'Кто сканировал',
  PRIMARY KEY (`id`),
  KEY `module_mid` (`module`,`m_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=252600 ;

Делаю запрос:

SELECT * FROM sp_files ORDER BY id DESC LIMIT 0, 100

Время выборки - 11сек. Убираю ORDER BY id DESC выбирает мгновено. Почему так тормозит выборка по первичному ключу.

Эксплэйн выдает следующее:

id - 1
select_type - SIMPLE
table - sp_files
type - index
possible_keys - NULL
key - PRIMARY
key_len - 4
ref - NULL
rows - 2300
Extra -

Как поправить? И почему так?

 

[флоппик]

SELECT * FROM sp_files ORDER BY id DESC LIMIT 0, 100

Время выборки - 11сек. Убираю ORDER BY id DESC выбирает мгновено. Почему так тормозит выборка по первичному ключу.
И почему так?

Потому что это разные запросы, которые выбирают разные данные, которые могут иногда совпадать. А иногда - нет.
В случае с ORDER BY ты получишь сортированные данные. Без ORDER BY — случайные первые прочитанные, которые скорее всего будут лежать в порядке, который примерно совпадает с порядком вставки записей.

 

[c0dex]

Простите, а с большим количеством, это сколько?

 

[akxxiv]

Простите, а с большим количеством, это сколько?

252600 записей.

 

[akxxiv]

Потому что это разные запросы, которые выбирают разные данные, которые могут иногда совпадать. А иногда - нет.
В случае с ORDER BY ты получишь сортированные данные. Без ORDER BY — случайные первые прочитанные, которые скорее всего будут лежать в порядке, который примерно совпадает с порядком вставки записей.

Это - то понятно. Мне не понятно то, почему он если по PRIMARY ключу ищет, то все здорово, находит мгновенно, а вот отсортировать по нему так же быстро не может. Ведь индек-то тоже по порядку лежит. Взял последние 100 записей из индекса и вывел соответствующие записи. Разве нет?

 

[флоппик]

Это - то понятно. Мне не понятно то, почему он если по PRIMARY ключу ищет, то все здорово, находит мгновенно, а вот отсортировать по нему так же быстро не может. Ведь индек-то тоже по порядку лежит. Взял последние 100 записей из индекса и вывел соответствующие записи. Разве нет?

А где ты что-то ищешь по первичному ключу в твоем примере?

 

[HORO]

Записей не так много, чтобы 11 сек выполняться... Может в реальности запрос "немного" другой? )

 

[c0dex]

@akxxiv, у меня сейчас табличка с несколькими десятками миллионов записей, там подобная сортировка прокатывае за 0,085с+-. Ты что-то не договариваешь...

Сортировка для первичного ключа работает по особому, она должна быть быстрой. Вот сортировки по иным идексам могут приводить к filesort

 

[akxxiv]

А где ты что-то ищешь по первичному ключу в твоем примере?

В примере я не ищу не чего. Я просто проверял - делал выборку по ID.

 

[akxxiv]

@akxxiv, у меня сейчас табличка с несколькими десятками миллионов записей, там подобная сортировка прокатывае за 0,085с+-. Ты что-то не договариваешь...

Сортировка для первичного ключа работает по особому, она должна быть быстрой. Вот сортировки по иным идексам могут приводить к filesort

Вот я тоже думаю, что должна быть быстрой, однако че-то не так. Ладно, потыркаюсь, глядишь пойму в чем прикол.

 

[MiksIr]

ASC дает такую же скорость?

 

[c0dex]

Чего-то мне кажется у него там настройки под сортировочный буфер и иже с ним не очень

 

[MiksIr]

А причем тут буфер то для первичного ключа. Просто я чота не вспомню, там строки только вперед линкуются или в оба направления. Позор, не возьмут меня в баду

 

[MiksIr]

АААААаааа.... ешкин конь... MyISAM? Really?

 

[Breeze]

вообще при LIMIT 0, 100 в explain не должно быть rows 2300