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. Мультитабличная вставка может быть достигнута, используя триггер
с предложением | |
A.1.5. |
У MySQL 8.0 есть кэш запроса? Это работает для сервера или базы данных? |
Да. Кэш запроса работает на уровне сервера, кэшируя полные наборы результатов, соответствующие оригинальной строке запроса. Если точно идентичный запрос сделан (что часто происходит, особенно в веб-приложениях), никакой парсинг или выполнение не необходимы: результат посылается непосредственно из кэша. Различные настраивающие опции доступны. См. раздел 9.10.3. | |
A.1.6. |
У MySQL 8.0 есть последовательности (Sequences)? |
Нет. Однако, MySQL имеет систему | |
A.1.7. |
Имеет ли MySQL 8.0 функцию
|
Да. См. раздел 12.3.6. | |
A.1.8. |
MySQL 8.0 работает с мультиядерными процессорами? |
Да. MySQL полностью многопоточный и использует много процессоров при условии, что операционная система поддерживает их. | |
A.1.9. |
Почему я вижу много процессов для |
Используя LinuxThreads, Вы должны видеть минимум три процесса mysqld. Это фактически потоки. Есть один поток для менеджера LinuxThreads, один поток, чтобы обработать соединения, и один поток, чтобы обработать аварийные сигналы. | |
A.1.10. |
Может MySQL 8.0 выполнять ACID-транзакции? |
Да. Все текущие версии MySQL поддерживают транзакции. Механизм хранения
Механизм хранения
The |
A.2.1. | Где я могу получить полную документацию для механизмов хранения MySQL? |
См. главу 17. Та глава содержит информацию обо всех
механизмах хранения MySQL за исключением
| |
A.2.2. |
Есть ли какие-либо новые механизмы хранения в MySQL 8.0? |
Нет. | |
A.2.3. |
Какие-либо механизмы хранения были удалены в MySQL 8.0? |
Нет. | |
A.2.4. |
Что является уникальной выгодой
механизма хранения |
Механизм хранения | |
A.2.5. |
Новые особенности в MySQL 8.0 относятся ко всем механизмам хранения? |
Общие новые особенности, такие как обзоры, хранимые процедуры, триггеры,
|
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)
опцией | |
A.3.4. |
Действительно ли режим зависит от базы данных или соединения? |
Режим не связан с базой данных. Режимы могут быть установлены в местном
масштабе для сеанса (соединения) или глобально для сервера. Вы можете
изменить эти настройки через использование
| |
A.3.5. |
Могут ли правила для строгого режима быть расширены? |
Когда мы обращаемся к строгому режиму, мы имеем в виду
режим где по крайней мере один из режимов
| |
A.3.6. |
Строгий режим воздействует на производительность? |
Интенсивная проверка допустимости входных данных требует большего количества времени, чем если бы проверка допустимости не была сделана. Если Вы не требуете такой проверки допустимости (возможно, Ваше приложение уже обрабатывает все это), то MySQL дает Вам опцию отключения строгого режима. Однако, если Вы действительно требуете проверку данных, строгий режим может обеспечить такую проверку допустимости. | |
A.3.7. | Каков по умолчанию режим SQL, когда MySQL 8.0 установлен? |
Значение по умолчанию режима SQL в MySQL 8.0 включает эти режимы:
|
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. |
Как Вы управляете сохраненными функциями? |
Всегда хорошая практика использовать ясную схему именования для Ваших
сохраненных процедур. Вы можете управлять хранимыми процедурами с помощью
| |
A.4.6. |
Есть способ рассмотреть все хранимые процедуры и сохраненные функции в данной базе данных? |
Да. Для базы данных
SELECT ROUTINE_TYPE, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA='
Тело сохраненной процедуры может быть рассмотрено, используя
| |
A.4.7. |
Где хранимые процедуры сохранены? |
Хранимые процедуры сохранены в таблицах Вы можете также использовать | |
A.4.8. |
Действительно ли возможно сгруппировать хранимые процедуры или сохраненные функции в пакеты? |
Нет. Это не поддерживается в MySQL 8.0. | |
A.4.9. |
Хранимая процедура может вызвать другую хранимую процедуру? |
Да. | |
A.4.10. |
Хранимая процедура может вызвать триггер? |
Хранимая процедура может выполнить запрос SQL, подобный
| |
A.4.11. |
Действительно ли хранимая процедура может получить доступ к таблицам? |
Да. Хранимая процедура может получить доступ к одной или более таблицам, как ей требуется. | |
A.4.12. |
У хранимых процедур есть запрос для того, чтобы создать ошибку приложения? |
Да. MySQL 8.0 реализует стандартные SQL-запросы | |
A.4.13. |
Хранимые процедуры обеспечивают обработку исключения? |
MySQL реализует определения | |
A.4.14. |
Может сохраненная процедура в MySQL 8.0 возвращать наборы результатов? |
Сохраненная процедура да, сохраненная функция нет.
Если Вы выполняете одиночный
| |
A.4.15. |
Is |
Не в MySQL 8.0. | |
A.4.16. |
Есть ли MySQL-эквивалент использованию
|
Нет эквивалента в MySQL 8.0. | |
A.4.17. |
Я могу передать массив как ввод хранимой процедуре? |
Не MySQL 8.0. | |
A.4.18. |
Могу я передавать курсор как параметр
|
В MySQL 8.0 курсоры доступны только внутри хранимых процедур. | |
A.4.19. |
Могу я возвращать курсор как параметр
|
В MySQL 8.0 курсоры доступны только внутри хранимых процедур.
Однако, если Вы не открываете курсор на
| |
A.4.20. |
Я могу распечатать значение переменной в пределах сохраненной процедуры для того, чтобы отладить код? |
Да, Вы можете сделать это в хранимой процедуре,
но не в сохраненной функции. Если Вы выполняете одиночный
| |
A.4.21. |
Я могу передать или отменить транзакцию в хранимой процедуре? |
Да. Однако, Вы не можете выполнить транзакционные действия в пределах сохраненной функции. | |
A.4.22. |
В MySQL 8.0 хранимые процедуры и функции работают с репликацией? |
Да, стандартные действия, выполненные в хранимых процедурах и функциях, копируются с сервера ведущего устройства на ведомый сервер. Есть несколько ограничений, которые описаны подробно в разделе 21.7. | |
A.4.23. |
Хранимые процедуры и функции создаются на главном сервере, копируемом на ведомый? |
Да, создание хранимых процедур и функций, выполнено через нормальные запросы
DDL о главном сервере, поэтому они скопируются на ведомый, таким образом,
объекты будут существовать на обоих серверах. | |
A.4.24. |
Как действия, которые имеют место в хранимых процедурах и копируемых функциях, реплицируются? |
MySQL делает запись каждого случая DML, который происходит в хранимой процедуре, и копирует эти отдельные действия на ведомый сервер. Фактические вызовы, сделанные, чтобы выполнить хранимые процедуры, не копируются. Сохраненные функции, которые изменяют данные, зарегистрированы как запросы, а не как события DML, которые происходят в каждой функции. | |
A.4.25. |
Есть ли специальные требования безопасности для того, чтобы использовать хранимые процедуры и функции вместе с репликацией? |
Да. Поскольку у ведомого сервера есть полномочия выполнить любой запрос, считанный из двоичного журнала ведущего устройства, специальные ограничения безопасности существуют для того, чтобы использовать сохраненные функции с репликацией. Если репликация или двоичный журнал вообще (с целью восстановления момента времени), являются активными, MySQL DBA имеет две опции безопасности, открытые для них:
| |
A.4.26. |
Какие ограничения существуют для того, чтобы копировать хранимую процедуру и функциональные действия? |
Недетерминированные (случайные) или основанные на времени действия,
встроенные в хранимые процедуры, возможно, не копируются должным образом. По
самому их характеру результаты, к которым они приводят, непредсказуемы и не
могут быть точно воспроизведены, поэтому, случайные действия, копируемые
ведомому устройству, не будут зеркально отражать выполненные на ведущем
устройстве. Объявление сохраненных функций Кроме того, основанные на времени действия не могут быть воспроизведены на ведомом устройстве, потому что синхронизация таких действий в хранимой процедуре не восстанавливаема через двоичной журнал, используемый для репликации. Это делает запись только событий DML и не делает фактора в синхронизации времени. Наконец, нетранзакционные таблицы, для которых ошибки происходят во время
больших действий DML (таких, как большая вставка) могут испытать проблемы
репликации, в которых ведущее устройство может быть частично обновлено от
деятельности DML, но никакие обновления не сделаны на ведомом устройстве
из-за ошибок. Обходное решение для действий функции DML, которые будут
выполнены с ключевым словом | |
A.4.27. |
Предыдущие ограничения затрагивают способность MySQL сделать восстановление момента времени? |
Те же самые ограничения, которые затрагивают репликацию, действительно затрагивают восстановление момента времени. | |
A.4.28. |
Что делать, чтобы исправить вышеупомянутые ограничения? |
Вы можете выбрать репликацию, основанную на запросе или на строке. Оригинальное выполнение репликации основано на запросе и двоичном журнале. Основанное на строке двоичное журналирование решает ограничения, упомянутые ранее. Смешанная репликация также доступна (запуская сервер с
|
A.5.1. | Где я могу найти документацию для триггеров в MySQL 8.0? |
См. раздел 21.3. | |
A.5.2. |
Есть дискуссионный форум для триггеров в MySQL? |
A.5.3. |
У MySQL 8.0 есть триггеры на уровне строки или на уровне запроса? |
В MySQL 8.0 все триггеры | |
A.5.4. |
Есть ли какие-либо триггеры по умолчанию? |
Не явно. У MySQL действительно есть определенное специальное поведение для
некоторых столбцов | |
A.5.5. |
Как управлять триггерами в MySQL? |
В MySQL 8.0 триггеры могут быть созданы, используя
Информация о триггерах может быть получена, запрашивая таблицу
| |
A.5.6. |
Есть способ рассмотреть все триггеры в базе данных? |
Да. Вы можете получить перечисление всех триггеров, определенных в базе
данных
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE,
ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS
WHERE TRIGGER_SCHEMA='
Вы можете также использовать запрос | |
A.5.7. |
Где сохранены триггеры? |
Триггеры сохранены в системной таблице | |
A.5.8. |
Триггер может вызвать хранимую процедуру? |
Да. | |
A.5.9. |
Действительно ли триггеры могут получить доступ к таблицам? |
Триггер может получить доступ к старым и новым данным в своей собственной таблице. Он может также затронуть другие таблицы, но не разрешено изменять таблицу, которая уже используется (для чтения или записи) запросом, который вызвал функцию или триггер. | |
A.5.10. |
У таблицы может быть много триггеров с тем же самым событием и временем действия? |
В MySQL 8.0 возможно определить много триггеров для данной таблицы, у которых
есть то же самое событие и время действия. Например, Вы можете иметь два
триггера | |
A.5.11. |
Триггеры могут вызвать внешнее приложение через UDF? |
Да. Например, триггер мог вызвать | |
A.5.12. |
Действительно ли возможно обновить триггером таблицы на удаленном сервере? |
Да. Таблица на удаленном сервере могла быть обновлена, используя механизм
хранения | |
A.5.13. |
Триггеры работают с репликацией? |
Да. Однако, путь, которым они работают, зависит от того, используете ли Вы классическую репликацию MySQL, основанную на запросе, доступную во всех версиях MySQL, или основанную на строке, введенную в MySQL 5.1. Используя основанную на запросе репликацию, триггеры на ведомом устройстве выполнены запросами, которые выполнены на ведущем устройстве (и копируются к ведомому устройству). Используя основанную на строке репликацию, триггеры не выполнены на ведомом устройстве из-за запросов, которые были выполнены на ведущем устройстве и затем копировались к ведомому устройству. Вместо этого, используя основанную на строке репликацию, изменения, вызванные, выполняя триггер на ведущем устройстве, применены на ведомом устройстве. | |
A.5.14. |
Как действия, выполненные через триггер на ведущем устройстве, копируются на ведомое устройство? |
Снова, это зависит от того, используете ли Вы классическую репликацию MySQL, основанную на запросе, доступную во всех версиях MySQL, или основанную на строке, введенную в MySQL 5.1. Основанная на запросе репликация.
Во-первых, триггеры, которые существуют на ведущем устройстве, должны быть
обновлены на ведомом сервере. Как только это сделано, поток репликации
работает как любой другой стандартный запрос DML, который участвует в
репликации. Например, рассмотрите таблицу
Основанная на строке репликация. Когда Вы используете основанную на строке репликацию, изменения, вызванные выполнением триггера на ведущем устройстве, применены на ведомом устройстве. Однако, сами триггеры фактически не выполнены на ведомом устройстве при основанной на строке репликации, потому что, если ведущее и ведомое устройства применяли изменения с ведущего и, кроме того, триггер, вызывающий эти изменения, был применен на ведомом устройстве, изменения будут в действительности применены дважды на ведомом устройстве, приводя к различным данным по ведущему и ведомому устройствам. В большинстве случаев результат тот же самый для обоих вариантов репликации. Однако, если Вы используете различные триггеры на ведущем и ведомом устройствах, Вы не можете использовать основанную на строке репликацию, потому что основанный на строке формат копирует изменения, произведенные выполнением триггеров на ведущем устройстве ведомым устройствам, а не запросами, которые заставили триггеры выполниться, так что соответствующие триггеры на ведомом устройстве не будут выполнены. Вместо этого любые запросы, выполняющие такие триггеры, должны копироваться, используя основанную на запросе репликацию. |
A.6.1. | Где я могу найти документацию о MySQL Views? |
См. раздел 21.5. | |
A.6.2. |
Есть дискуссионный форум для MySQL Views? |
A.6.3. |
Что происходит с представлением, если основная таблица удалена или переименована? |
После того, как представление было создано, возможно удалить или изменить
таблицу или представление, к которому относится определение. Чтобы проверить
определение представления на проблемы этого вида, используйте запрос
| |
A.6.4. |
У MySQL 8.0 есть табличные снимки? |
Нет. | |
A.6.5. |
MySQL 8.0 имеет осуществленные представления? |
Нет. | |
A.6.6. |
Вы можете вставить в представления, которые основаны на объединениях? |
Это возможно, при условии, что Ваш запрос
Вы не можете вставить в много таблиц с единственной вставкой на представлении. |
A.7.1. |
Где я могу найти документацию для базы
данных MySQL |
См. главу 22. | |
A.7.2. |
Есть ли дискуссионный форум для
|
A.7.3. |
Где можно прочитать спецификацию
ANSI SQL 2003 для |
К сожалению, официальные технические требования не в свободном доступе
(ANSI делает их доступными для покупки). Однако, есть такие доступные книги,
как SQL-99 Complete, Really by Peter Gulutzan and Trudy Pelzer,
которые обеспечивают всесторонний краткий обзор стандарта,
включая | |
A.7.4. |
Что является различием между Oracle Data Dictionary и
MySQL |
Оба обеспечивают метаданные в таблицах. Однако, Oracle и MySQL
используют различные имена таблиц и имена столбцов. Выполнение MySQL более
подобно DB2 и SQL Server, которые также поддерживают
| |
A.7.5. |
Могу я добавлять или иначе изменять таблицы
в базе данных |
Нет. Так как приложения могут положиться на структуру определенного
стандарта, это не должно быть изменено. Поэтому мы не можем
допустить ошибки или другие проблемы, которые следуют из изменения
таблиц или данных в |
A.8.1. | Где я могу найти информацию о том, как мигрировать с MySQL 5.7 на MySQL 8.0? |
Для подробной информации об обновлении см. раздел 2.10.1. Не пропускайте главную версию, обновляя, а завершайте процесс по шагам, обновляя от одной главной версии до следующей на каждом шаге. Это может казаться более сложным, но это будет экономить время и поможет избежать проблем. Если Вы столкнетесь с проблемами во время обновления, то их происхождение будет легче идентифицировать Вам или, если у Вас есть подписка MySQL Enterprise, поддержкой MySQL. | |
A.8.2. |
Как поддержка механизмов хранения (типов таблиц) изменилась в MySQL 8.0? |
Поддержка механизма хранения изменилась следующим образом:
|
A.9.1. | Где я могу найти документацию, которая обращается к вопросам безопасности для MySQL? |
Лучшим местом, чтобы начать является Глава 7. Другие части документации MySQL, которую Вы можете счесть полезным относительно определенных проблем безопасности, включают следующее: | |
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)? |
Нет. |
В следующем разделе мы отвечаем на вопросы, которые часто спрашивают о
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.
| |
A.10.3. |
Сколько компьютеров нужно, чтобы выполнить MySQL Cluster и почему? |
Минимум три компьютера нужны, чтобы выполнять жизнеспособный кластер. Однако, минимальное рекомендуемое число компьютеров в кластере MySQL четыре: по одному, чтобы выполнить управление и узлы SQL, и два компьютера, чтобы служить узлами данных. Цель этих двух узлов данных состоит в том, чтобы обеспечить избыточность, управленческий узел должен работать на отдельной машине, чтобы гарантировать работу арбитражных служб, когда один из узлов данных падает. Чтобы обеспечить увеличенную пропускную способность и высокую доступность, Вы должны использовать много узлов SQL (MySQL Server, соединенные с кластером). Также возможно (хотя не строго необходимо) выполнить много управленческих серверов. |
Этот набор часто задаваемых вопросов получен из опыта поддержки MySQL и групп развития в обработке многих запросов о CJK (китайско-японско-корейских) проблем.
A.11.1. |
Какие наборы символов CJK доступны в MySQL? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Список наборов символов CJK может измениться в зависимости от Вашей версии
MySQL. Например, набор символов 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) наборов символов, которые
официальны в Китайской Народной Республике: Иногда люди пытаются вставить символы Здесь, мы пытаемся разъяснить точно, какие символы законны в
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.2. |
Я вставил символы CJK в свою таблицу. Почему
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Эта проблема обычно происходит из-за установки в MySQL, которая не соответствует настройки для приложения или операционной системы. Вот некоторые общие шаги для того, чтобы исправить эти типы проблем:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.3. |
О каких проблемах я должен знать, работая с китайским набором символов Big5? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MySQL поддерживает набор символов Big5, который распространен в Гонконге и
Тайване (республика Китая). MySQL набор символов Запрос новых функций для того, чтобы добавить расширения
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.4. |
Почему японские преобразования набора символов терпят неудачу? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MySQL поддерживает наборы символов В следующей таблице преобразования столбец
Теперь рассмотрите следующую часть таблицы:
Это означает, что MySQL преобразовывает | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.5. |
Что я должен делать, если я хочу
преобразовать SJIS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Есть серьезные жалобы об этом: много людей предпочли бы
преобразование, так, чтобы | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.6. |
Как MySQL, представляют Иену? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Проблема возникает потому что некоторые версии японских наборов символов
( MySQL следует только за одной версией JIS (Japanese Industrial
Standards). В MySQL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.7. |
MySQL планирует сделать отдельный набор символов где
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Это - одно возможное решение проблемы знака Иены, однако, это не будет происходить в MySQL 5.1 или 6.0. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.8. |
О каких проблемах я должен знать, работая с корейскими наборами символов в MySQL? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
В теории, в то время как было несколько версий набора символов
Мы используем вариант ASCII EUC-KR, в котором кодовая точка
mysql> SELECT CONVERT('Б┌╘' USING euckr) AS euckr, HEX(CONVERT('Б┌╘' USING euckr)) AS hexeuckr; +-------+----------+ | euckr | hexeuckr | +-------+----------+ | ? | 3F | +-------+----------+ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.9. |
Почему я получаю сообщения об ошибках Incorrect string value? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Для иллюстрации мы составим таблицу с одним столбцом Unicode
( 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) Таким образом, это предупреждение только о столбце 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) Несколько вещей нуждаются в объяснении здесь:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.10. |
Почему мой GUI или браузер не выводят на экран символы CJK правильно в моем приложении, используя Access, PHP или другой API? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Получите прямую связь с сервером, используя клиент
mysql
(Windows: mysql.exe
) и попытайтесь выполнить тот же самый запрос там. Если
mysql
отвечает правильно, то проблема может состоять в том, что Ваш интерфейс
приложения требует инициализации. Используйте
mysql, чтобы
сказать, какой набор символов нужен, через использование <% Session.CodePage=0 Dim strConnection Dim Conn str Connection="driver={MySQL ODBC 3.51 Driver};server= Почти таким же способом, если Вы используете какой-либо набор символов,
кроме Если Вы используете 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'"); ?> В этом случае мы использовали Другая проблема, с которой часто сталкиваются в приложениях PHP, имеет
отношение к предположениям, сделанным браузером. Иногда добавляя или изменяя
тэг Если Вы используете 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:
Эффект этого состоит в том, что Вы не можете управлять набором символов
клиента, запуская mysqld
с опцией
Посредством примера, предположите, что Ваш любимый набор символов сервера
mysqld --character-set-server=latin1 И затем запустите клиента с набором символов
по умолчанию mysql --default-character-set=utf8 Текущие настройки могут быть просмотрены через
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 Запустите клиента еще раз с 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) Как Вы можете видеть, сравнивая отличающиеся результаты
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.12. |
Почему некоторые поиски
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Есть очень простая проблема с
+-------------------------+---------------------------+ | OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'Ц┐ ') | +-------------------------+---------------------------+ | 1 | 3 | +-------------------------+---------------------------+ 1 row in set (0.00 sec) Если мы не знаем, где первый символ заканчивается, то мы не знаем, где
второй символ начинается, когда даже очень простые поиски, например,
Это одна из причин, почему MySQL не может позволить кодировки несуществующих символов. Если нет строгого ограничения об отклонении плохого ввода, то нет никакого способа знать, где символы заканчиваются. Для поисков | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.13. | Как узнать,
доступен ли символ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Большинство упрощенного китайского и основных символов японского алфавита
появляется во всех наборах символов CJK. Эта хранимая процедура принимает
символ 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// Ввод может быть любым символом 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) Так как ни одно из значений столбцов не | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.14. |
Почему CJK сортирует в виде строки неправильно в Unicode? (I) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Иногда люди замечают что результат поиска с
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,
которое возможно найти, читая шестнадцатеричное число для
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 ; [.1E57.0020.000E.304B] # HIRAGANA LETTER KA 304C ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM Официальные имена Unicode (после #) указывают на японскую
слоговую азбуку (Hiragana), неофициальная классификация
(буквы, цифры и знаки препинания) и западный идентификатор ( | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.15. | Почему CJK сортирует в виде строки неправильно в Unicode? (II) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Если Вы используете Unicode ( 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 Так как набор символов, кажется, правилен, давайте смотреть, что
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 | +-------------+--------------------+-----------------+ Вы можете видеть, что сопоставление 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) Для | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.16. |
Почему мои дополнительные символы отклонены MySQL? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
До MySQL 5.5.3 MySQL не поддерживает дополнительный набор символов,
то есть, символы, которые нуждаются больше, чем в 3 байтах для
Одно возможное обходное решение должно использовать С MySQL 5.5.3 поддержка Unicode расширена, чтобы включать дополнительные
символы посредством дополнительных наборов символов Unicode:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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, автоматически переписывая названия соответствующих каталогов и файлов. Например, если Вы создаете базу данных | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.19. |
Где я могу найти переводы руководства MySQL на китайский, японский и корейский языки? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Японский перевод руководства MySQL 5.6 может быть загружен с downloaded from http://dev.mysql.com/doc/. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A.11.20. |
Где я могу получить справку по CJK и связанным проблемам в MySQL? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Следующие ресурсы доступны:
|
Для общих вопросов, касающихся MySQL Connector и других API, см. следующие области руководства:
В следующем разделе мы обеспечиваем ответы на вопросы, которые наиболее часто встречаются в темах о репликации в MySQL.
A.13.1. |
Ведомое устройство должно быть соединено с ведущим устройством все время? |
Нет. Ведомое устройство может отключиться в течение многих часов или даже дней, и затем повторно соединиться и нагнать обновления. Например, Вы можете настроить основные/ведомые отношения по коммутируемой линии, где связь бывает только спорадически и в течение коротких промежутков времени. Значение этого то, что в любой момент времени ведомое устройство не будет в синхронизации с ведущим устройством, если Вы не предпримете некоторые специальные меры. Чтобы гарантировать, что синхронизация может быть выполнена для ведомого устройства, которое было разъединено, Вы не должны удалять двоичные файлы системного журнала ведущего устройства, которые содержат информацию, которая еще не копировалась к ведомым устройствам. Асинхронный ответ может работать, только если ведомое устройство в состоянии продолжить читать двоичный журнал с того места, где чтение было прервано. | |
A.13.2. |
Я должен включить сеть на моем ведущем и ведомом устройствах, чтобы включить репликацию? |
Да, сеть должна быть включена на ведущем и ведомом устройствах. Если сеть не
включена, ведомое устройство не может соединиться с ведущим и передать
двоичный журнал. Проверьте, что опция
| |
A.13.3. |
Как я узнаю дату последнего запроса, копируемого ведомым устройством? |
Проверьте столбец Когда ведомый поток SQL запускает событие, считанное с ведущего
устройства, он изменяет свое собственное время к timestamp события.
Это причина того, почему | |
A.13.4. |
Как я вынуждаю ведущее устройство заблокировать обновления, пока ведомое его не нагонит? |
Используйте следующую процедуру:
| |
A.13.5. |
О каких проблемах я должен знать, настраивая двухстороннюю репликацию? |
Репликация MySQL в настоящее время не поддерживает протокола блокировки между ведущим и ведомым устройством, чтобы гарантировать атомичность распределенного обновления. Другими словами, для клиента A возможно сделать обновление cо-ведущего устройства 1, а тем временем, прежде, чем это размножится на cо-ведущее устройство 2, клиент B мог сделать обновление cо-ведущего устройства 2, которое делает обновление клиента A, работающего по-другому, чем это сделано на cо-ведущем устройстве 1. Таким образом, когда обновление клиента А сделано на cо-ведущем устройстве 2, это производит таблицы, которые отличаются от того, что Вы имеете на cо-ведущем устройстве 1, даже после того, как все обновления от cо-ведущего устройства 2 также размножились. Это означает, что Вы не должны объединить два сервера в цепочку вместе в двухсторонних отношениях репликации, если Вы не уверены, что Ваши обновления могут безопасно произойти в любом порядке, или если Вы заботитесь о неправильных упорядоченных обновлениях так или иначе в коде клиента. Вы должны также понять, что двухсторонняя репликация фактически не очень улучшает работу (если вообще). Каждый сервер должен сделать то же самое число обновлений, как если бы у Вас был единственный сервер Единственная разница то, что есть немного меньше блокировок, потому что обновления, происходящие на другом сервере, преобразованы в последовательную форму в одном ведомом потоке. Даже эта выгода может быть нивелирована сетевыми задержками. | |
A.13.6. |
Как я могу использовать репликацию, чтобы улучшить производительность моей системы? |
Настройте один сервер как ведущее устройство и пишите все на него. Тогда
сконфигурируйте так много ведомых устройств, как Вам позволяет бюджет,
и распределите чтения между ведущим и ведомыми устройствами. Вы можете также
запустить ведомые устройства с опциями
| |
A.13.7. |
Что я должен сделать, чтобы подготовить код клиента в моих собственныхприложениях, чтобы использовать улучшающую работу репликацию? |
См. руководство по использованию репликации в разделе 19.3.5. | |
A.13.8. |
Когда и насколько репликация MySQL может улучшить производительность моей системы? |
Репликация MySQL является самой выгодной для системы, которая обрабатывает частые чтения и нечасто пишет. В теории, при использовании варианта с одним ведущим и несколькими ведомыми серверами Вы можете масштабировать систему, добавляя больше ведомых устройств до нужного числа. Чтобы определить, сколько ведомых устройств Вы можете использовать,
и насколько Вы можете улучшить исполнение своего сайта, Вы должны знать свои
образцы запроса и определить опытным путем эффективность отношения пропускной
способности для чтения и записи на типичных ведущем и ведомом устройствах.
Пример здесь показывает весьма упрощенное вычисление того, что Вы можете
получить с репликацией для гипотетической системы. Через
Скажем, системная загрузка состоит из 10% записей и 90% чтений
и мы определили эффективность
9 *
Последнее уравнение указывает максимальное количество записей для
Этот анализ приводит к следующим заключениям:
Эти вычисления принимают бесконечную сетевую пропускную способность и
пренебрегают несколькими другими факторами, которые могли быть существенными
на Вашей системе. Во многих случаях, Вы не можете быть в состоянии выполнить
вычисление, подобное только что показанному, которое точно предсказывает то,
что произойдет на Вашей системе, если Вы добавите
| |
A.13.9. |
Как я могу использовать репликацию, чтобы обеспечить избыточность или высокую доступность? |
То, как Вы осуществляете избыточность, полностью зависит от Вашего приложения и обстоятельств. Высоконадежные решения (с автоматическим аварийным переключением) требуют, чтобы активный контроль и\или пользовательские скрипты (или сторонние инструменты) оказали поддержку от оригинального сервера MySQL до ведомого устройства. Чтобы обработать процесс вручную, Вы должны быть в состоянии переключиться от упавшего ведущего устройства на предварительно сконфигурированное ведомое, изменяя Ваше приложение, чтобы говорить с новым сервером или корректируя DNS для сервера MySQL. | |
A.13.10. |
Как узнать использует ли главный сервер репликацию, основанную на запросе или на строке? |
Проверьте значение переменной
mysql> SHOW VARIABLES LIKE 'binlog_format'; Показанное значение будет одним из: | |
A.13.11. |
Как сказать ведомому устройству использовать основанную на строке репликацию? |
Ведомые устройства автоматически знают который формат использовать. | |
A.13.12. |
|
Запустите сервер с опцией
| |
A.13.13. |
Репликация работает со смешанными операционными системами (например, основной сервер под Linux, ведомые под OS X и Windows)? |
Да. | |
A.13.14. |
Репликация работает со смешанной архитектурой аппаратных средств (например, основной сервер на 64-битной, а подчиненные на 32-битных системах)? |
Да. |
A.14.1. |
Какие типы операций меняют вторичные индексы и результат в буфере изменений? |
| |
A.14.2. |
Что является выгодой буфера изменения |
Вторичная буферизация индексирует изменения, когда вторичные индексные страницы не находятся в буферном бассейне, это позволяет избегать дорогих операций ввода/вывода произвольного доступа, которые были бы обязаны немедленно читать затронутые индексные страницы с диска. Буферизованные изменения могут быть применены позже, в пакетах, когда страницы считаны в буферный бассейн другими операциями чтения. | |
A.14.3. |
Буфер изменений понимает другие типы индексов? |
Нет, только вторичные индексы. Кластеризируемый, полнотекстовый и пространственный индексы не поддержаны. Полнотекстовый индекс имеет собственный механизм кэширования. | |
A.14.4. |
Как много места |
До введения опции
В MySQL 5.6 и позже опция
Буферные страницы изменения не обязаны сохраняться в буферном бассейне и могут быть удалены операциями LRU. | |
A.14.5. |
Как определить текущий размер буфера изменения? |
Текущий размер буфера изменения сообщает
------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf: size 1, free list len 0, seg size 2, 0 merges Соответствующие точки данных включают:
| |
A.14.6. |
Когда выполняется слияние буфера изменений? |
| |
A.14.7. |
Когда буфер изменения сбрасывается? |
Обновленные страницы сбрасываются тем же самым механизмом, который сбрасывает другие страницы, которые занимают буферный бассейн. | |
A.14.8. |
Когда используется буфер изменений? |
Буфер изменения особенность, разработанная, чтобы уменьшить случайный
I/O вторичных индексов, когда индексы растут и больше не вписываются в
буферный бассейн | |
A.14.9. |
Когда буфер изменений не используется? |
Вы могли бы рассмотреть отключение буфера изменения, если весь набор данных
помещается в буферный бассейн | |
A.14.10. |
Где я могу найти дополнительную информацию о буфере изменения? |
Следующие разделы и сообщения в блогах обеспечивают дополнительную информацию
о буфере изменения |
A.15.1. |
Данные дешифрованы для пользователей, которые уполномочены видеть их? |
Да. Шифрование табличного пространства | |
A.15.2. |
Что является накладными расходами,
связанными с шифрованием табличного пространства |
Нет никакого дополнительного хранения. Согласно внутренним точкам отсчета, разница в производительности около 0,1%. | |
A.15.3. |
Что является алгоритмами шифрования,
используемыми в шифровании табличного пространства |
Шифрование табличного пространства | |
A.15.4. |
Возможно использовать сторонние алгоритмы
шифрования вместо обеспеченного |
Нет, невозможно использовать другие алгоритмы шифрования. | |
A.15.5. |
Индексированные столбцы могут быть зашифрованы? |
Шифрование табличного пространства | |
A.15.6. |
Какие типы данных и длины данных
поддерживает шифрование табличного пространства |
Шифрование табличного пространства | |
A.15.7. |
Данные остаются зашифрованными в сети? |
Данные, зашифрованные | |
A.15.8. |
Память базы данных содержит открытый текст или зашифрованные данные? |
С | |
A.15.9. |
Как я узнаю, которые данные зашифровать? |
Согласие со стандартом PCI-DSS требует, чтобы номера кредитной карточки (Primary Account Number, 'PAN') были сохранены в зашифрованной форме. Законы об уведомлении (например, CA SB 1386, CA AB 1950 и подобные) требуют шифрования имени, фамилии, номера водительских прав и других личных данных. В начале 2008 CA AB 1298 добавил медицинскую и информация о медицинском страховании к данным PII. Кроме того, могут быть отраслевые стандарты и требования по этой части. | |
A.15.10. |
Как шифрование табличного пространства
|
Есть симметричные и асимметричные API шифрования в MySQL, которые могут
использоваться, чтобы вручную зашифровать данные в пределах базы данных.
Однако, приложение должно управлять ключами шифрования и выполнить требуемое
шифрование и дешифрование, вызывая функции API. | |
A.15.11. |
Переносимы ли зашифрованные данные? |
Да. | |
A.15.12. |
Сжимает ли данные шифрование |
Клиенты, использующие шифрование табличного пространства | |
A.15.13. |
Можно ли применить
mysqlpump
или |
Да. Поскольку эти утилиты создают логические резервные копии, данные, выведенные из зашифрованных таблиц, не зашифрованы. | |
A.15.14. |
Как сменить основной ключ шифрования? |
Шифрование табличного пространства | |
A.15.15. |
Как мигрировать данные из открытого текста
в зашифрованное табличное пространство |
Передача данных из одного табличного пространства в другое не требуется.
Зашифровать данные в |
A.16.1. |
MySQL поддерживает виртуальное окружение Oracle VM, VMWare, Docker, Microsoft Hyper-V или что-то такое? |
MySQL поддерживает виртуальное окружение, но сертифицирован пока только для Oracle VM. Подробности в техподдержке Oracle. |