1.4. Что Ново в MySQL 5.6

MySQL теперь обеспечивает метод для того, чтобы он сохранил учетные данные аутентификации, зашифрованные в названном файле опции .mylogin.cnf. Чтобы создать файл, используйте mysql_config_editor утилиту. Файл может быть считан позже клиентскими программами MySQL, чтобы получить учетные данные аутентификации для того, чтобы соединиться с сервером MySQL. mysql_config_editor пишет .mylogin.cnf файл используя шифрование так учетные данные не хранится как открытый текст, и его содержание когда дешифровано клиентскими программами используется только в памяти. Таким образом пароли могут быть сохранены в файле в формате неоткрытого текста и использоваться позже, никогда не будучи должен быть представленными на командной строке или в переменной окружения. Для получения дополнительной информации см. Раздел 4.6.6, "mysql_config_editor — MySQL Configuration Utility".

MySQL теперь поддерживает более сильное шифрование для паролей учетной записи пользователя, доступных через названный плагин аутентификации sha256_password это реализует SHA 256 хеширующих паролей. Этот плагин встраивается, таким образом, это всегда доступно и не должно быть загружено явно. Для получения дополнительной информации, включая инструкции для того, чтобы создать учетные записи, которые используют SHA 256 паролей, см. Раздел 6.3.7.2, "SHA 256 Плагинов Аутентификации".

mysql.user у таблицы теперь есть a password_expired столбец. Его значение по умолчанию 'N', но может быть установлен в 'Y' с новым ALTER USER оператор. После того, как пароль учетной записи истекся, все операции, выполняемые в последующих соединениях с сервером, используя результат учетной записи по ошибке до пользовательских проблем a SET PASSWORD оператор, чтобы установить новый пароль учетной записи. Для получения дополнительной информации см. Раздел 13.7.1.1,"ALTER USER Синтаксис".

У MySQL теперь есть условие для того, чтобы проверить безопасность пароля:

Обе возможности реализуются validate_password плагин. Для получения дополнительной информации см. Раздел 6.1.2.6, "Плагин Проверки допустимости Пароля".

mysql_upgrade теперь производит предупреждение, если он считает учетные записи пользователей с паролями хешированными с более старыми пред4.1 хеширующими методами. Такие учетные записи должны быть обновлены, чтобы использовать более безопасный хеширующий пароль. См. Раздел 6.1.2.4, "Пароль, Хеширующий в MySQL"

На платформах Unix mysql_install_db поддерживает новую опцию, --random-passwords, это предусматривает более безопасную установку MySQL. Вызов mysql_install_db с --random-passwords причины это, чтобы присвоить случайный пароль MySQL root учетные записи, набор "пароль истекший" флаг для тех учетных записей, и удаляют учетные записи MySQL анонимного пользователя. Для дополнительных деталей см. Раздел 4.4.3, "mysql_install_db — Каталог Данных MySQL Initialize".

Журналирование было изменено так, чтобы пароли не появились в простом тексте в операторах, записанных общему журналу запросов, медленному журналу запросов, и двоичному журналу. См. Раздел 6.1.2.3, "Пароли и Журналирование".

mysql клиент больше не регистрирует к его операторам файла истории, которые обращаются к паролям. См. Раздел 4.5.1.3, "Журналирование mysql" .

START SLAVE синтаксис был изменен, чтобы разрешить параметрам соединения быть определенными для того, чтобы соединиться с ведущим устройством. Это обеспечивает альтернативу хранению пароля в master.info файл. См. Раздел 13.4.2.5,"START SLAVE Синтаксис".

Можно создать FULLTEXT индексирует на InnoDB таблицы, и запрашивают их использующий MATCH() ... AGAINST синтаксис. Эта функция включает новый оператор поиска с расстоянием (@) и несколько новых параметров конфигурации и INFORMATION_SCHEMA таблицы: См. Раздел 14.2.3.12.3,"FULLTEXT Индексирует" для получения дополнительной информации.

Несколько ALTER TABLE операции могут быть выполнены, не копируя таблицу, без блокирования вставляет, обновляет, и удаляет к таблице, или обоим. Эти улучшения известны все вместе как онлайновый DDL. См. Раздел 5.5, "Онлайновый DDL для InnoDB Таблицы" для деталей.

У Вас есть больше гибкости, чтобы переместить.ibd файлы файлов, создаваемые в режиме файла на таблицу, чтобы удовлетворить Вашим устройствам хранения и серверам баз данных. Составляя таблицу, можно определять расположение вне каталога данных MySQL содержать .ibd файл, например чтобы поместить занятую таблицу в устройство SSD или огромную таблицу на устройстве HDD большой емкости. Можно экспортировать таблицу от одного экземпляра MySQL и импортировать его в различном экземпляре, без несогласованностей или несоответствий, вызванных буферизованными данными, происходящими транзакциями, и внутренними бухгалтерскими деталями, такими как ID пространства и LSN. См. Раздел 14.2.4.2.34, "Улучшенное управление Табличной областью" для деталей.

Можно теперь установить InnoDB размер страницы для несжатых таблиц к 8 Кбитам или 4 Кбитам, как альтернатива значению по умолчанию 16 Кбит. Этой установкой управляют innodb_page_size параметр конфигурации. Вы определяете размер, создавая экземпляр MySQL. Все InnoDB табличные области в пределах экземпляра совместно используют тот же самый размер страницы. Меньшие размеры страницы могут помочь избежать избыточного или неэффективного ввода-вывода для определенных комбинаций рабочей нагрузки и устройств хранения, особенно устройства SSD с маленькими размерами блока.

Улучшения алгоритмов для адаптивного сбрасывания делают операции ввода-вывода более эффективными и непротиворечивыми под множеством рабочих нагрузок. Новый алгоритм и значения конфигурации значения по умолчанию, как ожидают, улучшат производительность и параллелизм для большинства пользователей. Усовершенствованные пользователи могут подстроить свою скорость отклика ввода-вывода через несколько параметров конфигурации. См. Раздел 14.2.4.2.9, "Улучшения Сбрасывания Пула буферов" для деталей.

Можно кодировать приложения MySQL тот доступ InnoDB таблицы через API NoSQL-стиля. Эта функция использует популярного memcached демона для релейных запросов такой как ADD, SET, и GET для пар ключ/значение. Эти простые операции, чтобы сохранить и получить данные избегают издержек SQL, таких как парсинг и построение плана выполнения запроса. Можно получить доступ к тем же самым данным через API NoSQL и SQL. Например, Вы могли бы использовать API NoSQL для быстрых обновлений и поисков, и SQL для сложных запросов и совместимости с существующими приложениями. См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для деталей.

Статистика оптимизатора для InnoDB таблицы собираются в более предсказуемых интервалах и могут сохраниться через перезапуски сервера для улучшенной устойчивости плана. Можно также управлять количеством выборки сделанного для InnoDB индексирует, чтобы сделать статистику оптимизатора более точной и улучшить план выполнения запроса. См. Раздел 14.2.4.2.10, "Персистентная Статистика Оптимизатора для Таблиц InnoDB" для деталей.

Новая оптимизация применяется к транзакциям только для чтения, улучшая производительность и параллелизм для оперативных запросов и генерирующих отчет приложений. Эта оптимизация применяется автоматически когда практичный, или можно определить START TRANSACTION READ ONLY гарантировать транзакцию только для чтения. См. Раздел 14.2.4.2.3, "Оптимизация для Транзакций Только для чтения" для деталей.

Можно переместиться InnoDB отмените журнал из системной табличной области в одного или более отдельных табличных областей. Образцы ввода-вывода для журнала отмены делают эти новые табличные области хорошими кандидатами, чтобы переместиться в хранение SSD, сохраняя системную табличную область на хранении жесткого диска. Для получения дополнительной информации см. Раздел 14.2.4.2.4, "Отдельные Табличные области для Журналов Отмены InnoDB".

InnoDB у файлов журнала отката теперь есть максимальный объединенный размер 512 Гбайт, увеличенных с 4 Гбайт. Можно определить большие значения через innodb_log_file_size опция. Поведение запуска теперь автоматически обрабатывает ситуацию, где размер существующих файлов журнала отката не соответствует размер, определенный innodb_log_file_size и innodb_log_files_in_group.

--innodb-read-only опция позволяет Вам выполнять сервер MySQL в режиме только для чтения. Можно получить доступ InnoDB таблицы на носителях только для чтения, таких как DVD или CD, или установленный хранилище данных с многократными экземплярами все совместное использование того же самого каталога данных. См. Раздел 14.2.5.1, "Поддержка Носителей Только для чтения" для использования детализирует.

Несколько новые InnoDBСвязанный INFORMATION_SCHEMA таблицы предоставляют информацию о InnoDB пул буферов, метаданные о таблицах, индексирует, и внешние ключи от InnoDB словарь данных, и информация о низком уровне о метриках производительности, которая дополняет информацию от таблиц Схемы Производительности.

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

InnoDB имеет несколько улучшений собственной производительности, включая сокращение конкуренции, разделяя взаимное исключение ядра, перемещая сбрасывание операций от основного потока до отдельного потока, включение многократные потоки чистки, и сокращение конкуренции для пула буферов на системах памяти большой емкости.

InnoDB использует новый, более быстрый алгоритм, чтобы обнаружить мертвые блокировки. Информация обо всех InnoDB мертвые блокировки могут быть записаны журналу ошибок сервера MySQL, чтобы помочь диагностировать проблемы приложения.

Избегать долгого периода разминки после перезапуска сервера, особенно для экземпляров с большим InnoDB пулы буферов, можно перезагрузить страницы в пул буферов сразу после перезапуска. MySQL может вывести компактный файл данных на завершении работы, затем консультироваться с тем файлом данных, чтобы найти, что страницы перезагружают на следующем перезапуске. Можно также вручную вывести или перезагрузить пул буферов в любое время, например во время сравнительного тестирования или после сложных запросов генерации отчета. См. Раздел 14.2.4.2.8, "Более быстрый Перезапуск, Предварительно загружая Пул буферов InnoDB" для деталей.

Максимальное количество разделов увеличивается до 8192. Это число включает все разделы и все подразделы таблицы.

Теперь возможно обмениваться разделом разделенной таблицы или подразделом подразделенной таблицы с неразделенной таблицей, у которой иначе есть та же самая структура, используя ALTER TABLE ... EXCHANGE PARTITION оператор. Это может использоваться, например, чтобы импортировать и экспортировать разделы. Для получения дополнительной информации и примеры, см. Раздел 18.3.3, "Обмениваясь Разделами и Подразделами с Таблицами".

Явный выбор одного или более разделов или подразделов теперь поддерживается для запросов, так же как для многих операторов модификации данных, того действия на разделенных таблицах. Например, примите таблицу t с некоторым целочисленным столбцом c имеет 4 названные раздела p0, p1, p2, и p3. Затем запрос SELECT * FROM t PARTITION (p0, p1) WHERE c < 5 возвраты только те строки от разделов p0 и p1 для которого c меньше чем 5.

Следующие операторы поддерживают явный выбор раздела:

Для синтаксиса см. описания отдельных операторов. Для дополнительной информации и примеров, см. Раздел 18.5, "Выбор Раздела".

Блокировка раздела, сокращающая значительно, улучшает производительность многих, операторы DML и DDL, действующие на таблицы со многими разделами, помогая устранить, соединяют разделы, на которые не влияют эти операторы. Такие операторы включают многих SELECT, SELECT ... PARTITION, UPDATE, REPLACE, INSERT, так же как много других операторов. Для получения дополнительной информации, включая полный список операторов, производительность которых была таким образом улучшена, см. Раздел 18.6.4, "Деля и Блокируя".

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

Фильтрация событий таблицей, основанной на схеме и/или именах таблиц.

Фильтрация событий потоком. Больше информации собирается для потоков.

Сводные таблицы для таблицы и индексируют ввод-вывод, и для блокировок таблицы.

Инструментарий для операторов и этапов в пределах операторов.

Конфигурация инструментов и потребителей при запуске сервера, который ранее был возможен только во времени выполнения.

MySQL теперь поддерживает основанную на транзакции репликацию, используя глобальные идентификаторы транзакции (также известный как "GTIDs"). Это позволяет идентифицировать и отследить каждую транзакцию, когда она фиксируется на инициирующем сервере и поскольку она применяется любыми ведомыми устройствами.

Включение GTIDs в установке репликации делается, прежде всего используя новое --gtid-mode и --enforce-gtid-consistency параметры сервера. Для получения информации о дополнительных опциях и переменных, представленных в поддержку GTIDs, см. Раздел 16.1.4.5, "Глобальные Опции ID Транзакции и Переменные".

При использовании GTIDs не необходимо обратиться к файлам журнала или позициям в пределах тех файлов, запуская новое ведомое устройство или перестав работать новому ведущему устройству, которое значительно упрощает эти задачи. Для получения дополнительной информации о настройке серверов для репликации GTID с или не обращаясь к двоичным файлам журнала, см. Раздел 16.1.3.3, "Используя GTIDs для Failover и Scaleout".

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

Для более полной информации о реализации и использовании GTIDs в MySQL Replication, см. Раздел 16.1.3, "Репликация с Глобальными Идентификаторами транзакции".

Построчная репликация MySQL теперь поддерживает управление изображением строки. Регистрируя только те столбцы, требуемые для однозначного определения и выполняя изменения на каждой строке (в противоположность всем столбцам) для каждого изменения строки, возможно сохранить дисковое пространство, сетевые ресурсы, и использование памяти. Можно определить, или все или минимальные строки регистрируются, устанавливая binlog_row_image системная переменная сервера к одному из значений minimal (зарегистрируйте требуемые столбцы только), full (зарегистрируйте все столбцы), или noblob (зарегистрируйте все столбцы за исключением ненужного BLOB или TEXT столбцы). См. Системные переменные, используемые с двоичным журналом для получения дополнительной информации.

Двоичный файл регистрирует записанный, и читайте MySQL Server, теперь безопасны от катастрофического отказа, потому что только полные события (или транзакции) регистрируются или читают назад. По умолчанию сервер регистрирует длину события так же как события непосредственно и использует эту информацию, чтобы проверить, что событие было записано правильно. Можно также заставить сервер писать контрольные суммы для событий, используя контрольные суммы CRC32, устанавливая binlog_checksum системная переменная. Чтобы заставить сервер читать контрольные суммы из двоичного журнала, используйте master_verify_checksum системная переменная. --slave-sql-verify-checksum системная переменная заставляет ведомый поток SQL читать контрольные суммы из релейного журнала.

MySQL теперь поддерживает журналирование основной информации о соединении и ведомой релейной информации о журнале к таблицам так же как файлам. Использованием этих таблиц можно управлять независимо, --master-info-repository и --relay-log-info-repository параметры сервера. Установка --master-info-repository к TABLE информация о соединении причин, которая будет зарегистрирована slave_master_info таблица; установка --relay-log-info-repository к TABLE реле причин регистрирует информацию, которая будет зарегистрирована к slave_relay_log_info таблица. Обе из этих таблиц составляются автоматически, в mysql системная база данных.

Для репликации, чтобы быть безопасным от катастрофического отказа, slave_master_info и slave_relay_log_info таблицы должны каждый использовать транзакционный механизм хранения, и начинание с MySQL 5.6.6, эти таблицы составляются, используя InnoDB по этой причине. (Ошибка #13538891), Если Вы используете предыдущий выпуск MySQL 5.6, в котором обе из этих таблиц используют MyISAM, это означает, что до запускающейся репликации следует преобразовать их обоих в транзакционный механизм хранения (такой как InnoDB) если Вы хотите для репликации быть безопасными от катастрофического отказа. Можно сделать это в таких случаях посредством соответствующего ALTER TABLE ... ENGINE=... операторы. Недопустимо попытаться изменить механизм хранения, используемый любой из этих таблиц, в то время как репликация фактически работает.

у mysqlbinlog теперь есть возможность поддержать двоичный файл, входят в систему его исходный двоичный формат. Когда вызвано с --read-from-remote-server и --raw опции, mysqlbinlog соединяется с сервером, запрашивает файлы журнала, и пишет выходные файлы в том же самом формате как оригиналы. См. Раздел 4.6.8.3, "Используя mysqlbinlog, чтобы поддержать Двоичные Файлы журнала".

MySQL теперь поддерживает задержанную репликацию так, что, ведомый сервер сознательно отстает от ведущего устройства, по крайней мере, указанным количеством времени. Задержка значения по умолчанию составляет 0 секунд. Используйте новое MASTER_DELAY опция для CHANGE MASTER TO установить задержку.

Задержанная репликация может использоваться в целях, таких как защита от пользовательских ошибок на ведущем устройстве (DBA может откатывать задержанное ведомое устройство времени как раз перед бедствием), или тестирование, как система ведет себя, когда есть задержка. См. Раздел 16.3.9, "Задержанная Репликация".

Ведомое устройство репликации, имеющее многократные сетевые интерфейсы, может теперь быть заставлено использовать только один из них (исключая другие) при использовании MASTER_BIND опция, выходя a CHANGE MASTER TO оператор.

log_bin_basename системная переменная была добавлена. Эта переменная содержит полное имя файла и путь к двоичному файлу журнала. Принимая во внимание, что log_bin системная переменная показывает только, включается ли двоичное журналирование, log_bin_basename отражает набор имени с --log-bin параметр сервера.

Точно так же relay_log_basename системная переменная показывает имя файла и полный путь к релейному файлу журнала.

MySQL Replication теперь поддерживает параллельное выполнение транзакций с многопоточностью на ведомом устройстве. Когда параллельное выполнение включается, ведомые действия потока SQL как координатор для многих потоков раба как определено значением slave_parallel_workers системная переменная сервера. Текущая реализация многопоточности на ведомом устройстве предполагает, что данные и обновления делятся на основе для каждой базы данных, и что обновления в пределах данной базы данных происходят в том же самом относительном порядке, как они делают на ведущем устройстве. Однако, не необходимо скоординировать транзакции между различными базами данных. Транзакции могут тогда также быть распределены для каждой базы данных, что означает, что рабочий поток на ведомом ведомом устройстве может обработать последовательные транзакции на данной базе данных, не ожидая обновлений к другим базам данных, чтобы завершиться.

Так как транзакции на различных базах данных могут произойти в различном порядке на ведомое устройство чем на ведущем устройстве, просто проверяющий на последний раз выполняемую транзакцию не гарантия, что все предыдущие транзакции на ведущем устройстве были выполнены на ведомом устройстве. У этого есть импликации для журналирования и восстановления при использовании многопоточного ведомого устройства. Для получения информации о том, как интерпретировать двоичную информацию о журналировании при использовании многопоточности на ведомом устройстве, см. Раздел 13.7.5.35,"SHOW SLAVE STATUS Синтаксис".

Оптимизатор теперь более эффективно обрабатывает запросы (и подзапросы) следующей формы:

SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

Тот тип запроса распространен в веб-приложениях, которые выводят на экран только несколько строк от большего набора результатов. Например:

SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

У буфера вида есть размер sort_buffer_size. Если элементы вида для N строки являются достаточно небольшими, чтобы поместиться в буфер вида (M+N строки, если M был определен), сервер может избегать использования файла слияния и выполнить вид полностью в памяти. Для получения дополнительной информации см. Раздел 8.2.1.3, "Оптимизируя LIMIT Запросы".

Оптимизатор реализует Дисковую развертку Многодиапазонное Чтение. Чтение строк, используя сканирование диапазона на вторичном устройстве индексирует, может привести ко многим случайным доступам к диску к базовой таблице, когда таблица является большой и не сохраненная в кэше механизма хранения. С Дисковой разверткой Многодиапазонное Чтение (MRR) оптимизация MySQL пытается сократить количество случайного доступа к диску для сканирований диапазона первым сканированием индексирования только и сбором ключей для соответствующих строк. Затем ключи сортируются, и наконец строки получаются из базовой таблицы, используя порядок первичного ключа. Побуждение для Дисковой развертки MRR должно сократить количество случайных доступов к диску и вместо этого достигнуть более последовательного сканирования данных базовой таблицы. Для получения дополнительной информации см. Раздел 8.13.11, "Многодиапазонная Оптимизация Чтения".

Реализации оптимизатора Индексируют Условие Pushdown (ICP), оптимизация для случая, где MySQL получает строки от таблицы, используя индексирование. Без ICP механизм хранения пересекает индексирование, чтобы определить местоположение строк в базовой таблице и возвращает их серверу MySQL, который оценивает WHERE условие для строк. С ICP, включенным, и если части WHERE условие может быть оценено при использовании только полей от индексирования, сервер MySQL продвигает эту часть WHERE условие вниз к механизму хранения. Механизм хранения тогда оценивает продвинутый, индексируют условие при использовании элемента индекса и только если это удовлетворяется, основная строка быть считанным. ICP может сократить количество доступов, которые механизм хранения должен сделать против базовой таблицы и числа доступов, которые сервер MySQL должен сделать против механизма хранения. Для получения дополнительной информации см. Раздел 8.13.4, "Индексируйте Кондайшн Пушдаун Оптимизэйшн".

EXPLAIN оператор теперь предоставляет информацию о плане выполнения для DELETE, INSERT, REPLACE, и UPDATE операторы. Ранее, EXPLAIN предоставленная информация только для SELECT операторы. Кроме того, EXPLAIN оператор теперь может произвести вывод в формате ДЖСОНА. См. Раздел 13.8.2,"EXPLAIN Синтаксис".

Оптимизатор более эффективно обрабатывает подзапросы в FROM пункт (то есть, полученные таблицы). Материализация подзапросов в FROM пункт откладывается, пока их содержание не необходимо во время выполнения запроса, которое улучшает производительность. Кроме того, во время выполнения запроса, оптимизатор может добавить индексирование к полученной таблице, чтобы ускорить извлечение строки от этого. Для получения дополнительной информации см. Раздел 8.13.16.3, "Оптимизируя Подзапросы в FROM Пункт (Полученные Таблицы)".

Оптимизатор использует полуобъединение и стратегии материализации оптимизировать выполнение подзапроса. См. Раздел 8.13.16.1, "Оптимизируя Подзапросы с Преобразованиями Полуобъединения", и Раздел 8.13.16.2, "Оптимизируя Подзапросы с Материализацией Подзапроса".

Пакетный доступ по ключу (BKA), алгоритм соединения теперь доступен, который использует и индексирует доступ к объединяемой таблице и буферу соединения. Алгоритм BKA поддерживает внутреннее объединение, внешнее объединение, и операции полуобъединения, включая вложенные внешние объединения и вложенные полуобъединения. Преимущества BKA включают улучшенную производительность соединения из-за более эффективного табличного сканирования. Для получения дополнительной информации см. Раздел 8.13.12, "Блокируйте Соединения Вложенного цикла и Пакетного доступа по ключу".

У оптимизатора теперь есть возможность трассировки, прежде всего для использования разработчиками. Интерфейс обеспечивается рядом optimizer_trace_xxx системные переменные и INFORMATION_SCHEMA.OPTIMIZER_TRACE таблица. Для получения дополнительной информации см. MySQL Internals: Трассировка Оптимизатора.

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

Приоритет условия более точно разрешается.

Очистка области диагностики изменилась. Ошибка #55843 вызванные обработанные условия, которые будут очищены от области диагностики прежде, чем активировать обработчик. Эта сделанная информация об условии, недоступная в пределах обработчика. Теперь информация об условии доступна обработчику, который может осмотреть ее с GET DIAGNOSTICS оператор. Информация об условии очищается, когда обработчик выходит, если это не было уже очищено во время выполнения обработчика.

Ранее, обработчики были активированы, как только условие произошло. Теперь они не активируются до оператора, в котором условие произошло выполнение концов, при которой точке выбирается самый соответствующий обработчик. Это может иметь значение для операторов, которые повышают многократные условия, если у условия, повышенного позже во время выполнения оператора, есть более высокий приоритет чем более раннее условие и есть обработчики в том же самом контексте для обоих условий. Ранее, обработчик для первого повышенного условия был бы выбран, даже если бы у этого был более низкий приоритет чем другие обработчики. Теперь обработчик для условия с наивысшим приоритетом выбирается, даже если это не первое условие, повышенное оператором.

MySQL теперь разрешает доли секунды для TIME, DATETIME, и TIMESTAMP значения, с до микросекунд (6 цифр) точность. См. Раздел 11.3.6, "Доли секунды во Временных стоимостях".

Ранее, самое большее один TIMESTAMP столбец на таблицу мог быть автоматически инициализирован или обновлен к текущей дате и время. Это ограничение было снято. Любой TIMESTAMP у определения столбца может быть любая комбинация DEFAULT CURRENT_TIMESTAMP и ON UPDATE CURRENT_TIMESTAMP пункты. Кроме того, эти пункты теперь могут использоваться с DATETIME определения столбца. Для получения дополнительной информации см. Раздел 11.3.5, "Автоматическая Инициализация и Обновляющий для TIMESTAMP и DATETIME".

В MySQL, TIMESTAMP тип данных отличается нестандартными способами от других типов данных с точки зрения значения по умолчанию и присвоения автоматической инициализации и атрибутов обновления. Эти поведения остаются значением по умолчанию, но теперь осуждаются, и могут быть выключены, включая explicit_defaults_for_timestamp системная переменная при запуске сервера. См. Раздел 11.3.5, "Автоматическая Инициализация и Обновляющий для TIMESTAMP и DATETIME", и Раздел 5.1.4, "Системные Переменные Сервера".

YEAR(2) тип данных теперь осуждается. YEAR(2) столбцы в существующих таблицах обрабатываются как прежде, но YEAR(2) в новых или измененных таблицах преобразовываются в YEAR(4). Для получения дополнительной информации см. Раздел 11.3.4,"YEAR(2) Ограничения и Переходящий на YEAR(4)".

Новый Connection_errors_xxx переменные состояния предоставляют информацию об ошибках соединения, которые не применяются к определенным клиентским IP-адресам.

Счетчики были добавлены к кэшу узла к дефектам записи, которые действительно применяются к определенным IP-адресам, и новому host_cache Таблица Схемы производительности представляет содержание кэша узла так, чтобы это могло быть исследовано, используя SELECT операторы. Доступ, чтобы разместить содержание кэша позволяет ответить на вопросы такой как, сколько узлов кэшируется, какие виды ошибок соединения происходят, для которого узлы, или как близко размещают ошибочные количества, к достижению max_connect_errors системный предел переменной.

Размер кэша узла теперь является конфигурируемым использованием host_cache_size системная переменная.