Форум MySQL

Допусти есть простая таблица типа:

CREATE TABLE IF NOT EXISTS `test4` (   `id` int(4) NOT NULL,   PRIMARY KEY  (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

И мы в нее вносим данные в таком порядке:

INSERT INTO `test4` valuse(1000); INSERT INTO `test4` valuse(12); INSERT INTO `test4` valuse(4); INSERT INTO `test4` valuse(10000);

При запросе вида

select * from test4 limit 1,10;

мы получим ответ вида:

4 12 1000 10000

Тоесть автоматически идет сорторовка по id полю.

Вопрос: Как нужно сделать или как подругому составить таблицу что бы при таком же запросе:

select * from test4 limit 1,10;

Выдавалась информация по порядку записи?(без дополнительной сортировки по другому полю) , тоесть вот такая:

1000 12 4 10000

>И мы в нее вносим данные в таком порядке:
>INSERT INTO `test4` valuse(1000);
>INSERT INTO `test4` valuse(12);
>INSERT INTO `test4` valuse(4);
>INSERT INTO `test4` valuse(10000);

Вносим может и в порядке, а данные в таблице лежат внавал.

>При запросе вида
>

select * from test4 limit 1,10;

>
>мы получим ответ вида:
>4
>12
>1000
>10000

Не гарантировано ничем.
Более того запрос с LIMIT и без ORDER BY не несет смысла, поскольку неоднозначен.

>Тоесть автоматически идет сорторовка по id полю.

Нет. Не идет.

>>И мы в нее вносим данные в таком порядке:
>>INSERT INTO `test4` valuse(1000);
>>INSERT INTO `test4` valuse(12);
>>INSERT INTO `test4` valuse(4);
>>INSERT INTO `test4` valuse(10000);
>
>Вносим может и в порядке, а данные в таблице лежат внавал.

Как раз таки мы их и вносим в навал, вносим то не по порядку .

>>При запросе вида
>>

select * from test4 limit 1,10;

>>
>>мы получим ответ вида:
>>4
>>12
>>1000
>>10000
>
>Не гарантировано ничем.

Гарантировано , проверял и не раз .

>Более того запрос с LIMIT и без ORDER BY не несет смысла, поскольку неоднозначен.

неважно писать select * from test4 limit 1,10; или просто select * from test4; порядок вывода будет 1 и тот же.

>>Тоесть автоматически идет сорторовка по id полю.
>
>Нет. Не идет.

Как раз таки идет.


Я вношу данные в таблицу в "навал" как вы выразились, такую же и сортировку в навал я хочу получить вот и все.

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

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

Можно начать с малого если вы по другому не можете обьеснить.

Порядок записи в таблицу произвольный по id(не упорядоченый(5,100,2,234,2999,1)).

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

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

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

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

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

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

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

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

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

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

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


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

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

>По поводу скорости работы 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 раз быстрея.
Тут без вопросов.

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

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

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

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

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

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

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

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

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

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