Форум MySQL

Безусловно. Я, как пример, показал. Реально нужны будут методики посложнее.

Да, такой запрос и в правду практически летает, только одно но , то что не учитываеться порядок строк, тоесть он будет прекрасно все выполнять где id идут по порядку , но в таблице где разница номеров id может быть на 10 а то и 100 раз будет выдовать не то что нужно.
А так работает шустро.

Смею предположить что о существовании книг по MySQL Вы и понятия не имеете. Оттого и пытаетесь что-то нагородить, то подбрасывая монету вверх, то гадая на кофейной гуще или куриной лапке. Поймите нужно сначала изучить все* возможности БД, что бы потом применять оптимальную конструкцию в соответствии с поставленной задачей. Оставте на время практику и уделите это время теории.
_____
* - ну хотя бы половину для начала

По первичному ключу с ограничением на его значения.
Запрос WHERE id BETWEEN 10000 AND 10009 ORDER BY id (где id - primary key) всяко будет выполнен быстрее

>Я же имел в виду другое.
>Когда Вы пишете LIMIT 1000, 10 - наивно предполагать, что первые 1000 строк перед десятком нужных запрошены не будут.
>Будут. И время на них затрачено будет.

Ну это я знаю, Limit 100,10 бывтрея чем limit 1000,10;

Но другова же способа нет вытащить именно те 10 которые идут после 1000.

Стандартная сортировка таблицы со страницами, подругому же никак?

Вы сравниваете запрос с порядком по вычисляемому значению (для которого в принципе индексом не воспользоваться, то есть единственный выход - выполнять сортировку) и запрос без порядка. И чему то удивляетесь.

Я же имел в виду другое.
Когда Вы пишете LIMIT 1000, 10 - наивно предполагать, что первые 1000 строк перед десятком нужных запрошены не будут.
Будут. И время на них затрачено будет.
Просто они не будут выданы в поток результата.

>По поводу скорости работы limit x,y; полагаю, Вы тоже сильно заблуждаетесь.
>Но в чем-либо убеждать желание отпало напрочь.

Понимаете просто я order by то делаю не по id и тоже с limit x,y, тоесть order by one*bal/golos limit x,y; , так что просто limit x,y получаеться выкидывает сортировки order by, что уж точно ускоряет работу.

Я смотрел по своим таблицам
select * from table order by one*bal/golos limit 1000,10; выполняет за 0.1 сек.
В то время как select * from table limit 1000,10; выполняет за 0.005 сек, что в 20 раз быстрея.
Тут без вопросов.

>Но что меня удивило это то что что бы я не делал с этим полем(оставлял пустым, делал update) на порядок вывода это не повлияло, хотя вы писали что должно было бы чтото измениться.


Я писал не это.
Я писал что у Вас мог измениться порядок.
И что как следствие Вы не должны принимать любые постулаты о порядке в расчет.

По поводу скорости работы limit x,y; полагаю, Вы тоже сильно заблуждаетесь.
Но в чем-либо убеждать желание отпало напрочь.

>Пока табличное пространство пустое, записи ложатся в последовательно распределяемые экстенты табличного пространства.
>А при заполнении прореженной таблицы характер изменится непредсказуемо.

Хм, действительно создав таблицу с дополнительным поля типа text я получил то что хотел, вывод в том порядке в котором я записывал эти данные.
Но что меня удивило это то что что бы я не делал с этим полем(оставлял пустым, делал update) на порядок вывода это не повлияло, хотя вы писали что должно было бы чтото измениться.
Ну неважно уже есть неплохие подвижки.

Просто к чему это все....У меня есть таблицы где информация постоянно обновляеться и сортируеться по нескольким полям.
Я подумал а нафига это делать каждый раз с таблицей на 20к строк.
Непроще ли сделать копию таблицы заняся в нее данные в порядки нужной мне сортировки первой таблицы и потом быстренько получать результаты элементарным запросом вида select * from table limit x,y; который работает в 10ки раз быстрея чем order by.

>Но при стандартом запросе без использования order by выдает записи упорядочено.

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

Но суть-то в том, что Вас как прикладного программиста (а не программиста Систем Управления Базами Данных) весь этот нижний уровень (табличное пространство, алгоритмы его распределения и т.п.) трогать не должен - Методика работы с СУ реляционной БД (коей является любой SQL сервер) абстрагируется как от порядка строк в таблице, так и от порядка столбцов.
Любая логика должна строиться на отношениях (то есть на соответствии в строке некоего значения в одном поле значению в другом поле) .
Причем если шибко хочется иметь порядковый номер строки, то такое поле нужно задать и заполнить явным образом.

Так что проще сказать себе - порядка в таблице нет. Строки лежат внавал.

Проистекает это из теории реляционных баз данных.

>Почему так?
Вот примерно поэтому.