ORDER BY ... ASC, из-за чего может отличатся сортировка, если ее не меняешь?

Question

[Дмитрий]

Два запроса ниже, выдают почти одни и теже данные.
ORDER BY datePost ASC, указан у обоих запросах, но выдает по разному.
MySQL 8.

SELECT idPost FROM posts WHERE `idRecordPost` = 83 and moder = 1 ORDER BY datePost ASC

SELECT users.loginUser, users.groupUser, posts.idPost, posts.textPost, posts.datePost FROM users INNER JOIN posts ON posts.idUserPost = users.idUser and posts.`idRecordPost` = 83 and posts.moder = 1 ORDER BY posts.datePost ASC

Значение datePost может повторятся UNIX time!

Comments

[Immortal_pony]

Ну так а что выдает-то? "Оличается"-то как?

[Дмитрий]

Immortal_pony, вот

[Immortal_pony]

Если дата одинаковая, то сортировка будет "от балды".

[Дмитрий]

Immortal_pony, ан нет! Она всегда одинаковая, могу предположить что внутри базы микросекундная метка.

[Immortal_pony]

inilim это остается абсолютно на усмотрение базы и зависит от внутренних алгоритмов реализации. Сегодня одинаковая - завтра изменится и это будет по-прежнему корректным поведением с точки зрения БД.
Если вы хотите гарнтировать порядок, то добавляйте в сортироку те поля, значения которых у записей отличаются - в этом случае сортировка будет происходить по второму полю в случае если значения первого поля одинаковы.

Например:

SELECT 
    `idPost` 
FROM 
    `posts` 
WHERE 1
    AND `idRecordPost` = 83 
    AND `moder` = 1 
ORDER BY 
    `datePost` ASC,
    `id` ASC

SELECT 
    `users`.`loginUser`, 
    `users`.`groupUser`, 
    `posts`.`idPost`, 
    `posts`.`textPost`, 
    `posts`.`datePost` 
FROM 
    `users` 
    INNER JOIN `posts` ON (
        `posts`.`idUserPost` = `users`.`idUser` AND
        `posts`.`idRecordPost` = 83 AND 
        `posts`.`moder` = 1 
    )
ORDER BY 
    `posts`.`datePost` ASC,
    `posts`.`id` ASC

[Дмитрий]

Immortal_pony, решения так и нет, так как idPost и есть автоинкремент, и он может изменятся, им сортировать нельзя. Как насчет изменить тип поля datePost на float и ставить время в микросекундах с плавающей точкой, что бы при добавлении записи, повторов не было уж точно.

[Immortal_pony]

inilim менять я бы не рекомендовал - потом можете получить проблемы в других частях системы из-за изменения формата хранения данных. А вот еще колонку `posts`.`timePost` можно добавить. И писать туда CURTIME(6) например (ну или на стороне backend ЯП вычислять - на ваш вкус).

Answer 1

[Андрей]

таблица users,
по ней нет сортировки, соответственно, строки извлекаются в порядке вставки.
если в from использовать posts - по-идее, разница должна исчезнуть.

Comments

[Дмитрий]

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

SELECT users.loginUser, users.groupUser, posts.idPost, posts.textPost, posts.datePost FROM posts INNER JOIN users ON posts.idUserPost = users.idUser and posts.`idRecordPost` = 83 and posts.moder = 1 ORDER BY posts.datePost ASC

[Андрей]

А конкурентных вставок вообще много? Если нет, я бы просто ещё поле добавил, уникальное целочисленное возрастающее и по нему сортировал.

Answer 2

[SagePtr]

Выбирать по двум критериям, например ORDER BY datePost ASC, idPost ASC (в этом случае выбираться будут по дате, но при одинаковой дате - по idPost).

Comments

[Дмитрий]

Сортировка исключительна нужна на datePost, на idPost нельзя, так как idPost может изменять, если она изменится то вывод на сайте будет отличатся, то есть не по хронологии.

[SagePtr]

inilim, внимательнее прочитайте мой ответ.

[Дмитрий]

SagePtr, Ну в таком случаи, оба запроса должны сортироваться по idPost.

[SagePtr]

inilim, если в ORDER BY указать несколько полей, то сортироваться будет по первому полю, и только при равенстве значений первого поля - по второму, и так далее.