MySQL -> ORDER BY

Имам 2 таблици - table_x и table_y.

Правя им join и ги сортирам:

SELECT

  x.id,

  y.name

FROM

  table_y y INNER JOIN table_x x

ON

  x.y_id=y.id

ORDER BY

  2

Интересува ме как MySQL сортира резултата в случай, че y.name е едно и също?

Everything louder than everything else...

На времето брах ядове.
Дали не можеш да минеш с обикновен селект?

Както казва salle ЗАВИСИ
направи го :
SELECT
x.id,
y.name
FROM
table_y y INNER JOIN table_x x
ON
x.y_id=y.id
ORDER BY
2,1 както си се изразил :-))

Е тук нищо няма:[линк]

Случайно естествено. Как иначе?

salle.online.bg/sig

Как така случайно?...Точно от това се страхувах. Не би ли трябвало една и съща заявка при наличие на едни и същи данни винаги да изкарва едно и също нещо?!...Да взима default сортирането на таблиците, които join-вам една след друга и така да сортира...но само не и random!

Everything louder than everything else...

Не би ли трябвало една и съща заявка при наличие на едни и същи данни винаги да изкарва едно и също нещо?!

Цъ . (това даже и аз го знам )

Все пак защо просто не сортираш?

Второ (това просто си питам) - има ли някаква реална полза от тоя JOIN в момента - искам да кажа с нещо по-добър ли е от още една клауза в WHERE?

Dakota
Това май вече сме ти го обяснявали ...

"Не би ли трябвало една и съща заявка при наличие на едни и същи данни винаги да изкарва едно и също нещо?!"

Проблема ти е в разбирането на НЕЩОТО.

Та значи според релационния модел таблиците са множества.

А според теорията на множествата (x, y, z) и (z, x, y) е едно и също множество - реда няма значение.

Точно затова когато НЕ СИ указал ORDER BY сървъра е в правото си да ти върне резултата в произволен ред. Забележи, че дори не е случаен а е произволен.

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

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

salle.online.bg/sig

Не си спомням, да сте ми го обяснявали.

Мерси за разяснението, все пак.

По тази логика, обаче, излиза, че дори да нямам JOIN, то пак MySQL би трябвало да ми връща нещата в произволен ред, но в действителност не е така...или пак бъркам?!

Everything louder than everything else...

1. Не ги сортирах, защото не знаех за това поведение на MySQL. Използвам един Paging/Sorting class, който написах, и в който подавам параметри, един от които е полето, по което да се сортира - като номер. Изглежда ще трябва да добавя едно допълнително ,1 в ORDER BY частта, дори и да се получават абсурдни заявки като ...ORDER BY 1 DESC, 1.

2. Всъщност, дори и да вкарам нещата в WHERE частта, това би било разносилно на INNER JOIN. А принципно, моята заявка е със 7-8 таблици, така че не става.

Everything louder than everything else...

Точно така.

Прави разлика обаче между случаен и произволен.

Произволен значи, че сървъра има правото да го избира. Включително и винаги да е един и същ. Въпросът е, че в момента в който не указваш изрично ORDER BY всъщност казваш на сървъра, че те ти пука какъв ще е редът. Това е логиката. И тя винаги е била такава за релационните бази данни


salle.online.bg/sig

"Точно така." - пак бъркам, или "Точно така." - резултатът от една единствена таблица не е произволен?

Тъкмо се проклинах, че в края на миналия постинг забравих да попитам каква е разликата между случаен и произволен...не че сега ми стана по-ясно, но мерси, че зачекна темата.

Истината е, че на мен наистина не ми пука какъв ще е редът...все ми е едно дали 2 ще е преди 3 или обратно, но искам винаги да е така. А не резултатът да се сменя според настроението на сървъра...което си е чиста случайност, освен ако в MySQL 4 не се включва и изкуствен интелект.

Everything louder than everything else...

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

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


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

Пращаш

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 пъти да получиш точно една и съща подредба или всеки път да е различна.

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

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

salle.online.bg/sig

Сега ми стана напълно ясно.

Остава само да вкарам някъде в картинката и кеширането на заявки.

Everything louder than everything else...

Силно те съветвам да изоставиш тоя стил

ORDER BY 1, 2

И да използваш alias-и или имената на колонките съответно

SELECT
x.id,
y.name
FROM
table_y y INNER JOIN table_x x
ON
x.y_id=y.id
ORDER BY y.name

Или още по-добре

SELECT
x.id AS id,
y.name AS name
FROM
table_y y INNER JOIN table_x x
ON
x.y_id=y.id
ORDER BY name

salle.online.bg/sig

[линк]

salle.online.bg/sig

На мен ми е адски удобно така, защото в Paging/Sorting класа не се интересувам от името на alias-а, а само от поредния му номер...иначе ще трябва да парсвам самото query или да подавам N параметъра.

Така не се използват индексите ли?

Everything louder than everything else...

Да де, аз го използвам already и съм доволен, но се чудех къде се фитва в контекста на произволното изваждане на данни и въпросните буфери в паметта, за които спомена...

Everything louder than everything else...

Обикновено най-лесното на пръв поглед се указва най-трудно за поддържане.

В моя случай е точно обратното.

Everything louder than everything else...