сортиране

Имам най прост SELECT * FROM tbl1

tbl1 има primary key (id), което е int и autoincrement
Всичко е принципно и максимално просто

Въпрос:
В какъв ред ще върне записите този селект щом нямам ORDER BY

по случаен ред според салле ;-)
според мои наблюдения - по физическо разположение на записите във файла. ако само вкарваш - от началото поред на въвеждане, ако и триеш .... баба знае

root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy

По физическо разположение на записите във файла, защото като изтриеш запис и после инсъртнеш, новия запис го слага на мястото на изтрития.
Това е така за да се пести място във файла на таблицата пък и по-бързо става.
Затова колкото повече delete и insert заявки правиш, толкова физическият ред се омешва.
Извод: винаги select трябва да има order by ...

Дойде ми акъла в главата :-P

Сървъра си кешира заявките и подерждането на резултатите може да зависи от предходните заявки - май салле го беше казал :)
Поправете ме ако бъркам.
Ама какво значение има реда без ордер (готина тафталогия:)?

Когато не указваш ORDER BY сървърът е в правото си да ти върне редовете в произволен ред по свое усмотрение. Както той прецени за най-добре.

Нарочно подчертавам произволен за да го разгранича от случаен.

Причината е проста - теорията дефинира таблиците като множества следователно те нямат вътрешна подредба.

Да ограничиш правото на сървъра да избира реда в който връща редовете би означавало да се съкратят изключително много възможностите за оптимизация.

Без простичкия факт, че всеки сървърите за Бази Данни има правото да съхранява, извлича и обработва данните в произволен ред който прецени за оптимален цялата технология на Базите Данни би била много по ограничена и с много по-малко възможности.


Помисли например за един всеобщ проблем при съхраняването на данни (не само при БД) - фрагментацията.

Когато се трият някакви данни обикновено остават дупки. Ако тези дупки не се "рециклират" по някакъв начин се губи пространство. Запълването на дупките винаги означава по някакъв начин да се преподредят данните (дали ще се "дефрагментират" или ще се вмъкват нови данни на мястото на дупките няма голямо значение)

Ето как изискването за вътрешна подредба пречи на оптимизацията на заеманото място.

NikB вече ти подсказа как може пречи на оптимизацията на бързодействие.

Един по-сложен случай (и още по-огромна пречка) е при системите за разпределена обработка когато данните са разхвърляни на много сървъри.

Изобщо никога, ама никога не разчитай, че можеш да предскажеш в какъв ред ще се върнат редовете при заявка без ORDER BY

salle.online.bg/sig