Не понимаю в чем тормоза (постраничный вывод)

[eurobax]

Есть таблица - сведения по заказам.

CREATE TABLE `x_ag_inforegister45` (
`id` char(32) COLLATE utf8_bin NOT NULL DEFAULT '',
`__version` int(10) unsigned DEFAULT NULL,
`owner` char(32) COLLATE utf8_bin NOT NULL,
`rowNumber` int(10) unsigned DEFAULT NULL,
`price` float(15,2) DEFAULT NULL,
`ware` char(32) COLLATE utf8_bin NOT NULL,
`priceType` char(32) COLLATE utf8_bin NOT NULL,
KEY `index45_1` (`id`),
KEY `index45_3` (`owner`),
KEY `index45_51` (`ware`),
KEY `index45_52` (`priceType`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

В таблице сейчас 22000 записей. Будет под миллион
Пугает вот что - сейчас ее просматривают в браузере с помощью запросов:

SELECT * FROM `x_ag_inforegister45` LIMIT 0,50 - выбираются первые 50 записей, время выполнения 7мс
SELECT * FROM `x_ag_inforegister45` LIMIT 20000,50 - выбираются 50 записей в хвосте таблицы, время 156мс

Где ошибка, и с чем это может быть связано?

 

[Vin-Diesel]

Не знаю

Начните с первичного ключа? Его у вас нет)

 

[С.]

SELECT * FROM `x_ag_inforegister45` LIMIT 0,50
SELECT * FROM `x_ag_inforegister45` LIMIT 20000,50

Вот так и выводите в неопределенном порядке?

 

[eurobax]

Попробовал сделать id как PRIMARY - еще хуже, 1.5 секунды тратится для хвоста (против 156мс)

 

[eurobax]

Вот так и выводите в неопределенном порядке?

Да, это без сортировки, типа брать записи в естественном порядке.
Привел только примеры запросов. На каждую страницу там просто свое смещение. Смущает что чем ближе к концу - тем тупее.

Будет поле сортировки - еще медленней формируется.

 

[Vin-Diesel]

EXPLAIN?

 

[eurobax]

Добавил индекс PRIMARY для id - вроде никак особо не повлияло

сам запрос (проверил заодно, задавал поля * или конкретно поле id - не особо разнится по времени выполнения)
SELECT * FROM `x_ag_inforegister45` ORDER BY id LIMIT 20000, 50 - 174мсек

EXPLAIN SELECT * FROM `x_ag_inforegister45` ORDER BY id LIMIT 20000, 50
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE x_ag_inforegister45 index NULL PRIMARY 96 NULL 20050

Profiling: (вот тут обнаружилось интересное - выделил жирным)
Status Time
starting 0.000033
Opening tables 0.000030
System lock 0.000002
Table lock 0.000003
init 0.000011
optimizing 0.000002
statistics 0.000007
preparing 0.000004
executing 0.000001
Sorting result 0.000003
Sending data 0.177728
end 0.000007
query end 0.000002
freeing items 0.000103
logging slow query 0.000001
cleaning up 0.000003

 

[Vin-Diesel]

Насколько помню это нормальное поведение. Т.е. будет просматривать все записи.
Если попробовать делать ограничения?
WHERE id > %offset%
или что-то в таком духе?

 

[eurobax]

Чтож.. ясно. Вот статью нашел по моему же вопросу:
http://myforce.ru/tyeoriya-i-praktika/optimizaciya-postranichnogo-vyvoda-v-mysql/

 

[Adelf]

Самое разумное там:

Нужно ли пользователю иметь возможность листать на последние страницы списка? Google не дает возможности просмотреть миллионную страницу, и никто не нервничает, ведь люди смотрят обычно только первые несколько страниц. Лимитируйте вывод до разумного предела.

Меня постоянно удивляет желание некоторых девелоперов давать ссылки на самые устаревшие новости(статьи, товары), которые никому не нужны

Есть люди, для которых они могут оказаться нужными, тогда можно завести раздел "Архив" и там показывать их либо в другом порядке, либо удобный поиск какой-нибудь ввести

 

[Фанат]

на хабре совсем недавно была статья (от капитана Очевидность) про то что старые статьи приводят не меньше, чем новьё.

но это если речь именно про статьи.

 

[Redjik]

не стоит еще забывать про СЕО, хотя если оставить ссылку такой же, просто исключить из поиска...

 

[Adelf]

Иван Redjik Матвеев
Про СЕО действительно не стоит забывать. Они бывают крайне обидчивы.
Но, наверняка, ты имел ввиду SEO