Ама виж сега...

Във всяка СУБД живее едно животно наречено Оптимизатор. Дето се опитва да измисли най-добрия начин да ти изпълни заявките.


Представи си сега следния хипотетичен вариант. Не казвам, че точно така ще стане но ако помислиш ще видиш, че би било добре ако е така.

Пращаш

SELECT name FROM tbl LIMIT 5;

т.е. дай ми 5 имена от таз таблица ама понеже няма ORDER BY значи Кои Да Е 5 имена. Не случайни а по усмотрение на сървъра.

Обаче в този момент сървъра се усеща, че някой друг преди теб е поискал 10 имена от тази таблица примерно със

SELECT name FROM tbl ORDER BY status LIMIT 10;

И тези 10 имена все още седят в някой буфер в паметта.
И сървъра си казва - Я да взема аз 5 имена от тоз буфер и да не ровя таблицата по диска. От паметта винаги е по-бързо, пък той Dakota не се вълнува от подредбата щом не е казал ORDER BY

И ти изведнъж получаваш 5 имена съвсем произволно подредени по статус.

След 5 минути изпълняваш същата заявка и понеже резултатът още е буфериран някъде получаваш точно същите 5 имена в точно същия ред.

Обаче сле 2 часа сървъра ти връща други 5 имена защото примерно въпросните буфери вече с пълни с нещо друго и той дръпва първите 5 имена от таблицата на диска които обаче са подредени по нещо друго.

Ето това имам предвид като казвам, че реда не е случаен. Т.е. не е гарантирано случаен.

Може 1000 пъти да получиш точно една и съща подредба или всеки път да е различна.

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

Ако сървъра беше длъжен да дава редовете винаги в един и същи ред в горния хипотетичен пример няваше да може да използва буфер в паметта ами задължително всеки път трябва да рови по диска.

Съдържаниет е скрито
Влезте за да го видите