Меню
Что нового?

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

  • Автор темы Автор темы berkut
  • Дата начала Дата начала
Вот, а я пытаюсь сказать, что у него проблема с логикой алгоритма.
 
zip111
он не лучше хотя бы тем, что вероятность получить неверный набор данных гораздо выше + слежка за "дырками", что само по себе криво и убивает всю идею автоинкемента и уникальности напрочь.
 
а ничё, что тема годичной давности? тут любят про дигерство.. zip111 а битвин не вариант, а гавно. если у меня именно в этом промежутке штук 50 записей удалены?
 
Breeze
Конечно, может я чего-то недогоняю, но:
- как можно получить неверный набор данных, если мы явно указываем диапазон ИД при выводе?
- о каких дырках, к примеру, идет речь? Проверка входящих переменных? логичность переменных "старт-стоп"?
-автоинкремент то тут причем? база как использовала автоинкремент ИД при добавлении, так и будет использовать.

-~{}~ 23.04.08 14:52:

догнал

-~{}~ 23.04.08 14:54:

имхо, в любом случае, лучше сделать проверку входящих данных и целостности диапазона и получить результат в 0,02 сек, чем любыми другими костылями за 90 секунд
 
zip111,кстати,в тексте Вашего запроса не видна " проверка целостности диапазона"...Вот если бы увидеть скорость выполнения выборки + проверки этого диапазона,тогда можно было бы и скорость сравнить,и увидеть,уложится ли он в 0,02 сек...
 
А на самом деле, тема актуально до сих пор.
при 100 млн. записей, который нужно выводить постранично, тормоза дикие.
У кого нибуть есть дельные идеи как это победить?
 
Я на дурака вроде не похож - фигня все эти идеи что есть в теме.
делая лимит, к примеру: 7777777, 10 - муська замолкает на 400 секунд, причем тестил ВСЕ предложенные варианты

-~{}~ 13.05.08 20:35:

вообще, все эти херни с джоинами и подзапроса до задници - тормозит то именно лимит, из-за скана всей таблицы.
 
zip111
не нужно делать limit 7777777,10;
эту конструкцию никак не ускорить, меняй подход вывода информации при таких объёмах.
 
Ну допустим.
А что конкретно мне делать, когда мне необходимо вывести ВСЕ значения из базы с учетом WHERE и разбить их на страницы?

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

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

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

Кстати, мысль с использованием дополнительной таблицы, с ИД первой записи в диапазоне хорошая, но мне не подходит. Так как выборка осуществляется с определенным условием, и не все подпадает под это условие и выполнение этого условия время от времени появляется. (ну что-то вроде иногда выполняется, иногда - нет).
 
А постраничный вывод необходим, что бы информация индексировалась поисковыми машинами.
Нажмите для раскрытия...
у тебя страницы нумеруются в прямом порядке: свежие на 1, старые на последней? или наоборот? если в прямом - то смысла от индексации нет :-)
 
zip111
Ага, лучше. Совсем как холодильник лучше ложки.
 
Войдите или зарегистрируйтесь для ответа.
Сверху