Приложение A. MySQL 8.0 Frequently Asked Questions


WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233	Visa 4274 3200 2453 6495

Приложение A. MySQL 8.0 Frequently Asked Questions

A.1. MySQL 8.0 FAQ: Общие вопросы

A.1.1.

Какая версия MySQL готовая (GA)?

MySQL 5.7 и MySQL 5.6 поддержаны для производственного использования.

MySQL 5.7 имеет состояние General Availability (GA) с MySQL 5.7.9, который был выпущен для производственного использования 21 октября 2015.

MySQL 5.6 имеет состояние General Availability (GA) с MySQL 5.6.10, который был выпущен для производственного использования 5 февраля 2013.

MySQL 5.5 имеет состояние General Availability (GA) с MySQL 5.5.8, который был выпущен для производственного использования 3 декабря 2010. MySQL 5.5 больше не актуален, но все еще поддержан.

MySQL 5.1 имеет состояние General Availability (GA) с MySQL 5.1.30, который был выпущен для производственного использования 14 ноября 2008. Активное развитие MySQL 5.1 закончилось.

MySQL 5.0 имеет состояние General Availability (GA) с MySQL 5.0.15, который был выпущен для производственного использования 19 октября 2005. Активное развитие MySQL 5.0 закончилось.

A.1.2.

Каково состояние разрабатываемых (non-GA) версий?

MySQL следует модели выпуска, которая вводит особенности "предпроизводственного качества" и стабилизирует их, чтобы выпустить окончательную версию (см. http://dev.mysql.com/doc/mysql-development-cycle/en/index.html ). Пожалуйста, проверьте журналы изменений, чтобы идентифицировать состояние конкретного выпуска.

MySQL 5.4 был версией для разработчиков. Работа над ним прекращена.

Преемник MySQL 5.7 активно развивается, используя методологию выпуска, описанную выше.

A.1.3.

Может MySQL 8.0 делать подзапросы?

Да. См. раздел 14.2.10.

A.1.4.

Может MySQL 8.0 делать мультитабличные вставки, обновления и удаления?

Да. Для синтаксиса, требуемого для этого, см. разделы 14.2.11 и 14.2.2.

Мультитабличная вставка может быть достигнута, используя триггер с предложением FOR EACH ROW, содержащим много запросов INSERT в пределах блока BEGIN ... END. См. раздел 21.3.

A.1.5.

У MySQL 8.0 есть кэш запроса? Это работает для сервера или базы данных?

Да. Кэш запроса работает на уровне сервера, кэшируя полные наборы результатов, соответствующие оригинальной строке запроса. Если точно идентичный запрос сделан (что часто происходит, особенно в веб-приложениях), никакой парсинг или выполнение не необходимы: результат посылается непосредственно из кэша. Различные настраивающие опции доступны. См. раздел 9.10.3.

A.1.6.

У MySQL 8.0 есть последовательности (Sequences)?

Нет. Однако, MySQL имеет систему AUTO_INCREMENT, которая в MySQL 8.0 может также обработать вставки в репликации с несколькими ведущими системами. Используя системные переменные auto_increment_increment и auto_increment_offset Вы можете установить каждый сервер, чтобы произвести значения автоинкремента, которые не находятся в противоречии с другими серверами. Значение auto_increment_increment должно быть больше, чем число серверов, и у каждого сервера должно быть уникальное смещение.

A.1.7.

Имеет ли MySQL 8.0 функцию NOW() с долями секунд?

Да. См. раздел 12.3.6.

A.1.8.

MySQL 8.0 работает с мультиядерными процессорами?

Да. MySQL полностью многопоточный и использует много процессоров при условии, что операционная система поддерживает их.

A.1.9.

Почему я вижу много процессов для mysqld?

Используя LinuxThreads, Вы должны видеть минимум три процесса mysqld. Это фактически потоки. Есть один поток для менеджера LinuxThreads, один поток, чтобы обработать соединения, и один поток, чтобы обработать аварийные сигналы.

A.1.10.

Может MySQL 8.0 выполнять ACID-транзакции?

Да. Все текущие версии MySQL поддерживают транзакции. Механизм хранения InnoDB предлагает полные ACID-транзакции с блокировкой на уровне строки, multi-versioning, повторимыми чтениями без блокировки и всеми четырьмя стандартными уровнями изоляции SQL.

Механизм хранения The NDB поддерживает только операционный уровень изоляции READ COMMITTED.

A.2. MySQL 8.0 FAQ: механизмы хранения

A.2.1.
Где я могу получить полную документацию для механизмов хранения MySQL?

См. главу 17. Та глава содержит информацию обо всех механизмах хранения MySQL за исключением NDB, который используется для MySQL Cluster. NDB описан в MySQL Cluster NDB 7.5.

A.2.2.

Есть ли какие-либо новые механизмы хранения в MySQL 8.0?

Нет. InnoDB механизм хранения по умолчанию для новых таблиц. См. раздел 16.1.

A.2.3.

Какие-либо механизмы хранения были удалены в MySQL 8.0?

Нет.

A.2.4.

Что является уникальной выгодой механизма хранения ARCHIVE?

Механизм хранения ARCHIVE идеально подходит для того, чтобы сохранить большие объемы данных без индексов: это имеет очень маленькие накладные расходы и выполняет выборки сканированием таблицы. См. раздел 17.5.

A.2.5.

Новые особенности в MySQL 8.0 относятся ко всем механизмам хранения?

Общие новые особенности, такие как обзоры, хранимые процедуры, триггеры, INFORMATION_SCHEMA, точная математика (тип столбца DECIMAL) и столбцы типа BIT, применяются ко всем механизмам хранения. Есть также дополнения и изменения для определенных механизмов хранения.

A.3. MySQL 8.0 FAQ: Режимы SQL

A.3.1.

Что такое режимы SQL?

Hежимы SQL определяют то, что должен поддерживать синтаксис SQL в MySQL и какое подтверждение правильности данных требуется. Это облегчает использование MySQL в различной окружающей среде и вместе с другими серверами базы данных. Сервер MySQL применяет эти режимы индивидуально к различным клиентам. Для получения дополнительной информации см. раздел 6.1.8.

A.3.2.
Сколько режимов SQL?

Каждый режим может быть независимо включен. См. раздел 6.1.8.

A.3.3.

Как Вы определяете режим SQL?

Вы можете установить режим SQL по умолчанию (для запуска mysqld) опцией --sql-mode . Используя SET [GLOBAL|SESSION] sql_mode='modes', Вы можете изменить настройки изнутри соединения. Вы можете получить текущий режим запросом SELECT @@sql_mode.

A.3.4.

Действительно ли режим зависит от базы данных или соединения?

Режим не связан с базой данных. Режимы могут быть установлены в местном масштабе для сеанса (соединения) или глобально для сервера. Вы можете изменить эти настройки через использование SET [GLOBAL|SESSION] sql_mode='modes'.

A.3.5.

Могут ли правила для строгого режима быть расширены?

Когда мы обращаемся к строгому режиму, мы имеем в виду режим где по крайней мере один из режимов TRADITIONAL, STRICT_TRANS_TABLES или STRICT_ALL_TABLES включен. Опции могут быть объединены, таким образом, Вы можете добавить ограничения на режим. См. раздел 6.1.8.

A.3.6.

Строгий режим воздействует на производительность?

Интенсивная проверка допустимости входных данных требует большего количества времени, чем если бы проверка допустимости не была сделана. Если Вы не требуете такой проверки допустимости (возможно, Ваше приложение уже обрабатывает все это), то MySQL дает Вам опцию отключения строгого режима. Однако, если Вы действительно требуете проверку данных, строгий режим может обеспечить такую проверку допустимости.

A.3.7.
Каков по умолчанию режим SQL, когда MySQL 8.0 установлен?

Значение по умолчанию режима SQL в MySQL 8.0 включает эти режимы: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE , NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER и NO_ENGINE_SUBSTITUTION.

A.4. MySQL 8.0 FAQ: Хранимые процедуры и функции

A.4.1.

MySQL 8.0 поддерживает хранимые процедуры и функции?

Да. MySQL 8.0 поддерживает хранимые процедуры и функции.

A.4.2.

Где я могу найти документацию для хранимых процедур MySQL?

См. раздел 21.2.

A.4.3.

Есть ли дискуссионный форум для хранимых процедур MySQL?

Да. См. http://forums.mysql.com/list.php?98.

A.4.4.

Где я могу найти спецификацию ANSI SQL 2003 для хранимых процедур?

К сожалению, официальные технические требования не в свободном доступе (ANSI делает их доступными для покупки). Однако, есть такие книги, как SQL-99 Complete, Really by Peter Gulutzan and Trudy Pelzer, которые обеспечивают всесторонний краткий обзор стандарта, включая освещение хранимых процедур.

A.4.5.

Как Вы управляете сохраненными функциями?

Всегда хорошая практика использовать ясную схему именования для Ваших сохраненных процедур. Вы можете управлять хранимыми процедурами с помощью CREATE [FUNCTION|PROCEDURE], ALTER [FUNCTION|PROCEDURE], DROP [FUNCTION|PROCEDURE] и SHOW CREATE [FUNCTION|PROCEDURE]. Вы можете получить информацию о существующих хранимых процедурах, используя таблицу ROUTINES в базе данных INFORMATION_SCHEMA (см. раздел 22.19).

A.4.6.

Есть способ рассмотреть все хранимые процедуры и сохраненные функции в данной базе данных?

Да. Для базы данных dbname используйте этот запрос на таблице INFORMATION_SCHEMA.ROUTINES:
SELECT ROUTINE_TYPE, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA='dbname';

Тело сохраненной процедуры может быть рассмотрено, используя SHOW CREATE FUNCTION (для функций) или SHOW CREATE PROCEDURE (для процедур). См. раздел 14.7.5.9.

A.4.7.

Где хранимые процедуры сохранены?

Хранимые процедуры сохранены в таблицах mysql.routines и mysql.parameters, которые являются частью словаря данных. Вы не можете получить доступ к этим таблицам непосредственно. Вместо этого запросите из INFORMATION_SCHEMA таблицы ROUTINES и PARAMETERS.

Вы можете также использовать SHOW CREATE FUNCTION, чтобы получить информацию о сохраненных функциях, и SHOW CREATE PROCEDURE, чтобы получить информацию о хранимых процедурах. См. раздел 14.7.5.9.

A.4.8.

Действительно ли возможно сгруппировать хранимые процедуры или сохраненные функции в пакеты?

Нет. Это не поддерживается в MySQL 8.0.

A.4.9.

Хранимая процедура может вызвать другую хранимую процедуру?

Да.

A.4.10.

Хранимая процедура может вызвать триггер?

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

A.4.11.

Действительно ли хранимая процедура может получить доступ к таблицам?

Да. Хранимая процедура может получить доступ к одной или более таблицам, как ей требуется.

A.4.12.

У хранимых процедур есть запрос для того, чтобы создать ошибку приложения?

Да. MySQL 8.0 реализует стандартные SQL-запросы SIGNAL и RESIGNAL. См. раздел 14.6.7.

A.4.13.

Хранимые процедуры обеспечивают обработку исключения?

MySQL реализует определения HANDLER согласно стандарту SQL. См. раздел 14.6.7.2.

A.4.14.

Может сохраненная процедура в MySQL 8.0 возвращать наборы результатов?

Сохраненная процедура да, сохраненная функция нет. Если Вы выполняете одиночный SELECT в хранимой процедуре, набор результатов возвращен непосредственно клиенту. Вы должны использовать для этого протокол клиент-сервер MySQL 4.1 (или выше). Это означает, что, например, в PHP Вы должны использовать расширение mysqli, а не старое mysql.

A.4.15.

Is WITH RECOMPILE поддержан для хранимых процедур?

Не в MySQL 8.0.

A.4.16.

Есть ли MySQL-эквивалент использованию mod_plsql как шлюз к Apache, чтобы работать непосредственно с хранимой процедурой в базе данных?

Нет эквивалента в MySQL 8.0.

A.4.17.

Я могу передать массив как ввод хранимой процедуре?

Не MySQL 8.0.

A.4.18.

Могу я передавать курсор как параметр IN хранимой процедуре?

В MySQL 8.0 курсоры доступны только внутри хранимых процедур.

A.4.19.

Могу я возвращать курсор как параметр OUT из хранимой процедуры?

В MySQL 8.0 курсоры доступны только внутри хранимых процедур. Однако, если Вы не открываете курсор на SELECT, результат пошлют непосредственно клиенту. Вы можете также направить SELECT INTO в переменные. См. раздел 14.2.9.

A.4.20.

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

Да, Вы можете сделать это в хранимой процедуре, но не в сохраненной функции. Если Вы выполняете одиночный SELECT в хранимой процедуре, набор результатов возвращен непосредственно клиенту. Вы должны будете использовать для этого протокол клиент-сервер MySQL 4.1 (или выше).

A.4.21.

Я могу передать или отменить транзакцию в хранимой процедуре?

Да. Однако, Вы не можете выполнить транзакционные действия в пределах сохраненной функции.

A.4.22.

В MySQL 8.0 хранимые процедуры и функции работают с репликацией?

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

A.4.23.

Хранимые процедуры и функции создаются на главном сервере, копируемом на ведомый?

Да, создание хранимых процедур и функций, выполнено через нормальные запросы DDL о главном сервере, поэтому они скопируются на ведомый, таким образом, объекты будут существовать на обоих серверах. ALTER и DROP для хранимых процедур и функций также копируются.

A.4.24.

Как действия, которые имеют место в хранимых процедурах и копируемых функциях, реплицируются?

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

Сохраненные функции, которые изменяют данные, зарегистрированы как запросы, а не как события DML, которые происходят в каждой функции.

A.4.25.

Есть ли специальные требования безопасности для того, чтобы использовать хранимые процедуры и функции вместе с репликацией?

Да. Поскольку у ведомого сервера есть полномочия выполнить любой запрос, считанный из двоичного журнала ведущего устройства, специальные ограничения безопасности существуют для того, чтобы использовать сохраненные функции с репликацией. Если репликация или двоичный журнал вообще (с целью восстановления момента времени), являются активными, MySQL DBA имеет две опции безопасности, открытые для них:

Любому пользователю, желающему создать сохраненные функции, нужно предоставить привилегию SUPER.

Альтернативно DBA может установить системную переменную log_bin_trust_function_creators в 1, что позволяет любому со стандартной привилегией CREATE ROUTINE создать сохраненные функции.

A.4.26.

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

Недетерминированные (случайные) или основанные на времени действия, встроенные в хранимые процедуры, возможно, не копируются должным образом. По самому их характеру результаты, к которым они приводят, непредсказуемы и не могут быть точно воспроизведены, поэтому, случайные действия, копируемые ведомому устройству, не будут зеркально отражать выполненные на ведущем устройстве. Объявление сохраненных функций DETERMINISTIC или установка переменной log_bin_trust_function_creators в 0 не будет позволять случайно оцененным операциям быть вызванными.

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

Наконец, нетранзакционные таблицы, для которых ошибки происходят во время больших действий DML (таких, как большая вставка) могут испытать проблемы репликации, в которых ведущее устройство может быть частично обновлено от деятельности DML, но никакие обновления не сделаны на ведомом устройстве из-за ошибок. Обходное решение для действий функции DML, которые будут выполнены с ключевым словом IGNORE, чтобы обновления на ведущем устройстве, которые вызывают ошибки, были проигнорированы, а обновления, которые не вызывают ошибки, копируются к ведомому устройству.

A.4.27.

Предыдущие ограничения затрагивают способность MySQL сделать восстановление момента времени?

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

A.4.28.

Что делать, чтобы исправить вышеупомянутые ограничения?

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

Смешанная репликация также доступна (запуская сервер с --binlog-format=mixed). Этот гибрид, умная форма репликации, динамически определяет, может ли репликация на уровне запроса безопасно использоваться или требуется репликация на уровне строки.

A.5. MySQL 8.0 FAQ: Триггеры

A.5.1.
Где я могу найти документацию для триггеров в MySQL 8.0?

См. раздел 21.3.

A.5.2.

Есть дискуссионный форум для триггеров в MySQL?

Да. http://forums.mysql.com/list.php?99.

A.5.3.

У MySQL 8.0 есть триггеры на уровне строки или на уровне запроса?

В MySQL 8.0 все триггеры FOR EACH ROW то есть, триггер активирован для каждой строки, которая вставлена, обновлена или удалена. MySQL 8.0 не поддерживает использование триггеров FOR EACH STATEMENT.

A.5.4.

Есть ли какие-либо триггеры по умолчанию?

Не явно. У MySQL действительно есть определенное специальное поведение для некоторых столбцов TIMESTAMP, так же как для столбцов, которые определены, используя AUTO_INCREMENT.

A.5.5.

Как управлять триггерами в MySQL?

В MySQL 8.0 триггеры могут быть созданы, используя CREATE TRIGGER, и удалены через DROP TRIGGER. См. разделы 14.1.17 и 14.1.27.

Информация о триггерах может быть получена, запрашивая таблицу INFORMATION_SCHEMA.TRIGGERS .

A.5.6.

Есть способ рассмотреть все триггеры в базе данных?

Да. Вы можете получить перечисление всех триггеров, определенных в базе данных dbname с использованием запроса в таблице INFORMATION_SCHEMA.TRIGGERS как показано здесь:
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA='dbname';

Вы можете также использовать запрос SHOW TRIGGERS, который является специфичным для MySQL. См. раздел 14.7.5.38.

A.5.7.

Где сохранены триггеры?

Триггеры сохранены в системной таблице mysql.triggers, которая является частью словаря данных.

A.5.8.

Триггер может вызвать хранимую процедуру?

Да.

A.5.9.

Действительно ли триггеры могут получить доступ к таблицам?

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

A.5.10.

У таблицы может быть много триггеров с тем же самым событием и временем действия?

В MySQL 8.0 возможно определить много триггеров для данной таблицы, у которых есть то же самое событие и время действия. Например, Вы можете иметь два триггера BEFORE UPDATE для таблицы. По умолчанию триггеры, у которых есть то же самое событие и время действия, активируются в порядке, в котором они создавались. Чтобы затронуть более аккуратный порядок, определите пункт после FOR EACH ROW, который указывает FOLLOWS или PRECEDES и название существующего триггера, у которого есть то же самое событие и время действия. С FOLLOWS новый триггер активируется после существующего. С PRECEDES до него.

A.5.11.

Триггеры могут вызвать внешнее приложение через UDF?

Да. Например, триггер мог вызвать sys_exec() UDF.

A.5.12.

Действительно ли возможно обновить триггером таблицы на удаленном сервере?

Да. Таблица на удаленном сервере могла быть обновлена, используя механизм хранения FEDERATED. См. раздел 17.8.

A.5.13.

Триггеры работают с репликацией?

Да. Однако, путь, которым они работают, зависит от того, используете ли Вы классическую репликацию MySQL, основанную на запросе, доступную во всех версиях MySQL, или основанную на строке, введенную в MySQL 5.1.

Используя основанную на запросе репликацию, триггеры на ведомом устройстве выполнены запросами, которые выполнены на ведущем устройстве (и копируются к ведомому устройству).

Используя основанную на строке репликацию, триггеры не выполнены на ведомом устройстве из-за запросов, которые были выполнены на ведущем устройстве и затем копировались к ведомому устройству. Вместо этого, используя основанную на строке репликацию, изменения, вызванные, выполняя триггер на ведущем устройстве, применены на ведомом устройстве.

A.5.14.

Как действия, выполненные через триггер на ведущем устройстве, копируются на ведомое устройство?

Снова, это зависит от того, используете ли Вы классическую репликацию MySQL, основанную на запросе, доступную во всех версиях MySQL, или основанную на строке, введенную в MySQL 5.1.

Основанная на запросе репликация. Во-первых, триггеры, которые существуют на ведущем устройстве, должны быть обновлены на ведомом сервере. Как только это сделано, поток репликации работает как любой другой стандартный запрос DML, который участвует в репликации. Например, рассмотрите таблицу EMP, которая имеет триггер AFTER на insert, который существует на сервере ведущего устройства MySQL. Те же самые таблица EMP и триггер AFTER существуют также и на ведомом сервере. Поток рпеликации был бы:

Запрос INSERT сделан на EMP.

Активирован триггер AFTER на EMP.

INSERT записан в двоичный журнал.

Ведомое устройство выполняет INSERT на EMP.

Триггер AFTER на EMP, который существует на ведомом устройстве, активируется.

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

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

A.6. MySQL 8.0 FAQ: Views

A.6.1.
Где я могу найти документацию о MySQL Views?

См. раздел 21.5.

A.6.2.

Есть дискуссионный форум для MySQL Views?

Да. http://forums.mysql.com/list.php?100

A.6.3.

Что происходит с представлением, если основная таблица удалена или переименована?

После того, как представление было создано, возможно удалить или изменить таблицу или представление, к которому относится определение. Чтобы проверить определение представления на проблемы этого вида, используйте запрос CHECK TABLE.

A.6.4.

У MySQL 8.0 есть табличные снимки?

Нет.

A.6.5.

MySQL 8.0 имеет осуществленные представления?

Нет.

A.6.6.

Вы можете вставить в представления, которые основаны на объединениях?

Это возможно, при условии, что Ваш запрос INSERT имеет список столбцов, который проясняет, что есть только одна вовлеченная таблица.

Вы не можете вставить в много таблиц с единственной вставкой на представлении.

A.7. MySQL 8.0 FAQ: INFORMATION_SCHEMA

A.7.1.

Где я могу найти документацию для базы данных MySQL INFORMATION_SCHEMA?

См. главу 22.

A.7.2.

Есть ли дискуссионный форум для INFORMATION_SCHEMA?

http://forums.mysql.com/list.php?101.

A.7.3.

Где можно прочитать спецификацию ANSI SQL 2003 для INFORMATION_SCHEMA?

К сожалению, официальные технические требования не в свободном доступе (ANSI делает их доступными для покупки). Однако, есть такие доступные книги, как SQL-99 Complete, Really by Peter Gulutzan and Trudy Pelzer, которые обеспечивают всесторонний краткий обзор стандарта, включая INFORMATION_SCHEMA.

A.7.4.

Что является различием между Oracle Data Dictionary и MySQL INFORMATION_SCHEMA?

Оба обеспечивают метаданные в таблицах. Однако, Oracle и MySQL используют различные имена таблиц и имена столбцов. Выполнение MySQL более подобно DB2 и SQL Server, которые также поддерживают INFORMATION_SCHEMA как определено в стандарте SQL.

A.7.5.

Могу я добавлять или иначе изменять таблицы в базе данных INFORMATION_SCHEMA?

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

A.8. MySQL 8.0 FAQ: Миграция

A.8.1.
Где я могу найти информацию о том, как мигрировать с MySQL 5.7 на MySQL 8.0?

Для подробной информации об обновлении см. раздел 2.10.1. Не пропускайте главную версию, обновляя, а завершайте процесс по шагам, обновляя от одной главной версии до следующей на каждом шаге. Это может казаться более сложным, но это будет экономить время и поможет избежать проблем. Если Вы столкнетесь с проблемами во время обновления, то их происхождение будет легче идентифицировать Вам или, если у Вас есть подписка MySQL Enterprise, поддержкой MySQL.

A.8.2.

Как поддержка механизмов хранения (типов таблиц) изменилась в MySQL 8.0?

Поддержка механизма хранения изменилась следующим образом:

Поддержка таблиц ISAM удалена в MySQL 5.0, и Вы должны теперь использовать MyISAM вместо ISAM. Преобразовать таблицу tblname из ISAM в MyISAM просто:
ALTER TABLE tblname ENGINE=MYISAM;

Внутренний RAID для MyISAM был также удален в MySQL 5.0. Это прежде использовалось, чтобы позволить большие таблицы в файловых системах, которые не поддерживали размеры файла больше 2GB. Все современные файловые системы учитывают большие таблицы, кроме того, есть теперь другие решения, например, MERGE и views.

Тип столбца VARCHAR теперь сохраняет конечные пробелы во всех механизмах хранения.

Таблицы MEMORY (прежде известные как HEAP) могут также содержать столбцы VARCHAR.

A.9. MySQL 8.0 FAQ: Безопасность

A.9.1.
Где я могу найти документацию, которая обращается к вопросам безопасности для MySQL?

Лучшим местом, чтобы начать является Глава 7.

Другие части документации MySQL, которую Вы можете счесть полезным относительно определенных проблем безопасности, включают следующее:

Раздел 7.1.1.

Раздел 7.1.3.

Раздел B.5.3.2.

Раздел 7.1.5.

Раздел 26.4.2.6.

Раздел 7.1.4.

Раздел 7.1.6.

Раздел 2.9.

Раздел 7.4.

A.9.2.

MySQL 8.0 имеет поддержку SSL?

У большинства двоичных модулей 8.0 есть поддержка соединений SSL между клиентом и сервером. См. раздел 7.4.

Вы можете также туннелировать соединение, используя SSH, если (например) приложение-клиент не поддерживает соединения SSL. Для примера см. раздел 7.4.7.

A.9.3.

Поддержка SSL встроена в двоичные модули или я должен повторно собрать пакет самостоятельно, чтобы включить ее?

Двоичные файлы 8.0 имеют SSL для соединений клиент-сервер, которые безопасны, авторизованы или то и другое сразу. См. раздел 7.4.

A.9.4.

У MySQL 8.0 есть встроенная аутентификация для LDAP?

Версия Enterprise включает PAM Authentication Plugin, который поддерживает аутентификацию по LDAP.

A.9.5.

MySQL 8.0 включают поддержку Roles Based Access Control (RBAC)?

Нет.

A.10. MySQL 8.0 FAQ: MySQL Cluster

В следующем разделе мы отвечаем на вопросы, которые часто спрашивают о MySQL Cluster и механизме хранения NDB.

A.10.1.

Какие версии программного обеспечения MySQL поддерживают Cluster? Я должен собрать из исходных текстов?

MySQL Cluster не поддержан в MySQL Server 8.0. Вместо этого MySQL Cluster выпущен как отдельный продукт, доступный как MySQL Cluster NDB 7.3 и MySQL Cluster NDB 7.4. Вы должны использовать MySQL Cluster NDB 7.4 для нового развертывания и запланировать обновление, если Вы используете предыдущую версию MySQL Cluster. Для краткого обзора усовершенствований, сделанных в MySQL Cluster NDB 7.3 см. What is New in MySQL Cluster NDB 7.3, то же про MySQL Cluster NDB 7.4: What is New in MySQL Cluster NDB 7.4. MySQL Cluster NDB 7.5 основан на MySQL Server 5.7, также доступен для тестирования и предварительного осмотра новых особенностей, но еще не считается готовым к производственному использованию. Для краткого обзора усовершенствований, сделанных в MySQL Cluster NDB 7.5, см. What is New in MySQL Cluster NDB 7.5.

Для получения дальнейшей информации о развертывании и использовании MySQL Cluster см. MySQL Cluster NDB 7.5.

A.10.2.

Что делает NDB и NDBCLUSTER?

NDB означает Network Database. NDB и NDBCLUSTER это названия механизма хранения, который позволяет кластеризировать поддержку с MySQL. NDB предпочтен, но любое имя правильно.

A.10.3.

Сколько компьютеров нужно, чтобы выполнить MySQL Cluster и почему?

Минимум три компьютера нужны, чтобы выполнять жизнеспособный кластер. Однако, минимальное рекомендуемое число компьютеров в кластере MySQL четыре: по одному, чтобы выполнить управление и узлы SQL, и два компьютера, чтобы служить узлами данных. Цель этих двух узлов данных состоит в том, чтобы обеспечить избыточность, управленческий узел должен работать на отдельной машине, чтобы гарантировать работу арбитражных служб, когда один из узлов данных падает.

Чтобы обеспечить увеличенную пропускную способность и высокую доступность, Вы должны использовать много узлов SQL (MySQL Server, соединенные с кластером). Также возможно (хотя не строго необходимо) выполнить много управленческих серверов.

A.11. MySQL 8.0 FAQ: Наборы символов Chinese, Japanese и Korean в MySQL

Этот набор часто задаваемых вопросов получен из опыта поддержки MySQL и групп развития в обработке многих запросов о CJK (китайско-японско-корейских) проблем.

A.11.1.

Какие наборы символов CJK доступны в MySQL?

Список наборов символов CJK может измениться в зависимости от Вашей версии MySQL. Например, набор символов gb18030 не был поддержан до MySQL 5.7.4. Однако, так как название применимого языка появляется в столбце DESCRIPTION для каждого входа в таблице INFORMATION_SCHEMA.CHARACTER_SETS, Вы можете получить текущий список всех не-Unicode наборов символов CJK, используя этот запрос:
mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION FROM INFORMATION_SCHEMA.CHARACTER_SETS WHERE DESCRIPTION LIKE '%Chin%' OR DESCRIPTION LIKE '%Japanese%' OR DESCRIPTION LIKE '%Korean%' ORDER BY CHARACTER_SET_NAME; +--------------------+---------------------------------+ | CHARACTER_SET_NAME | DESCRIPTION | +--------------------+---------------------------------+ | big5 | Big5 Traditional Chinese | | cp932 | SJIS for Windows Japanese | | eucjpms | UJIS for Windows Japanese | | euckr | EUC-KR Korean | | gb18030 | China National Standard GB18030 | | gb2312 | GB2312 Simplified Chinese | | gbk | GBK Simplified Chinese | | sjis | Shift-JIS Japanese | | ujis | EUC-JP Japanese | +--------------------+---------------------------------+

MySQL поддерживает три разновидности GB (Guojia Biaozhun, or National Standard или Simplified Chinese) наборов символов, которые официальны в Китайской Народной Республике: gb2312, gbk и gb18030 (добавлен в MySQL 5.7.4).

Иногда люди пытаются вставить символы gbk в gb2312, и это работает большую часть времени потому, что gbk супернабор gb2312, но в конечном счете они пытаются вставить более редкий китайский символ, и это не работает. См. Bug #16072).

Здесь, мы пытаемся разъяснить точно, какие символы законны в gb2312 или gbk в отношении официальных документов. Пожалуйста, проверьте эти ссылки перед сообщением об ошибке в gb2312 или gbk.

Набор символов MySQL gbk в действительности Microsoft code page 936. Это отличается от официальной gbk символами A1A4 (middle dot), A1AA (em dash), A6E0-A6F5 и A8BB-A8C0.

Для перечисления отображений gbk/Unicode см. http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT.

A.11.2.

Я вставил символы CJK в свою таблицу. Почему SELECT выводит на экран их как ??

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

Будьте уверены, какую версию MySQL Вы используете .

Используйте SELECT VERSION();, чтобы определить это.

Удостоверьтесь, что база данных фактически использует желаемый набор символов.

Люди часто думают, что набор символов клиента всегда тот же самый как набор символов сервера или набор символов, используемый в целях отображения. Однако, оба эти предположения ложные. Вы можете удостовериться, проверяя результат SHOW CREATE TABLE tablename или при использовании этого запроса:
SELECT character_set_name, collation_name FROM information_schema.columns WHERE table_schema = your_database_name AND table_name = your_table_name AND column_name = your_column_name;

Определите шестнадцатеричное значение символа или символов, которые не выводятся на экран правильно.

Вы можете получить эту информацию для столбца column_name в таблице table_name с использованием следующего запроса:
SELECT HEX(column_name) FROM table_name;

3F код для символа ?, это означает символ ?, фактически сохраненный в столбце. Это чаще всего происходит из-за проблемы преобразования особого символа Вашего набора символов клиента в целевой набор символов.

Удостоверьтесь, что конвертация туда и обратно реальна, то есть, когда Вы выбираете literal (или _introducer hexadecimal-value), Вы получаете literal в результате.

Например, японский символ Katakana Pe (Ц┐ ') существует во всех наборах символов CJK, и имеет значение кодовой точки (шестнадцатеричное кодирование) 0x30da. Чтобы проверить конвертацию этого символа, используйте этот запрос:
SELECT 'Ц┐ ' AS `Ц┐ `; /* or SELECT _ucs2 0x30da; */

Если результат не Ц┐ , что-то не так.

Для отчетов об ошибках относительно таких отказов мы могли бы попросить, чтобы Вы предоставили результат SELECT HEX('Ц┐ ');. Тогда мы можем определить, правильно ли клиент кодирует.

Удостоверьтесь, что проблема не с браузером или другим приложением, а именно с MySQL.

Используйте клиент mysql (в Windows mysql.exe), чтобы выполнить эту задачу. Если mysql выводит на экран правильно, но Ваше приложение так не делает, то Ваша проблема происходит, вероятно, из-за системных настроек.

Чтобы узнать, каковы Ваши настройки, используйте SHOW VARIABLES, вывод которого должен выглядеть примерно так:
mysql> SHOW VARIABLES LIKE 'char%'; +--------------------------+----------------------------------------+ | Variable_name | Value | +--------------------------+----------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------------+ 8 rows in set (0.03 sec)

Это типичные настройки набора символов для международно ориентированного клиента (заметьте использование utf8 Unicode), соединенного с сервером (latin1 набор символов по умолчанию для MySQL).

Хотя Unicode (обычно utf8 в Unix и ucs2 в Windows) предпочтителен для латыни, это часто не то, что Ваши утилиты операционной системы поддерживают лучше всего. Много пользователей Windows находят что набор символов Microsoft, такой как cp932 для Japanese Windows, является подходящим.

Если Вы не можете управлять настройками сервера и Вы понятия не имеете, каков Ваш основной компьютер, то попытайтесь измениться на общий набор символов для страны, в которой Вы находитесь (euckr = Korea; gb18030, gb2312 или gbk = КНР; big5 = Taiwan; sjis, ujis, cp932 или eucjpms = Japan; ucs2 или utf8 = где угодно). Обычно необходимо изменить только настройки клиента, результатов и соединения. Есть простой запрос, который изменяет все три сразу: SET NAMES. Например:
SET NAMES 'big5';

Как только установка правильна, Вы можете сделать ее постоянной, редактируя my.cnf или my.ini. Например Вы могли бы добавить такие строки:
[mysqld] character-set-server=big5 [client] default-character-set=big5

Также возможно, что есть проблемы с установкой конфигурации API, используемой в Вашем приложении.

A.11.3.

О каких проблемах я должен знать, работая с китайским набором символов Big5?

MySQL поддерживает набор символов Big5, который распространен в Гонконге и Тайване (республика Китая). MySQL набор символов big5 в действительности кодовая страница Microsoft 950, которая очень подобна оригиналу big5.

Запрос новых функций для того, чтобы добавить расширения HKSCS был зарегистрирован. Люди, которые нуждаются в этом расширении, могут найти патч для Bug #13577 интересным.

A.11.4.

Почему японские преобразования набора символов терпят неудачу?

MySQL поддерживает наборы символов sjis, ujis, cp932 и eucjpms так же, как Unicode. Общая потребность состоит в том, чтобы преобразовать между наборами символов. Например, может быть сервер Unix (как правило с sjis или ujis) и клиент Windows (как правило с cp932).

В следующей таблице преобразования столбец ucs2 представляет источник, а столбцы sjis, cp932, ujis и eucjpms представляют назначение то есть, последние 4 столбца обеспечивают шестнадцатеричный результат, когда мы используем CONVERT(ucs2) или мы назначаем столбец ucs2, содержащий значение, к столбцу sjis, cp932, ujis или eucjpms.

Имя символа ucs2 sjis cp932 ujis eucjpms

BROKEN BAR 00A6 3F 3F 8FA2C3 3F

FULLWIDTH BROKEN BAR FFE4 3F FA55 3F 8FA2

YEN SIGN 00A5 3F 3F 20 3F

FULLWIDTH YEN SIGN FFE5 818F 818F A1EF 3F

TILDE 007E 7E 7E 7E 7E

OVERLINE 203E 3F 3F 20 3F

HORIZONTAL BAR 2015 815C 815C A1BD A1BD

EM DASH 2014 3F 3F 3F 3F

REVERSE SOLIDUS 005C 815F 5C 5C 5C

FULLWIDTH "" FF3C 3F 815F 3F A1C0

WAVE DASH 301C 8160 3F A1C1 3F

FULLWIDTH TILDE FF5E 3F 8160 3F A1C1

DOUBLE VERTICAL LINE 2016 8161 3F A1C2 3F

PARALLEL TO 2225 3F 8161 3F A1C2

MINUS SIGN 2212 817C 3F A1DD 3F

FULLWIDTH HYPHEN-MINUS FF0D 3F 817C 3F A1DD

CENT SIGN 00A2 8191 3F A1F1 3F

FULLWIDTH CENT SIGN FFE0 3F 8191 3F A1F1

POUND SIGN 00A3 8192 3F A1F2 3F

FULLWIDTH POUND SIGN FFE1 3F 8192 3F A1F2

NOT SIGN 00AC 81CA 3F A2CC 3F

FULLWIDTH NOT SIGN FFE2 3F 81CA 3F A2CC

Теперь рассмотрите следующую часть таблицы:

ucs2 sjis cp932

NOT SIGN 00AC 81CA 3F

FULLWIDTH NOT SIGN FFE2 3F 81CA

Это означает, что MySQL преобразовывает NOT SIGN (Unicode U+00AC) к sjis кодовая точка 0x81CA и к cp932 кодовая точка 3F (3F это вопросительный знак ?), то, что всегда используется, когда преобразование не может быть выполнено.

A.11.5.

Что я должен делать, если я хочу преобразовать SJIS 81CA к cp932?

Есть серьезные жалобы об этом: много людей предпочли бы преобразование, так, чтобы 81CA (NOT SIGN) в sjis становится 81CA (FULLWIDTH NOT SIGN) в cp932. Мы рассматриваем изменение этого поведения.

A.11.6.

Как MySQL, представляют Иену?

Проблема возникает потому что некоторые версии японских наборов символов (sjis и euc) представляют 5C как reverse solidus (\ также известен как backslash), а другие обрабатывают это как знак иены (б╔).

MySQL следует только за одной версией JIS (Japanese Industrial Standards). В MySQL 5C всегда reverse solidus (\).

A.11.7.

MySQL планирует сделать отдельный набор символов где 5C знак Yen как делает по крайней мере одна другая главная система управления базами данных?

Это - одно возможное решение проблемы знака Иены, однако, это не будет происходить в MySQL 5.1 или 6.0.

A.11.8.

О каких проблемах я должен знать, работая с корейскими наборами символов в MySQL?

В теории, в то время как было несколько версий набора символов euckr (Extended Unix Code Korea), только одна проблема была отмечена.

Мы используем вариант ASCII EUC-KR, в котором кодовая точка 0x5c REVERSE SOLIDUS, \, вместо KS-Roman EUC-KR, в котором кодовая точка 0x5c WON SIGN(Б┌╘). Это означает, что Вы не можете конвертировать Unicode U+20A9 в euckr:
mysql> SELECT CONVERT('Б┌╘' USING euckr) AS euckr, HEX(CONVERT('Б┌╘' USING euckr)) AS hexeuckr; +-------+----------+ | euckr | hexeuckr | +-------+----------+ | ? | 3F | +-------+----------+

A.11.9.

Почему я получаю сообщения об ошибках Incorrect string value?

Для иллюстрации мы составим таблицу с одним столбцом Unicode (ucs2) и одним столбцом Chinese (gb2312).
mysql> CREATE TABLE ch (ucs2 CHAR(3) CHARACTER SET ucs2, gb2312 CHAR(3) CHARACTER SET gb2312);

Мы попытаемся поместить редкий символ Ф╠▄ в обоих столбцах.
mysql> INSERT INTO ch VALUES ('AФ╠▄B','AФ╠▄B'); Query OK, 1 row affected, 1 warning (0.00 sec)

Есть предупреждение. Используйте следующий запрос, чтобы видеть, каково это:
mysql> SHOW WARNINGS\G *************************** 1. row *************************** Level: Warning Code: 1366 Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1 1 row in set (0.00 sec)

Таким образом, это предупреждение только о столбце gb2312.
mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch; +-------+--------------+--------+-------------+ | ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) | +-------+--------------+--------+-------------+ | AФ╠▄B | 00416C4C0042 | A?B | 413F42 | +-------+--------------+--------+-------------+ 1 row in set (0.00 sec)

Несколько вещей нуждаются в объяснении здесь:

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

Символ Ф╠▄ не находится в наборе символов gb2312, как описано ранее.

Если Вы будете использовать старую версию MySQL, то Вы будете, вероятно, видеть иное сообщение.

С sql_mode=TRADITIONAL будет сообщение об ошибке, а не предупреждение.

A.11.10.

Почему мой GUI или браузер не выводят на экран символы CJK правильно в моем приложении, используя Access, PHP или другой API?

Получите прямую связь с сервером, используя клиент mysql (Windows: mysql.exe ) и попытайтесь выполнить тот же самый запрос там. Если mysql отвечает правильно, то проблема может состоять в том, что Ваш интерфейс приложения требует инициализации. Используйте mysql, чтобы сказать, какой набор символов нужен, через использование SHOW VARIABLES LIKE 'char%';. Если Вы используете Access, то Вы наиболее вероятно соединяетесь с Connector/ODBC. В этом случае Вы должны проверить Configuring Connector/ODBC. Если, например, Вы используете big5, надо скомандовать SET NAMES 'big5'. Отметьте, что нет ; в этом случае. Если Вы используете ASP, Вы, возможно, должны были бы добавить SET NAMES в код. Вот пример, который работал в прошлом:
<% Session.CodePage=0 Dim strConnection Dim Conn str Connection="driver={MySQL ODBC 3.51 Driver};server=server;uid=username;" \ & "pwd=password;database=database;stmt=SET NAMES 'big5';" Set Conn = Server.CreateObject("ADODB.Connection") Conn.Open strConnection %>

Почти таким же способом, если Вы используете какой-либо набор символов, кроме latin1 с Connector/Net, Вы должны определить набор символов в строке подключения. См. Connecting to MySQL Using Connector/Net.

Если Вы используете PHP, попробуйте это:
<?php $link = new mysqli($host, $usr, $pwd, $db); if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $link->query("SET NAMES 'utf8'"); ?>

В этом случае мы использовали SET NAMES, чтобы изменить character_set_client, character_set_connection и character_set_results.

Другая проблема, с которой часто сталкиваются в приложениях PHP, имеет отношение к предположениям, сделанным браузером. Иногда добавляя или изменяя тэг <meta> можно исправить проблему: например, чтобы обеспечить, чтобы пользовательский агент интерпретировал контент страницы как UTF-8, Вы должны включить <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> в <head> HTML-страницы.

Если Вы используете Connector/J, см. Using Character Sets and Unicode.

A.11.11.

Я обновил до MySQL 8.0. Как я могу вернуться к поведению как в MySQL 4.0 относительно наборов символов?

В MySQL Version 4.0 был единственный глобальный набор символов для сервера и клиента, решения, относительно того, какой символ использовать, было сделано администратором сервера. Это изменено с MySQL Version 4.1. Что происходит теперь, описано в разделе 11.1.4:

Когда клиент соединяется, это посылает в сервер название набора символов, который хочет использовать. Сервер использует имя для установки системных переменных character_set_client, character_set_results и character_set_connection. В действительности сервер выполняет SET NAMES, используя имя набора символов.

Эффект этого состоит в том, что Вы не можете управлять набором символов клиента, запуская mysqld с опцией --character-set-server=utf8. Однако, некоторые из наших азиатских клиентов сказали, что предпочитают поведение MySQL 4.0. Чтобы позволить сохранить это поведение, мы добавили выключатель --skip-character-set-client-handshake. Если Вы запускаете mysqld с --skip-character-set-client-handshake, когда клиент соединяется, это посылает в сервер название набора символов, который хочет применить, однако, сервер игнорирует этот запрос от клиента.

Посредством примера, предположите, что Ваш любимый набор символов сервера latin1 (вряд ли в CJK, но это значение по умолчанию). Предположите далее, что клиент использует utf8 потому что это поддерживает операционная система клиента. Теперь запустите сервер с latin1 как его набор символов по умолчанию:
mysqld --character-set-server=latin1

И затем запустите клиента с набором символов по умолчанию utf8:
mysql --default-character-set=utf8

Текущие настройки могут быть просмотрены через SHOW VARIABLES:
mysql> SHOW VARIABLES LIKE 'char%'; +--------------------------+----------------------------------------+ | Variable_name | Value | +--------------------------+----------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------------+ 8 rows in set (0.01 sec)

Теперь остановите клиента и сервер, используя mysqladmin . Теперь запустите сервер снова, но на сей раз скажите ему пропускать квитирование:
mysqld --character-set-server=utf8 --skip-character-set-client-handshake

Запустите клиента еще раз с utf8 как набор символов по умолчанию, затем выведите на экран текущие настройки:
mysql> SHOW VARIABLES LIKE 'char%'; +--------------------------+----------------------------------------+ | Variable_name | Value | +--------------------------+----------------------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------------+ 8 rows in set (0.01 sec)

Как Вы можете видеть, сравнивая отличающиеся результаты SHOW VARIABLES, сервер игнорирует начальные установки клиента, если используется --skip-character-set-client-handshake.

A.11.12.

Почему некоторые поиски LIKE и FULLTEXT с символами CJK терпят неудачу?

Есть очень простая проблема с LIKE на столбцах BINARY и BLOB: мы должны знать конец символа. С многобайтовыми наборами символов у различных символов могут быть различные длины октета. Например, в utf8 A требует одного байта, но Ц┐ требует трех байтов, как показано здесь:
+-------------------------+---------------------------+ | OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'Ц┐ ') | +-------------------------+---------------------------+ | 1 | 3 | +-------------------------+---------------------------+ 1 row in set (0.00 sec)

Если мы не знаем, где первый символ заканчивается, то мы не знаем, где второй символ начинается, когда даже очень простые поиски, например, LIKE '_A%' не работают. Решение состоит в том, чтобы использовать регулярный набор символов CJK или преобразовать в набор символов CJK перед сравнением.

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

Для поисков FULLTEXT мы должны знать, где слова начинаются и заканчиваются. С западными языками это редко проблема, потому что большинство (если не все) из них используют пробел. Однако, это обычно не так с азиатским письмом. Мы могли использовать произвольные лежащие на полпути меры, например, считать, что все символы Han представляют слова, или (для японского языка) в зависимости от изменений переключаться между Katakana и Hiragana из-за грамматических окончаний. Однако, единственное верное решение требует всестороннего списка слов, что означает, что мы должны были бы включать словарь в сервер для каждого поддержанного азиатского языка. Это просто не выполнимо.

A.11.13.
Как узнать, доступен ли символ X во всех наборах символов?

Большинство упрощенного китайского и основных символов японского алфавита появляется во всех наборах символов CJK. Эта хранимая процедура принимает символ UCS-2 Unicode, преобразует во все другие наборы символов и выводит на экран результаты в шестнадцатеричном виде.
DELIMITER // CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2) BEGIN CREATE TABLE tj (ucs2 CHAR(1) character set ucs2, utf8 CHAR(1) character set utf8, big5 CHAR(1) character set big5, cp932 CHAR(1) character set cp932, eucjpms CHAR(1) character set eucjpms, euckr CHAR(1) character set euckr, gb2312 CHAR(1) character set gb2312, gbk CHAR(1) character set gbk, sjis CHAR(1) character set sjis, ujis CHAR(1) character set ujis); INSERT INTO tj (ucs2) VALUES (ucs2_char); UPDATE tj SET utf8=ucs2, big5=ucs2, cp932=ucs2, eucjpms=ucs2, euckr=ucs2, gb2312=ucs2, gbk=ucs2, sjis=ucs2, ujis=ucs2; /* If there is a conversion problem, UPDATE will produce a warning. */ SELECT hex(ucs2) AS ucs2, hex(utf8) AS utf8, hex(big5) AS big5, hex(cp932) AS cp932, hex(eucjpms) AS eucjpms, hex(euckr) AS euckr, hex(gb2312) AS gb2312, hex(gbk) AS gbk, hex(sjis) AS sjis, hex(ujis) AS ujis FROM tj; DROP TABLE tj; END//

Ввод может быть любым символом ucs2 или значением кодовой точки (шестнадцатеричное представление) этого символа. Например, из списка Unicode ucs2 и имен (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt) мы знаем, что символ Katakana Pe появляется во всех наборах символов CJK, и что его значение кодовой точки 0x30da. Если мы используем это значение в качестве параметра p_convert(), результат показан здесь:
mysql> CALL p_convert(0x30da)// +------+--------+------+-------+---------+-------+--------+------+------+------+ | ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis | +------+--------+------+-------+---------+-------+--------+------+------+------+ | 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA | +------+--------+------+-------+---------+-------+--------+------+------+------+ 1 row in set (0.04 sec)

Так как ни одно из значений столбцов не 3F (?), мы знаем, что каждое преобразование сработало.

A.11.14.

Почему CJK сортирует в виде строки неправильно в Unicode? (I)

Иногда люди замечают что результат поиска с utf8_unicode_ci или ucs2_unicode_ci или сортировки ORDER BY не то, что они думают. Хотя мы никогда не исключаем возможность, что есть ошибка, мы нашли в прошлом, что много людей не читают правильно стандартную таблицу весов для Unicode Collation Algorithm. MySQL использует таблицу, найденную в http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. Это не первая таблица, которую Вы найдете, перемещаясь от основной страницы unicode.org, потому что MySQL использует более старые таблицы 4.0.0 allkeys, а не 4.1.0. Сопоставления '520' в MySQL 5.6 и позже используют таблицы 5.2 allkeys. Это потому, что мы очень осторожны в изменении упорядочивания, которые могут вызвать проблемы, как в Bug #16526:
mysql< CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci); Query OK, 0 rows affected (0.05 sec) mysql> INSERT INTO tj VALUES ('Ц│▄'),('Ц│▀'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM tj WHERE s1 = 'Ц│▀'; +-----+ | s1 | +-----+ | Ц│▄ | | Ц│▀ | +-----+ 2 rows in set (0.00 sec)

Символ в первой строке результата не тот, который мы искали. Почему MySQL получил это? Сначала мы ищем значение кодовой точки Unicode, которое возможно найти, читая шестнадцатеричное число для ucs2-версии символов:
mysql> SELECT s1, HEX(CONVERT(s1 USING ucs2)) FROM tj; +------+-----------------------------+ | s1 | HEX(CONVERT(s1 USING ucs2)) | +------+-----------------------------+ | Ц│▄ | 304C | | Ц│▀ | 304B | +------+-----------------------------+ 2 rows in set (0.03 sec)

Теперь мы ищем 304B и 304C в таблице 4.0.0 allkeys и находим эти строки:
304B ; [.1E57.0020.000E.304B] # HIRAGANA LETTER KA 304C ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM

Официальные имена Unicode (после #) указывают на японскую слоговую азбуку (Hiragana), неофициальная классификация (буквы, цифры и знаки препинания) и западный идентификатор (KA или GA. Что еще более важно, первичный вес (первое шестнадцатеричное число в квадратных скобках) 1E57 в обоих строках. Для сравнений в поиске и в сортировке, MySQL обращает внимание только на основной (первичный) вес, игнорируя все другие числа. Это означает, что мы сортируем Ц│▄ и Ц│▀ правильно, согласно спецификации Unicode. Если бы мы хотели отличить их, то мы должны были бы использовать сопоставление не-UCA (Unicode Collation Algorithm) (utf8_bin или utf8_general_ci) или сравнить значения HEX() или использовать ORDER BY CONVERT(s1 USING sjis). Быть правильным согласно Unicode недостаточно, конечно: человек, который представил ошибку, был одинаково прав. Мы планируем добавить другое сопоставление для японского языка согласно стандарту JIS X 4061.

A.11.15.
Почему CJK сортирует в виде строки неправильно в Unicode? (II)

Если Вы используете Unicode (ucs2 или utf8), и знаете, что порядок сортировки Unicode (см. раздел A.11), но MySQL все еще, кажется, сортирует Вашу таблицу неправильно, тогда Вы должны сначала проверить табличный набор символов:
mysql> SHOW CREATE TABLE t\G ******************** 1. row ****************** Table: t Create Table: CREATE TABLE `t` ( `s1` char(1) CHARACTER SET ucs2 DEFAULT NULL) ENGINE=MyISAM DEFAULT CHARSET=latin1

Так как набор символов, кажется, правилен, давайте смотреть, что INFORMATION_SCHEMA.COLUMNS сообщает об этом столбце:
mysql> SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 's1' AND TABLE_NAME = 't'; +-------------+--------------------+-----------------+ | COLUMN_NAME | CHARACTER_SET_NAME | COLLATION_NAME | +-------------+--------------------+-----------------+ | s1 | ucs2 | ucs2_general_ci | +-------------+--------------------+-----------------+

Вы можете видеть, что сопоставление ucs2_general_ci использовано вместо ucs2_unicode_ci. Причина почему это так, может быть найдена, используя SHOW CHARSET:
mysql> SHOW CHARSET LIKE 'ucs2%'; +---------+---------------+-------------------+--------+ | Charset | Description | Default collation | Maxlen | +---------+---------------+-------------------+--------+ | ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 | +---------+---------------+-------------------+--------+ 1 row in set (0.00 sec)

Для ucs2 и utf8 сопоставление по умолчанию general. Чтобы определить сопоставление Unicode, надо использовать COLLATE ucs2_unicode_ci.

A.11.16.

Почему мои дополнительные символы отклонены MySQL?

До MySQL 5.5.3 MySQL не поддерживает дополнительный набор символов, то есть, символы, которые нуждаются больше, чем в 3 байтах для UTF-8. Мы поддерживаем только то, что в Unicode называется Basic Multilingual Plane / Plane 0. Только несколько очень редких символов Han дополнительны, поддержка их необычна. Это привело к отчетам, таким как Bug #12600, который мы отклонили как это не баг, это фича. С utf8 мы должны усечь строку ввода, когда сталкиваемся с байтами, которые не понимаем. Иначе мы не знали бы, какой длины плохой мультибайтный символ.

Одно возможное обходное решение должно использовать ucs2 вместо utf8, когда плохие символы изменены на вопросительные знаки, однако, никакого усечения нет. Вы можете также изменить тип данных на BLOB или BINARY, которые не выполняют проверки законности.

С MySQL 5.5.3 поддержка Unicode расширена, чтобы включать дополнительные символы посредством дополнительных наборов символов Unicode: utf16, utf32 и четырехбайтного utf8mb4. Эти наборы символов поддерживают дополнительные символы Unicode вне Basic Multilingual Plane (BMP).

A.11.17.

Разве это не должен быть CJKV?

Нет. Термин CJKV (Chinese Japanese Korean Vietnamese ) относится к вьетнамским наборам символов, которые содержат Han (первоначально китайские) символы. У MySQL нет никакого плана поддержать старый вьетнамский сценарий, используя символы Han. MySQL действительно, конечно, поддерживает современный вьетнамский сценарий с западными символами.

С MySQL 5.6 есть вьетнамские сопоставления для наборов символов Unicode, как описано в разделе 11.1.10.1.

A.11.18.

MySQL позволяет символам CJK использоваться в именах базы данных и таблиц?

Эта проблема исправлена в MySQL 5.1, автоматически переписывая названия соответствующих каталогов и файлов.

Например, если Вы создаете базу данных Ф╔╝ на сервере, операционная система которого не поддерживает CJK в именах каталогов, MySQL создает названный каталог @0w@00a5@00ae, который является только необычным способом закодировать E6A5AE то есть, шестнадцатеричное представление Unicode для символа Ф╔╝. Однако, если Вы выполняете запрос SHOW DATABASES, Вы можете видеть, что база данных перечислена как Ф╔╝.

A.11.19.

Где я могу найти переводы руководства MySQL на китайский, японский и корейский языки?

Японский перевод руководства MySQL 5.6 может быть загружен с downloaded from http://dev.mysql.com/doc/.

A.11.20.

Где я могу получить справку по CJK и связанным проблемам в MySQL?

Следующие ресурсы доступны:

Список групп пользователей MySQL может быть найден на https://wikis.oracle.com/display/mysql/List+of+MySQL+User+Groups.

Запросы новых функций представления, касающиеся набора символов, выходят в http://tinyurl.com/y6xcuf.

Посетите MySQL Character Sets, Collation, Unicode Forum. http://forums.mysql.com/ также обеспечивает форумы иностранного языка.

A.12. MySQL 8.0 FAQ: Connector & API

Для общих вопросов, касающихся MySQL Connector и других API, см. следующие области руководства:

Раздел 25.8.15.

Common Problems with MySQL and PHP.

Connector/ODBC Notes and Tips.

Connector/Net Programming.

MySQL Connector/J 5.1 Developer Guide.

A.13. MySQL 8.0 FAQ: Репликация

В следующем разделе мы обеспечиваем ответы на вопросы, которые наиболее часто встречаются в темах о репликации в MySQL.

A.13.1.

Ведомое устройство должно быть соединено с ведущим устройством все время?

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

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

A.13.2.

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

Да, сеть должна быть включена на ведущем и ведомом устройствах. Если сеть не включена, ведомое устройство не может соединиться с ведущим и передать двоичный журнал. Проверьте, что опция skip-networking НЕ включена в конфигурационном файле ни для одного сервера.

A.13.3.

Как я узнаю дату последнего запроса, копируемого ведомым устройством?

Проверьте столбец Seconds_Behind_Master в выводе SHOW SLAVE STATUS.

Когда ведомый поток SQL запускает событие, считанное с ведущего устройства, он изменяет свое собственное время к timestamp события. Это причина того, почему TIMESTAMP хорошо копируется. Столбец Time в выводе SHOW PROCESSLIST указывает число секунд для ведомого потока SQL и является числом секунд между timestamp последнего копируемого события и реальным временем ведомой машины. Вы можете использовать это, чтобы определить дату последнего копируемого события. Отметьте, что, если Ваше ведомое устройство отсоединялось от ведущего в течение одного часа, а затем повторно соединяется, Вы можете немедленно видеть большое значение Time, например, 3600 в SHOW PROCESSLIST. Это потому, что ведомое устройство выполняет запросы, которые помечены одним часом. См. раздел 19.2.2.

A.13.4.

Как я вынуждаю ведущее устройство заблокировать обновления, пока ведомое его не нагонит?

Используйте следующую процедуру:

На ведущем выполните эти запросы:
mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;

Сделайте запись координат репликации (текущее имя файла двоичного системного журнала и позиция в нем) из вывода SHOW.

На ведомом устройстве, сделайте следующий запрос, где параметры MASTER_POS_WAIT() значения координаты репликации, полученные на предыдущем шаге:
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);

Запрос SELECT блокирует запросы пока ведомый сервер не достигнет нужных координат репликации. В этой точке ведомое устройство находится в синхронизации с ведущим устройством.

На ведущем устройстве сделайте следующий запрос, чтобы начать обрабатывать обновления снова:
mysql> UNLOCK TABLES;

A.13.5.

О каких проблемах я должен знать, настраивая двухстороннюю репликацию?

Репликация MySQL в настоящее время не поддерживает протокола блокировки между ведущим и ведомым устройством, чтобы гарантировать атомичность распределенного обновления. Другими словами, для клиента A возможно сделать обновление cо-ведущего устройства 1, а тем временем, прежде, чем это размножится на cо-ведущее устройство 2, клиент B мог сделать обновление cо-ведущего устройства 2, которое делает обновление клиента A, работающего по-другому, чем это сделано на cо-ведущем устройстве 1. Таким образом, когда обновление клиента А сделано на cо-ведущем устройстве 2, это производит таблицы, которые отличаются от того, что Вы имеете на cо-ведущем устройстве 1, даже после того, как все обновления от cо-ведущего устройства 2 также размножились. Это означает, что Вы не должны объединить два сервера в цепочку вместе в двухсторонних отношениях репликации, если Вы не уверены, что Ваши обновления могут безопасно произойти в любом порядке, или если Вы заботитесь о неправильных упорядоченных обновлениях так или иначе в коде клиента.

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

A.13.6.

Как я могу использовать репликацию, чтобы улучшить производительность моей системы?

Настройте один сервер как ведущее устройство и пишите все на него. Тогда сконфигурируйте так много ведомых устройств, как Вам позволяет бюджет, и распределите чтения между ведущим и ведомыми устройствами. Вы можете также запустить ведомые устройства с опциями --skip-innodb, --low-priority-updates и --delay-key-write=ALL, чтобы получить прирост скорости на ведомом конце. В этом случае ведомые используют нетранзакционные таблицы MyISAM вместо таблиц InnoDB, чтобы получить больше скорости, устраняя накладные расходы транзакций.

A.13.7.

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

См. руководство по использованию репликации в разделе 19.3.5.

A.13.8.

Когда и насколько репликация MySQL может улучшить производительность моей системы?

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

Чтобы определить, сколько ведомых устройств Вы можете использовать, и насколько Вы можете улучшить исполнение своего сайта, Вы должны знать свои образцы запроса и определить опытным путем эффективность отношения пропускной способности для чтения и записи на типичных ведущем и ведомом устройствах. Пример здесь показывает весьма упрощенное вычисление того, что Вы можете получить с репликацией для гипотетической системы. Через reads и writes обозначьте число чтений и записей в секунду, соответственно.

Скажем, системная загрузка состоит из 10% записей и 90% чтений и мы определили эффективность reads = 1200-2*writes. Другими словами, система может сделать 1200 чтений в секунду без записей, средняя запись вдвое медленнее среднего чтения и отношения линейны. Предположите, что у ведущего устройства и каждого ведомого устройства есть та же самая пропускная способность, у нас есть одно ведущее устройство и N ведомых. Тогда мы имеем для каждого сервера (ведущее или ведомое устройство):

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (чтения разделены, но записи копируются всем ведомым устройствам).

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

Последнее уравнение указывает максимальное количество записей для N ведомых устройств, учитывая максимальный возможный уровень чтения 1200 в секунду и отношение в девять чтений на одну запись.

Этот анализ приводит к следующим заключениям:

Если N = 0 (у нас нет никакой репликации), наша система может обработать 1200/11 = 109 записей в секунду.

Если N = 1, то уже 184 записи в секунду.

Если N = 8, то 400 записей в секунду.

Если N = 17, то 480 записей в секунду.

В конечном счете, устремив N в бесконечность (и наш бюджет в отрицательную бесконечность), мы можем подобраться очень близко к 600 записям в секеунду, увеличивая системную пропускную способность приблизительно в 5,5 раз. Однако, только с восемью серверами, мы увеличиваем это почти в четыре раза.

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

Каково отношение чтения к записи на Вашей системе?

Сколько еще записей один сервер может обработать, если Вы уменьшаете чтения?

Для скольких ведомых устройств Вы имеете пропускную способность в наличии в своей сети?

A.13.9.

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

То, как Вы осуществляете избыточность, полностью зависит от Вашего приложения и обстоятельств. Высоконадежные решения (с автоматическим аварийным переключением) требуют, чтобы активный контроль и\или пользовательские скрипты (или сторонние инструменты) оказали поддержку от оригинального сервера MySQL до ведомого устройства.

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

A.13.10.

Как узнать использует ли главный сервер репликацию, основанную на запросе или на строке?

Проверьте значение переменной binlog_format:
mysql> SHOW VARIABLES LIKE 'binlog_format';

Показанное значение будет одним из: STATEMENT, ROW или MIXED. Для режима MIXED по умолчанию используется основанная на запросе, но переключается автоматически на основанную на строке при определенных условиях, таких как опасные запросы. Для информации о том, когда это может произойти, см. раздел 6.4.4.3.

A.13.11.

Как сказать ведомому устройству использовать основанную на строке репликацию?

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

A.13.12.

Как защитить запросы GRANT and REVOKE от репликации?

Запустите сервер с опцией --replicate-wild-ignore-table=mysql.%, чтобы проигнорировать репликацию для таблиц в базе данных mysql.

A.13.13.

Репликация работает со смешанными операционными системами (например, основной сервер под Linux, ведомые под OS X и Windows)?

Да.

A.13.14.

Репликация работает со смешанной архитектурой аппаратных средств (например, основной сервер на 64-битной, а подчиненные на 32-битных системах)?

Да.

A.14. MySQL 8.0 FAQ: Буфер изменений InnoDB

A.14.1.

Какие типы операций меняют вторичные индексы и результат в буфере изменений?

INSERT, UPDATE и DELETE меняют вторичные индексы. Если затронутая индексная страница не находится в буферном бассейне, изменения могут быть буферизованы в буфере изменения.

A.14.2.

Что является выгодой буфера изменения InnoDB?

Вторичная буферизация индексирует изменения, когда вторичные индексные страницы не находятся в буферном бассейне, это позволяет избегать дорогих операций ввода/вывода произвольного доступа, которые были бы обязаны немедленно читать затронутые индексные страницы с диска. Буферизованные изменения могут быть применены позже, в пакетах, когда страницы считаны в буферный бассейн другими операциями чтения.

A.14.3.

Буфер изменений понимает другие типы индексов?

Нет, только вторичные индексы. Кластеризируемый, полнотекстовый и пространственный индексы не поддержаны. Полнотекстовый индекс имеет собственный механизм кэширования.

A.14.4.

Как много места InnoDB использует для буфера изменений?

До введения опции innodb_change_buffer_max_size в MySQL 5.6 максимальный размер буфера изменения на диске в системном табличном пространстве был 1/3 InnoDB размер бассейна буферов.

В MySQL 5.6 и позже опция innodb_change_buffer_max_size определяет максимальный размер буфера изменения как процент полного буферного размера бассейна. По умолчанию innodb_change_buffer_max_size составляет 25. Максимум 50.

InnoDB не буферизует работу, если это заставило бы буфер изменения на диске превышать определенный предел.

Буферные страницы изменения не обязаны сохраняться в буферном бассейне и могут быть удалены операциями LRU.

A.14.5.

Как определить текущий размер буфера изменения?

Текущий размер буфера изменения сообщает SHOW ENGINE INNODB STATUS \G под заголовком INSERT BUFFER AND ADAPTIVE HASH INDEX. Например:
------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf: size 1, free list len 0, seg size 2, 0 merges

Соответствующие точки данных включают:

size: Число страниц, которые используются в пределах буфера изменения. Размер буфера изменения равен seg size - (1 + free list len). Значение 1+ представляет буферную страницу заголовка изменения.

seg size: Размер буфера изменения в страницах.

A.14.6.

Когда выполняется слияние буфера изменений?

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

Буферное слияние выполнено как фоновая задача. Параметр innodb_io_capacity устанавливает верхний предел для деятельности I/O, выполненной такими фоновыми задачами InnoDB, как слияние данных буфера изменений.

Буферное слияние выполнено во время восстановления катастрофического отказа. Изменения применены из буфера изменения (в системном табличном пространстве) к страницам вторичных индексов, когда индексные страницы считаны в буферный бассейн.

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

Полное слияние буфера изменения может быть вызвано как часть медленного завершения работы сервера с применением --innodb-fast-shutdown=0.

A.14.7.

Когда буфер изменения сбрасывается?

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

A.14.8.

Когда используется буфер изменений?

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

A.14.9.

Когда буфер изменений не используется?

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

A.14.10.

Где я могу найти дополнительную информацию о буфере изменения?

Следующие разделы и сообщения в блогах обеспечивают дополнительную информацию о буфере изменения InnoDB change buffer:

раздел 16.4.2

раздел 16.6.4

MySQL 5.5: InnoDB Change Buffering

A.15. MySQL 8.0 FAQ: Шифрование табличного пространства InnoDB

A.15.1.

Данные дешифрованы для пользователей, которые уполномочены видеть их?

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

A.15.2.

Что является накладными расходами, связанными с шифрованием табличного пространства InnoDB?

Нет никакого дополнительного хранения. Согласно внутренним точкам отсчета, разница в производительности около 0,1%.

A.15.3.

Что является алгоритмами шифрования, используемыми в шифровании табличного пространства InnoDB?

Шифрование табличного пространства InnoDB поддерживает Advanced Encryption Standard (AES256). Он использует режим блочного шифрования Electronic Codebook (ECB) для шифрования ключей табличного пространства и режим блочного шифрования Cipher Block Chaining (CBC) для шифрования данных.

A.15.4.

Возможно использовать сторонние алгоритмы шифрования вместо обеспеченного InnoDB?

Нет, невозможно использовать другие алгоритмы шифрования.

A.15.5.

Индексированные столбцы могут быть зашифрованы?

Шифрование табличного пространства InnoDB поддерживает все индексы прозрачно.

A.15.6.

Какие типы данных и длины данных поддерживает шифрование табличного пространства InnoDB?

Шифрование табличного пространства InnoDB поддерживает все поддержанные типы данных. Нет никакого ограничения длины данных.

A.15.7.

Данные остаются зашифрованными в сети?

Данные, зашифрованные InnoDB, дешифрованы, когда они считаны из файла табличного пространства. Таким образом, если данные находятся в сети, они там находятся в форме открытого текста. Однако, данные в сети могут быть зашифрованы, используя шифрование сети MySQL, которое шифрует данные, используя SSL/TLS.

A.15.8.

Память базы данных содержит открытый текст или зашифрованные данные?

С InnoDB данные в памяти дешифрованы, что обеспечивает 100% прозрачность.

A.15.9.

Как я узнаю, которые данные зашифровать?

Согласие со стандартом PCI-DSS требует, чтобы номера кредитной карточки (Primary Account Number, 'PAN') были сохранены в зашифрованной форме. Законы об уведомлении (например, CA SB 1386, CA AB 1950 и подобные) требуют шифрования имени, фамилии, номера водительских прав и других личных данных. В начале 2008 CA AB 1298 добавил медицинскую и информация о медицинском страховании к данным PII. Кроме того, могут быть отраслевые стандарты и требования по этой части.

A.15.10.

Как шифрование табличного пространства InnoDB отличается от функций шифрования, которые MySQL уже и так имеет?

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

A.15.11.

Переносимы ли зашифрованные данные?

Да.

A.15.12.

Сжимает ли данные шифрование InnoDB?

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

A.15.13.

Можно ли применить mysqlpump или mysqldump с зашифрованными таблицами?

Да. Поскольку эти утилиты создают логические резервные копии, данные, выведенные из зашифрованных таблиц, не зашифрованы.

A.15.14.

Как сменить основной ключ шифрования?

Шифрование табличного пространства InnoDB использует два ключевых механизма. Когда шифрование используется, отдельные ключи сохранены в заголовке основного файла с данными табличного пространства. Ключи табличного пространства зашифрованы, используя основной ключ шифрования. Основной ключ шифрования произведен, когда шифрование табличного пространства включено, и сохранен вне базы данных. Основной ключ шифрования ротируется, используя команду ALTER INSTANCE ROTATE INNODB MASTER KEY, которая производит новый основной ключ шифрования.

A.15.15.

Как мигрировать данные из открытого текста в зашифрованное табличное пространство InnoDB?

Передача данных из одного табличного пространства в другое не требуется. Зашифровать данные в InnoDB можно командой ALTER TABLE tbl_name ENCRYPTION='Y'. Шифрование табличного пространства в InnoDB поддержано только с табличными пространствами file-per-table.

A.16. MySQL 8.0 FAQ: Поддержка виртуализации

A.16.1.

MySQL поддерживает виртуальное окружение Oracle VM, VMWare, Docker, Microsoft Hyper-V или что-то такое?

MySQL поддерживает виртуальное окружение, но сертифицирован пока только для Oracle VM. Подробности в техподдержке Oracle.

Поиск

На сайте
В Яндексе

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову.