Comments 41
Некто?
Ну, кто-то все-таки заметил)
Успел 2 задачи сделать:
https://bugs.php.net/bug.php?id=76243 в mysql8 новый механизм аутентификации по умолчанию, запрос на поддержку в php.
https://bugs.mysql.com/bug.php?id=90529 установка в Centos из yum репозитория требует дополнительных телодвижений, чтобы корректно проинициализировались технические таблицы (схемы sys, mysql, performance_schema, information_schema)
Странно. Я еще с год назад юзал докер-образ с восьмеркой. Думал, что она уже давно зарелизилась
Выражения DDL стали атомарными и защищенными от падений, метаданные в транзакционной таблице.
То есть в предыдущих версиях падение во время выполнения DDL может всю БД сломать?
Ну, всю не всю, но можно было поиметь проблемы с той таблицей, которую менял этот DDL. Они, насколько я понимаю, не смертельные, все можно восстановить было, но ручками. А сейчас проблем, теоретически, быть больше не должно
раньше структуры таблиц хранились в myisam
то же самое что внутри транзакции сделать update на таблице без поддержки транзакционных механизмов
то же самое что внутри транзакции сделать update на таблице без поддержки транзакционных механизмов
Нет, раньше структуры таблиц хранились в frm файлах. Одна таблица — один файл. То есть CREATE TABLE состоял из двух этапов — 1) создать frm файл 2) создать таблицу внутри InnoDB. Если сервер падал между этими двумя этапами, сервер думал, что таблица есть, а InnoDB — что нет. Лечилось такое drop-аньем этой полу-таблицы и созданием заново.
CTE это отнюдь не только синтаксический сахар. Главное в них — рекурсия, и это принципиально новая штука в SQL (SQL-99, если честно) позволяющая делать то, что раньше было невозможно.
А можете дать ссылочку на какой-нибудь красивый пример, я в статью вставлю :)
В документации есть примеры. Например, в dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursive есть примеры на генерацию последовательностей (числа фибоначчи, все даты от… и до...) и на проход дерева (таблица employees с отношениями начальник-подчиненный).
А в mariadb.com/kb/en/library/recursive-common-table-expressions-overview есть пример на граф — нахождение всех маршрутов (с пересадками) из Нью-Йорка до Роли
А в mariadb.com/kb/en/library/recursive-common-table-expressions-overview есть пример на граф — нахождение всех маршрутов (с пересадками) из Нью-Йорка до Роли
Есть и более экзотические примеры (a.k.a. ненормальное программирование):
* Решатель судоку
* Интерпретатор Brainfuck
С добавлением рекурсивных CTE, SQL стал полным по Тьюрингу
* Решатель судоку
* Интерпретатор Brainfuck
С добавлением рекурсивных CTE, SQL стал полным по Тьюрингу
И, для полноты картины, в MariaDB CTE и оконные функции есть уже год. REGEXP_REPLACE, SQL-роли и гистограммы — четыре года. Но вот атомарных DDL, например, нет пока.
Да тут многие вещи в RC болтались минимум год, если приглядеться.
а еще check constraint есть
зато в марии json фейковый.
и чем дальше, тем больше они (эти две субд) будут отличаться.
в MariaDB json стандартный. В SQL стандарте такого типа нет.
Вообще тип — фигня, в MySQL просто медленный JSON парсер, и без бинарного json-а все ползало, а в MariaDB парсер побыстрей и ломать стандарт причины не было.
Из реально интересных штук — JSON_TABLE в 8.0. Этого в MariaDB нет. И json partial updates тоже интересная фича.
Вообще тип — фигня, в MySQL просто медленный JSON парсер, и без бинарного json-а все ползало, а в MariaDB парсер побыстрей и ломать стандарт причины не было.
Из реально интересных штук — JSON_TABLE в 8.0. Этого в MariaDB нет. И json partial updates тоже интересная фича.
Выражения DDL стали атомарными и защищенными от падений, метаданные в транзакционной таблице.Из доков:
This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACTION… COMMIT, or combined with other statements within the same transaction.Раз менять DDL внутри транзакции по-прежнему нельзя, то, получается, команду можно поздравить разве что с тем, что фундаментальная функция БД теперь работает и больше не
/dev/null.А есть ли какая-то информация, когда завезут поддержку
CHECK вместо «парсится и молча игнорируется»?
Сразу скажу, с MySQL я довольно поверхностно знаком, несмотря на долгую эксплуатацию. Вопрос к database-админам и увлеченным программерам — вроде как обещают прирост производительности до 200%. Еще не проверяли, не тестировали на всяких сценариях? И как с совместимостью веб-приложений?
В свое время были вдохновляющие статьи про PHP 7.0 — 1, 2, 3 с бенчмарками. Про новый MySQL бы такое увидеть.
В свое время были вдохновляющие статьи про PHP 7.0 — 1, 2, 3 с бенчмарками. Про новый MySQL бы такое увидеть.
Для меня самое главное в innodb таблицах наконец-то сохраняется значение максимального авто-инкремента даже при удалении записей или перезагрузках базы
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id из-за чего было много не уловимых багов
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id из-за чего было много не уловимых багов
>>Выражения DDL стали атомарными и защищенными от падений, метаданные в транзакционной таблице.
Это значит что можно накатывать пачку изменений на структуру БД в одной транзакции и при ошибке все скопом отменять rollback-ом?
Это значит что можно накатывать пачку изменений на структуру БД в одной транзакции и при ошибке все скопом отменять rollback-ом?
Еще из веселого — не веселого, убрали Query Cache.
NOWAIT and SKIP LOCKED — Запретить запросу ждать блокировку на уровне таблицы и на уровне отдельных строк, соответственно.Неудачная формулировка. Создается впечатление, что NOWAIT относится к уровню таблицы, а SKIP LOCKED — строк. Это не так.
SKIP LOCKED используюется для не детерминистического чтения из таблицы с пропуском строк, заблокированых другими пользователями.
NOWAIT — при наличии заблокированной строки не ждать освобождения блокировки innodb_lock_wait_timeout секунд, а сразу завершить выполнение запроса и вернуть ошибку:
ERROR 3572 (HY000): Do not wait for lock.
Есть хорошая статья Мартина Ханссона, перевод тут.
Вложенные транзакции не появились случаем?
Слишком поздно для комментариев, но хотел спросить, никто не сталкивался с таким что 5.7 примерно на 20% быстрее была, чистую установку 8.0 накатил, из дампа бд раскатал, запускаю одинаковую затратную операцию на той же бд, скорость хуже на 8.0
Sign up to leave a comment.
Никто и не заметил, как вышел MySQL 8.0