The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Стабильный релиз СУБД MySQL 8.0

19.04.2018 23:25

После двух с половиной лет разработки компания Oracle представила первый стабильный релиз СУБД MySQL 8.0. Версия 8.0 обусловлена сменой нумерации версий, релиз выпущен следом за 5.7 вместо версии 5.8. Сборки MySQL Community Server 8 сформированы для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows.

Ключевые улучшения MySQL 8.0:

  • Добавлены оконные функции (window-функции или аналитические функции), позволяющие для каждой строки запроса выполнить вычисления, используя строки, связанные с текущей строкой. В отличие от агрегатных функций над сгруппированными строками, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят агрегирование для каждой строки в результирующем наборе. Реализованы как специальные оконные функции RANK, LAG, ROW_NUMBER, FIRST_VALUE, LEAD, LAG и NTILE, так и возможность применение некоторых агрегатных функций в форме оконных (например, COUNT, SUM, AVG, MIN, MAX);
  • Поддержка рекурсивных и не рекурсивных обобщённых табличных выражений (Common Table Expression), позволяющих использовать временные именованные результирующие наборы, задаваемые при помощи оператора WITH;
  • В InnoDB добавлена поддержка опций NOWAIT и SKIP LOCKED, которые можно использовать для управления поведением при наличии блокировок в момент выполнения выражений "SELECT ... FOR SHARE" и "SELECT ... FOR UPDATE". При указании NOWAIT управление будет возвращено сразу с выводом ошибки, если запрошенная строка заблокирована другой транзакцией, а при "SKIP LOCKED" заблокированные строки будут исключены из результирующего набора;
  • Поддержка невидимых индексов (Invisible Indexes), которые никогда не используются оптимизатором. Управление видимостью индекса производится при помощи ключевых слов VISIBLE и INVISIBLE. Обычный видимый индекс может быть превращён в невидимый и наоборот. Невидимые индексы можно использовать для тестирования влияния того или иного индекса на производительность, без физического удаления данного индекса (индекс можно перевести в режим невидимого, изучить изменение производительности и вернуть обратно);
  • Поддержка нисходящих индексов (descending indexes), позволяющих использовать оператор "DESC" при определении индекса для сохранения значений ключей в порядке убывания. В работе подобные индексы не требуют сканирования в обратном порядке, что значительно увеличивает эффективность работы с убывающими значениями;
  • Реализована функция GROUPING(), которая позволяет отделить NULL-значения, полученные в результате агрегирования строк при группировке GROUP BY с использованием таких расширений, как ROLLUP, от NULL-значений в обычных сгруппированных строках;
  • Добавлены новые подсказки для управления поведением оптимизатора (задаются внутри комментария /*+ */, указываемого сразу после ключевых слов SELECT, INSERT, REPLACE, UPDATE и DELETE): INDEX_MERGE и NO_INDEX_MERGE для управления поведением слияния индексов для отдельных запросов, JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX и JOIN_SUFFIX для управления порядком обработки таблиц при выполнении слияния, SET_VAR для установки системной переменной в контексте текущего выражения;
  • Добавлены новые функции для манипуляции данными в формате JSON:
    • Расширен синтаксис для определения диапазонов значений в JSON, например "SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');".
    • Добавлена поддержка табличных функций, позволяющих использовать SQL для данных JSON (при помощи функции JSON_TABLE() создаётся реляционное представление данных JSON).
    • Добавлены агрегатные функции JSON_ARRAYAGG() для генерации массивов JSON и JSON_OBJECTAGG() для генерации объектов JSON.
    • Добавлены функции слияния JSON_MERGE_PATCH() и JSON_MERGE_PRESERVE().
    • Добавлена функция JSON_PRETTY() для приведения блоков JSON к читаемому виду;
    • Добавлена функция JSON_STORAGE_SIZE() для вычисления размера, который занимает объект JSON;
    • От 1.2 до 18 раз увеличена производительность сортировки и группировки значений JSON;
  • Добавлен режим работы в качестве хранилища документов (Document Store), к которому можно обращаться с использованием методов NoSQL (коллекции JSON без предварительно определяемой схемы хранения). Функциональность реализована при помощи плагина mysqlxplugin;
  • Добавлена поддержка пространственных типов данных, индексов и функций, позволяющих работать с географическими координатами и картографическими данными;
  • По умолчанию задействована кодировка UTF8MB4 (ранее применялась кодировка latin1) и поддержка свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. По сравнению с версией MySQL 5.7 существенно (до 20 раз) увеличена производительность сортировки данных в кодировке UTF8MB4;
  • Добавлены новые функции для использования регулярных выражений REGEXP_INSTR(), REGEXP_LIKE(), REGEXP_SUBSTR() и долгожданная функция замены при помощи регулярных выражений REGEXP_REPLACE(). Кроме того, в регулярных выражениях реализована корректная работа с многобайтовыми Unicode-символами;
  • Transactional Data Dictionary - новый механизм хранения системных данных, поддерживающий транзакции и реализованный в виде набора SQL-таблиц, хранимых в отдельном табличном пространстве InnoDB (хранение системных данных и метаданных в MyISAM прекращено);
  • Новая система ролей (именованных коллекций привилегий), позволяющая делегировать и блокировать полномочия для групп пользователей;
  • Добавлена возможность переименования столбцов (ALTER TABLE ... RENAME COLUMN old_name TO new_name);
  • Задействован по умолчанию плагин аутентификации caching_sha2_password, использующий SHA-256 для хэширования паролей, но по сравнению с плагином sha256_password обеспечивающий более высокую производительность за счёт использования кэширования;
  • Добавлена защита от атак по подбору паролей. В случае нескольких неудачных попыток аутентификации теперь между следующими попытками добавляется задержка;
  • Добавлена команда "SET PERSIST", позволяющая менять значения переменных конфигурации с сохранением их между перезапусками. Также добавлена команда RESTART, позволяющая удалённо перезапустить MySQL при наличии соответствующих полномочий;
  • В качестве библиотеки с реализацией TLS/SSL по умолчанию задействован OpenSSL;
  • Добавлена поддержка шифрования Undo- и Redo-логов;
  • Проведены различные оптимизации производительности, например, в тесте upto при 4 одновременно работающих клиентах достигнуто почти двухкратное ускорение - продемонстрирована производительность на уровне 1.8 млн запросов в секунду. Скорость запросов к таблицам Performance Schema возросла до 30 раз, а к таблицам Information Schema до 100 раз.

  1. Главная ссылка к новости (https://mysqlserverteam.com/wh...)
  2. OpenNews: Уязвимость в mysqldump, позволяющая выполнить код при восстановлении бэкапа
  3. OpenNews: Уязвимость в MySQL, позволяющая поднять свои привилегии
  4. OpenNews: В MySQL 8.0 отмечается закат хранилища MyISAM
  5. OpenNews: Критическая root-уязвимость в MySQL
  6. OpenNews: Компания Oracle анонсировала стабильный релиз MySQL 5.7
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48466-mysql
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (83) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:30, 19/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Спасибо, но уже есть PostgreSQL и MariaDB.
     
     
  • 2.2, KonstantinB (ok), 23:35, 19/04/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это лучше, чем MariaDB, они выпилили myisam насовсем, в том числе из служебных таблиц.
     
     
  • 3.3, Имя (?), 23:49, 19/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Aria?
     
     
  • 4.4, KonstantinB (ok), 00:09, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Фигария, попробуй сменить тип таблиц в базе mysql.
     
  • 4.6, KonstantinB (ok), 00:12, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html
     
  • 3.5, Gemorroj (ok), 00:11, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    вот тоже уже думаю обратно на ванильный mysql с марии переезжать.
    честный json, sys схема... в то время как мария начала ломать совместимость с оригинальным mysql (тот же json), что сильно снижает ее привлекательность.
     
     
  • 4.7, KonstantinB (ok), 00:15, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Еще CTE и window-функции завезли.

    Я с бетой игрался, отлично, уже прям настоящая РСУБД, скоро постгрес догонит.

     
     
  • 5.46, Gemorroj (ok), 11:29, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я пока заткнулся с https://dev.mysql.com/doc/refman/8.0/en/mysql-secure-installation.html


    # mysql_secure_installation

    Securing the MySQL server deployment.

    Connecting to MySQL using a blank password.
    Segmentation fault



     
     
  • 6.70, Аноним (-), 09:30, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Segmentation fault

    Обычно перестаёт быть страшно к N.X.20-26, а в важных местах к N.X.40
    Но ходят слухи, что минорная нумерация версий тоже поменяется/поменялась.

     
  • 4.15, Монти Пайтон (?), 01:29, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Percona умеет половину из Maria и Mysql 8.0
     
     
  • 5.20, KonstantinB (ok), 06:00, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Percona умеет половину из Maria и Mysql 8.0

    Transactional data dictionary не умеют, это самое главное. Тут я восхищаюсь объемом проделанной работы. Системные словари относятся к самому древнему окаменевшему коду, который Монти писал на коленке в далеких девяностых, и myisam был прибит гвоздями наглухо кондовым хардкодом везде, где можно и нельзя.

     
     
  • 6.56, Аноним (-), 17:50, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    myisam гогно, тут я с вами согласен на все 100%
     
  • 5.69, Аноним (-), 09:27, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Percona умеет половину из Maria и Mysql 8.0

    Percona не пилит новые божественные фичи. Percona Server это ванильный оракловый MySQL + набор фишек повышающих производительность (чаще меньше чем следующий мажорный релиз от Oracle) + удобства диагностики (больше инфы в slowlog, userstats) + энтерпрайз фишки под GPL вроде PAM audit_plugin.

    MariaDB пилят свои фишки отдельно, на своём форке mysql 5.5, без оглядки что это надо/можно будет объединить с Oracle MySQL.

    Так что Percona Server 8.0 выйдет через пару месяцев и будет уметь то же что и MySQL 8.0, а фишки из MariaDB доступны только плагинные.

    Никакой магии нет, все три компании занимаются разным в плане разработки.

     
  • 5.82, KonstantinB (ok), 21:01, 23/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А вот так они могут? :-)
    https://www.reddit.com/r/brainfuck/comments/83cw7l/i_implemented_a_brainfck_in

    C рекурсивным CTE, кстати, MySQL-евский диалект SQL стал тьюринг-полным языком. :-)

     
  • 4.40, feudor (ok), 11:09, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    мария начала ломать совместимость с оригинальным mysql хорошая шутка.
     
     
  • 5.45, Gemorroj (ok), 11:28, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну поработай с json, найди там хоть какой-то сходство.
     
     
  • 6.52, feudor (ok), 13:21, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    я про то что оригинальный MySQL это и есть мария.
     
  • 4.61, Ilya Indigo (ok), 03:56, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://jira.mariadb.org/browse/MDEV-13594
    Ответ на мой комментарий меня просто поразил.
    Я после того подумал про миграцию на PostgreSQL.
     
  • 2.8, IRASoldier (?), 00:17, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/
     
     
  • 3.9, KonstantinB (ok), 00:33, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы с озвученной Uber-ом проблемой столкнуться, нужен особый характер нагрузки - множество апдейтов в секунду, затрагивающих индекс. Для большинства проектов это не критично.
     
     
  • 4.24, Аноним (-), 07:21, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Из статьи следует, что апдейты индексированнного поля и неиндексированного одинаково тяжеловесны в Постгри.
      Использование СУБД файлового кеша ОСи убило ваапще.

    Подумывал опробывать Постги, но теперь обожду.

     
     
  • 5.59, Аноним (-), 20:23, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Использование СУБД файлового кеша ОСи убило ваапще.

    И чем же?

     
     
  • 6.71, Аноним (-), 09:38, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Использование СУБД файлового кеша ОСи убило ваапще.
    > И чем же?

    Если горячая страничка (на чтение) вытеснится из кеша ОС, сразу пачка одновременных запросов может заблокироваться, за это время придёт ещё пачка запросов и база будет работать медленнее из-за скачка нагрузки (больше тредов/процессов - больше блокировок).

    Эту проблему можно убрать, если кешировать в shared memory сегменте базы, но без direct io одни и те же данные будут и в shared memory и в кеше ОС, а значит надо для одних и тех же данных закупать на 20-30% больше оперативной памяти если база не работает/не эфективно работает с direct io.

     
     
  • 7.86, Аноним (-), 22:31, 24/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > одни и те же данные будут и в shared memory и в кеше ОС

    Как долго? Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритмы вытеснения не используемых данных, в конечном счёте в shared_buffers останутся горячие данные, а в кеше ОС — тёплые (другие), потому что данные находящиеся в shared_buffers не запрашиваются у ОС и вытесняются из кеша, не так ли?

     
  • 5.62, KonstantinB (ok), 04:29, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением. Хранилище постгреса проектировалось в те далекие времена, когда никаких O_DIRECT не было даже в планах. В условиях какого-нибудь ядра 1.4 или freebsd 3 это было наиболее эффективным решением. Оттуда же и пачки процессов и shared memory - никаких epoll-ов и прочих kevent тоже не было, с тредами все было печально. Но, надо заметить, все это и сейчас весьма неплохо работает.
     
     
  • 6.78, нах (?), 21:38, 22/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением.

    и пока линуксеры не доломали совместимость с нормальными юниксами - вполне пристойно работает.

    родовая травма постгреза - его причудливейший формат storage, корнями уходящий в великую бесполезно-фичу time-travel (не работающую со времен postgresql95)

    с вечным vacuum ("мы его уже совсем-совсем deprecated, он ненужен-ненужен...а, нет, разумеется он будет и дальше вызываться из внутреннего планировщика в самые неподходящие моменты, мы не об этом") и вечным разрастанием индексов.
    Что новый-модный zheap решит эти проблемы не создав попутно все те же что у myisam и еще пачку уникальных - что-то вот не верится.

     
  • 4.55, letsmac (ok), 15:51, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы с этой проблемой столкнуться надо написать оптимизированную логику под MySQL, а потом перенести эту логику на Postgres. У которой свои оптимизации.

    >>Для большинства проектов это не критично.

    Postgres не любит апдейтов, как и любой версионник. Для кучи апдейтов лучше уж NoSQL использовать.

     
     
  • 5.64, funny. falcon (?), 08:23, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Извините, но Innodb тоже версионник. Однока он лучше сравляется спробоемой потому, что у него быстрее всего доступна именно последняя версия строки.

    В постгрессе же последняя версия строки чаще всего попадает в экзкьютор последней.

     
  • 3.10, Аноним (-), 00:33, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не нужен кому? PostgreSQL это из разряда MSSQL, продукции Oracle, Sybase.

    З.Ы. топить за MyISAM не смешно и не весело ни разу.

     
     
  • 4.11, Аноним (-), 00:40, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А чем myisam плох для определённых случаев? Вот есть десяток девелоперских баз. На myisam заливка дампа  на два с половиной гигабайта с прода занимает от силы 10 минут. На Inno/XtraDB - в лучшем случае час, и всякие игрища с параметрами в my.cnf и системной схеме не особо помогают.
     
     
  • 5.12, KonstantinB (ok), 00:58, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для девелоперской базы никто не мешает остановить mysqld и ручками скопировать innodb-файлы.
     
     
  • 6.17, angra (ok), 02:52, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потом попробовать стартануть мускул, почитать ругань, а если он таки стартанул, то попытаться найти таблицы и обнаружить их отсутствие. Повторить процесс такого горячего копирования несколько раз, до тех пор пока не придет осознание, что ты что-то делаешь неправильно. Потом пойти почитать про кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb.
     
     
  • 7.19, KonstantinB (ok), 05:54, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ничего сложного, совсем.
    Во-первых, можно скопировать содержимое /var/lib/mysql вообще целиком
    Во-вторых, если хочется частично, https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html
     
     
  • 8.27, angra (ok), 07:50, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не говорил, что сложно или невыполнимо Но простое копирование как с MYISAM пр... текст свёрнут, показать
     
     
  • 9.30, KonstantinB (ok), 08:09, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно куча, элементарно все ... текст свёрнут, показать
     
  • 9.31, KonstantinB (ok), 08:11, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Задача была импортировать данные на машину разработчика Для этого можно и так с... текст свёрнут, показать
     
  • 9.72, Аноним (-), 10:00, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет утилиты официальной, чтобы бекапить всю базу и разворачивать её с помощью tr... текст свёрнут, показать
     
  • 7.22, Аноним (-), 06:58, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если останавливают процессы, то это не горячее а холодное копирование.
     
     
  • 8.25, angra (ok), 07:41, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Из контекста остановка продакшена не предусматривалась и про использование репли... текст свёрнут, показать
     
     
  • 9.26, ыы (?), 07:45, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В общем вместо чтения документации - каждый на своей волне ... текст свёрнут, показать
     
  • 9.28, KonstantinB (ok), 08:03, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то там речь о девелоперских базах шла И что это такой за продакшен без р... текст свёрнут, показать
     
     
  • 10.38, ыы (?), 11:06, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    там может быть все что угодно например 386DX2 какой-то хостинг с 64 мегами о... текст свёрнут, показать
     
     
  • 11.73, Аноним (-), 10:09, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    даже с mysqldump innodb есть фокусы настройки, чтобы заливать дамп быстрее истор... текст свёрнут, показать
     
     
  • 12.84, angra (ok), 04:55, 24/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да уж, заменить hdd на ssd тот еже фокус настройка Предлагаю не менее эффективн... текст свёрнут, показать
     
  • 11.83, angra (ok), 04:52, 24/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Заметь, что соотношение осталось прежним 1 6... текст свёрнут, показать
     
  • 9.53, Аноним (-), 13:51, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это была поправка на конкретное высказывание http www opennet ru openforum vsl... текст свёрнут, показать
     
  • 5.39, Валик228 (?), 11:07, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    вам бы попробовать дампить базу с ключем --disable-keys

     
  • 3.13, Аноним (-), 01:05, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Статья устаревшая из-за старой используемой версии у Убера. Хотя, конечно, никто не без проблем.
     
     
  • 4.14, KonstantinB (ok), 01:09, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да пофиг какая версия, основное там - это родовая проблема с организацией данных. Из-за нее, кстати, и нужен тяжелый VACUUM. Патчи в новых версиях только смягчают проблему, но не решают.

    Все остальные пункты - действительно мелкие придирки.

     
  • 3.63, Ilya Indigo (ok), 05:08, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Postgre пока не нyжен - детально так раъяснено почему - https://habrahabr.ru/company/devconf/blog/353682/

    Благодарю за ссылку! Зачитался и задумался аж на 2 часа.

     
  • 3.81, fi (ok), 14:30, 23/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    этот старый вброс давно разобран по косточкам — там в основном проблемы разраба, плюс ему очен хотелось MySQL
     
  • 2.16, rshadow (ok), 01:37, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Постгря плохо работает с индексами. И разрабы абсолютно упираются от создания инструмента ручного управления ими. Так что директивы и невидимые индексы выглядят вкусно.
     
     
  • 3.33, Кабан ЛяЛя (?), 09:11, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это где она плохо работает?
    Хоть один пример...

    За ручное управление индексами "по шапке"!

     
     
  • 4.41, Аноним (-), 11:12, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тут не про индексы наверное имелось ввиду а про оптимизатор.
     
     
  • 5.50, rshadow (ok), 13:16, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да. Начиная с COUNT(*) который полным сканированием определяется, заканчивая явными глюками оптимизатора, которые может когда нибудь и починят.
     
     
  • 6.74, Аноним (-), 10:28, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В 5 7, кстати select count чуток ускорили InnoDB SELECT COUNT FROM t sta... большой текст свёрнут, показать
     
  • 4.51, rshadow (ok), 13:21, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Совершенно с вами согласен. Только для сферического мира где планировщик не глючит, ALTER TABLE...NOT NULL всегда делается мгновенно на боевой бд, и вообще есть беспростойный апгрейд версии через репликацию.
    Очень хочется просто вводить команды, а оно само оптимизировалось, расползалось по кластеру, делалось мгновенно и без глюков.
     

  • 1.23, Анонимъ (?), 07:21, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ура?
     
     
  • 2.29, Николай (??), 08:05, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ура?

    Да

     

  • 1.32, Аноним (-), 09:07, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Про партицирование ничего не сказали. Его поправили? Можно теперь совмещать в таблице партиции разных движков?
     
     
  • 2.34, Ануним (?), 10:03, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О, помню этот баг. Помнится, из-за него я рабочий проект потребовал на MSSQL перевести.
     
     
  • 3.48, Аноним (-), 12:07, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами хранения данных в рамках одной таблицы. Хотя фактически это были разные таблицы. В итоге забили, перевели на SSD, которые мрут как мухи, но обеспечивают стабильную поддержку ПО.
    Не понятно, зачем вводить в протокол функционал, который они и не собирались поддерживать. Подразнить?...
     
     
  • 4.66, Аноним (-), 08:34, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами
    > хранения данных в рамках одной таблицы.

    а DATA DIRECTORY не пробовали с партициями? https://dev.mysql.com/doc/refman/5.7/en/partitioning-subpartitions.html


     
  • 2.65, Аноним (-), 08:29, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот выпилили эту возможность:
    https://dev.mysql.com/doc/mysql-partitioning-excerpt/8.0/en/partitioning.html

    In MySQL 8.0, partitioning support is provided by the InnoDB storage engine. (The NDB storage engine used by MySQL Cluster also provides partitioning support, but NDB is not included in MySQL 8.0.)

    MySQL 8.0 does not currently support partitioning of tables using any storage engine other than InnoDB, such as MyISAM. An attempt to create a partitioned tables using a storage engine that does not supply native partitioning support fails with ER_CHECK_NOT_IMPLEMENTED.

     

  • 1.35, luserz (?), 10:36, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    параллельность добавили выполнения запросов? или всё так же в одну каску молотит каждый запрос?
     
  • 1.36, анонимус (??), 10:52, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.

    Почему я не могу аггрегировать данные в колонку при группировке с сохранением типов? GROUP_CONCAT возвращает строку.

    Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае если строка превышает значение установленное в group_concat_max_len?

    Такого поведения там полно. И пока его не пофиксят MySQL так и останется недоСУБД.

     
     
  • 2.37, Фуррь (ok), 10:59, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.

    Обычно такие претензии возникают из-за непонимания того, что MySQL - это маленькая быстрая пони, и её нельзя грузить, как ломовую лошадь.

     
     
  • 3.76, Адноним (?), 14:34, 22/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Маленькая пони полная Нонна из сомнительных решений и память она жрет в разы больше pgsql
     
  • 2.42, Аноним (-), 11:16, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц ... большой текст свёрнут, показать
     
     
  • 3.54, KonstantinB (ok), 15:05, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц?

    Транзакционные системные словари и atomic DDL в 8.0 сделали, так что скоро. Вроде уже ничто не мешает.

     
  • 2.43, Аноним (-), 11:18, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Такого поведения там полно. И пока его не пофиксят MySQL так и
    > останется недоСУБД.

    Так она по определению теперь такая, а так-же тестовый полигон и обучалка для будущего использования промышленной БД от oracle.

     
  • 2.44, Gemorroj (ok), 11:24, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по 1 пункту - https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html для этого и делалось.
     

  • 1.47, rvs2016 (ok), 11:45, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Версия 8.0 обусловлена сменой нумерации версий,
    > релиз выпущен следом за 5.7 вместо версии 5.8.

    Не понял прикола. Почему в смене версий с 5.7 на сразу 8.0 упор делается на то, что не было промежуточных версий с непонятными номерами типа 5.8 вместо указания на отсутствие более логичных номеров типа 6.0 да 7.0?

    ps: С версиями типа 6.* вроде прикол много лет назад ходил такой: начали делать шестые версии, а потом забросили и откатились обратно на пятые. А с седьмыми номерами прикол какой, в чём?

     
     
  • 2.57, Аноним (-), 19:05, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тут как с джавой логика, минорная циферка переехала в мажорную, потому что по факту 5.х это давно уже не минорные релизы.
     
     
  • 3.58, Аноним (-), 19:07, 20/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да и Марию догонять надо :)
     

  • 1.49, Аноним (-), 12:48, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то появилась в транзакции уже? SELECT ... FOR UPDATE?
     
     
  • 2.67, Аноним (-), 08:53, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то
    > появилась в транзакции уже? SELECT ... FOR UPDATE?

    SELECT FOR UPDATE был уже в 4.0, 2002 год, почти 16 лет назад.

    В 8.0 добавили возможность при использовании select for update либо выдать ошибку как только натолкнёмся на строчку заблокированную другой транзакцией NOWAIT (модифицированную или заблокированную S F U) либо молча пропускать строчки заблокированные другими транзакциями SKIP LOCKED.

    Сходу что приходит в голову, такие фишки позволяют делать очереди с несколькими обработчиками на кроне/event scheduler.

     

  • 1.60, Vitaliy Blats (?), 20:35, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не высрет в лог кучу непонятной срани, а при попытке восстановить скажет "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using бла бла бла"
     
     
  • 2.68, Аноним (-), 09:07, 21/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    InnoDB модифицирует данные по месту, Если лог транзакций физически повреждён, то... большой текст свёрнут, показать
     
     
  • 3.77, нах (?), 18:16, 22/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются
    > вникуда (потому что это более свежая версия страницы)

    откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?

     
     
  • 4.79, Аноним (-), 21:49, 22/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В каждой странице содержится ссылка на следующую и предыдущую Если мы сделали с... большой текст свёрнут, показать
     
     
  • 5.80, нах (?), 01:12, 23/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.

    то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).

    binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.

     

  • 1.87, Alex (??), 23:45, 04/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мда.. вышел порт 8.0.12_1, затем 8.0.12_2 и не собирается.. откатывать обратно на 5.7...

    mysql80-server-8.0.12_2 is vulnerable:
    MySQL -- multiple vulnerabilities
    CVE: CVE-2018-3286
    CVE: CVE-2018-3283
    CVE: CVE-2018-3284
    CVE: CVE-2018-3282
    CVE: CVE-2018-3279
    CVE: CVE-2018-3278
    CVE: CVE-2018-3161
    CVE: CVE-2018-3186
    CVE: CVE-2018-3280
    CVE: CVE-2018-3212
    CVE: CVE-2018-3170
    CVE: CVE-2018-3200
    CVE: CVE-2018-3173
    CVE: CVE-2018-3162
    CVE: CVE-2018-3277
    CVE: CVE-2018-3171
    CVE: CVE-2018-3174
    CVE: CVE-2018-3187
    CVE: CVE-2018-3247
    CVE: CVE-2018-3195
    CVE: CVE-2018-3185
    CVE: CVE-2018-3144
    CVE: CVE-2018-3145
    CVE: CVE-2018-3133
    CVE: CVE-2018-3203
    CVE: CVE-2018-3137
    CVE: CVE-2018-3182
    CVE: CVE-2018-3251
    CVE: CVE-2018-3156
    CVE: CVE-2018-3143
    CVE: CVE-2018-3155
    CVE: CVE-2016-9843
    WWW: https://vuxml.FreeBSD.org/freebsd/ec5072b0-d43a-11e8-a6d2-b499baebfeaf.html

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру