limit - тормоза, full table scan

kruglov

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

Breeze

goshogun
Команда форума
Партнер клуба
zip111
он не лучше хотя бы тем, что вероятность получить неверный набор данных гораздо выше + слежка за "дырками", что само по себе криво и убивает всю идею автоинкемента и уникальности напрочь.
 

berkut

Новичок
а ничё, что тема годичной давности? тут любят про дигерство.. zip111 а битвин не вариант, а гавно. если у меня именно в этом промежутке штук 50 записей удалены?
 

zip111

Новичок
Breeze
Конечно, может я чего-то недогоняю, но:
- как можно получить неверный набор данных, если мы явно указываем диапазон ИД при выводе?
- о каких дырках, к примеру, идет речь? Проверка входящих переменных? логичность переменных "старт-стоп"?
-автоинкремент то тут причем? база как использовала автоинкремент ИД при добавлении, так и будет использовать.

-~{}~ 23.04.08 14:52:

догнал

-~{}~ 23.04.08 14:54:

имхо, в любом случае, лучше сделать проверку входящих данных и целостности диапазона и получить результат в 0,02 сек, чем любыми другими костылями за 90 секунд
 

Ralph

Дикий столяр
zip111,кстати,в тексте Вашего запроса не видна " проверка целостности диапазона"...Вот если бы увидеть скорость выполнения выборки + проверки этого диапазона,тогда можно было бы и скорость сравнить,и увидеть,уложится ли он в 0,02 сек...
 

zip111

Новичок
А на самом деле, тема актуально до сих пор.
при 100 млн. записей, который нужно выводить постранично, тормоза дикие.
У кого нибуть есть дельные идеи как это победить?
 

zip111

Новичок
Я на дурака вроде не похож - фигня все эти идеи что есть в теме.
делая лимит, к примеру: 7777777, 10 - муська замолкает на 400 секунд, причем тестил ВСЕ предложенные варианты

-~{}~ 13.05.08 20:35:

вообще, все эти херни с джоинами и подзапроса до задници - тормозит то именно лимит, из-за скана всей таблицы.
 

Gas

может по одной?
zip111
не нужно делать limit 7777777,10;
эту конструкцию никак не ускорить, меняй подход вывода информации при таких объёмах.
 

zip111

Новичок
Ну допустим.
А что конкретно мне делать, когда мне необходимо вывести ВСЕ значения из базы с учетом WHERE и разбить их на страницы?

Какой тут еще может быть подход?
 

Gas

может по одной?
Какой тут еще может быть подход?
имхо, постраничная навигация по такому количеству данных безсмысленна, вот вывелись 10000 страниц и что с ними делать. Google количество страниц ограничивает 1000-ей, а мог бы показать ого-го сколько.

Например, нужно было сделать навигацию по действиям админов, всего записей несколько десяткой M. Можно тоже было тупо сделать постраничку и всё. Но сделал чтоб при выборе админа, показываются временные интервалы и количество действий в них (вменяемое количество), а уже зайдя в интервал - постраничная разбивка. Всё это решалось доп. таблицей со временными интервалами, количествами, id первой записи в диапазоне. Тут своя специфика - лог, данные только добавлялись.

Как лучше сделать тебе, я не знаю. Ты знаешь задачу, тебе решать. Но limit 7777777,10 это точно не вариант.
 

zip111

Новичок
вот вывелись 10000 страниц и что с ними делать
Пользователи точно использовать эту фичу будут крайне редко. Суть вывода этих данных у меня сейчас в том, что пользователь их ищет путем ввода ключевых слов. А постраничный вывод необходим, что бы информация индексировалась поисковыми машинами.

Кстати, мысль с использованием дополнительной таблицы, с ИД первой записи в диапазоне хорошая, но мне не подходит. Так как выборка осуществляется с определенным условием, и не все подпадает под это условие и выполнение этого условия время от времени появляется. (ну что-то вроде иногда выполняется, иногда - нет).
 

zerkms

TDD infected
Команда форума
А постраничный вывод необходим, что бы информация индексировалась поисковыми машинами.
у тебя страницы нумеруются в прямом порядке: свежие на 1, старые на последней? или наоборот? если в прямом - то смысла от индексации нет :)
 

HraKK

Мудак
Команда форума
zip111
Ага, лучше. Совсем как холодильник лучше ложки.
 
Сверху