Это стандарт SQL. Если никакая сортировка не указана - база возвращает результат в любом удобном для себя порядке.
Innodb всегда кластеризован (расположен физически) в порядке первичного ключа. Поэтому seqscan и index scan по PK полностью совпадают. Не более чем допустимое стандартом влияние деталей реализации.
Если в innodb нет ни первичного ни уникального ключа - то таблица будет кластеризована по скрытому автоматически-созданному идентификатору. Для стороннего наблюдателя - порядка в ней не будет.
А тот же myisam - всегда бинарная куча, каждый апдейт может переместить запись в другое место всей таблицы, каждый insert попытается вставить запись на то место, где когда-то была удалённая delete запись..
Василий Назаров: ну, вляпаетесь ещё когда-нибудь. Таких коллег тоже встречал, уверенно утверждавших, что приложения достаточно для контроля ссылок. А потом случается "ой!"
Василий Назаров: делать внешние ключи обязательно. Иногда - не надо. И для этого "не надо" нужна чёткая аргументация
Если вы ранее никогда не вляпывались в ситуацию "wtf? в той табличке значение есть, а ссылается куда-то в никуда" - то вы просто слишком недавно работаете. Я за 7 лет опыта веб-разработчиком уже повидал такого.
Потому что shit happens. Если ограничение проверить может ещё кто-то помимо приложения - этим надо пользоваться. Не допускать писать кривые данные куда проще и дешевле, чем потом разбираться с мусором вместо данных. Да и искать ошибку проще по стектрейсу попытки записи невалидных данных, т.к. ошибка где-то там.
И эта галочка тоже абсолютно лишняя с точки зрения UX.
Да и не ограничивается гуглокапча галочкой, от меня постоянно требует найти картинки с дорожными знаками, витринами или ещё какими горами.
Армянское Радио: опять же смотря как запускать.
Поблочно устройства - разумеется консистентный снимок ФС не получится как минимум без перемонтирования в ro на всё время копирования.
Смонтированную ФС синхронизировать в два-три прохода (последний на ro ФС) - милое дело.
Армянское Радио: смотря как запускать. Утилита хорошая, наверное и поблочную копию сможет сделать если натравить на сами блочные устройства. Только может пары мегабайт места опять же не хватить
Предполагаю, что автор знает, как скопировать свои данные, т.к. не указано, может там вообще lvm, про который разговор попроще, но отдельный и подлиннее.
Армянское Радио: dd скорей всего не влезет. mdadm резервирует небольшой кусочек диска под метаданные
Ну и потому что можно продолжать работать, пока rsync шуршит. Для dd ведь надо размонтировать диск.
"Сама база" - это весь целиком /var/lib/pgsql/data/ плюс tablespace если есть. Только пара конфигов могут лежать отдельно, но тогда обязательно задаваться аргументами запуска пути до postgresql.conf и в нём самом.
Я имел в виду перенести весь /var/lib/pgsql/data/ целиком куда надо, а на месте /var/lib/pgsql/data сделать симлинк на новое месторасположение. И это работать будет.
Mysql всё-таки имеет функции, не знали?
year - это функция, возвращающая год для переданного аргументом поля типов date, datetime, timestamp
month аналогично возвращает месяц для тех же типов данных
Функции тоже можно использовать в where. Вызвали функцию, она что-то сделала и что-то вернула, и это что-то можно сравнить с чем-нибудь другим.
Я написал полностью эквивалентное выражение where, именно это ваш запрос и пытается сделать. Только плохо, не оптимально пытается.
где ddl таблицы? Где локализация проблемы до "вот здесь я использую напрямую и вижу в переменной X, а вот тут я пишу в базу, затем читаю и базы и вижу Y. Почему так?"
Для начала кодировка. utf8 в mysql не умеет 4-х байтовый юникод. У вас точно utf8mb4 везде используется?
Логикой и опытом. Знаете чем они различаются? union делает distinct. Почти всегда это нафиг не нужно по условиям изначальной задачи, но это дорогая операция требующая материализации запроса во временной таблице и собственно поиск дублей. Повезёт, если только inmemory, можно и до filesort'а дойти легко. Для совершенно ненужной задачи. А зачем?
У вас хоть транзакционный storage engine?