Настройка и проверка работоспособности MySQL

[STALKER_SLX]

Здравствуйте уважаемые форумчане!
При настройке MySQL-сервера под управлением ОС Ubuntu 14.04 столкнулся с некоторыми трудностями.
В связи с этим, прошу Вас посильной помощи начинающему админу!
 
1.1. Изменение в MySQL-сервере кодировки баз данных по умолчанию на UTF-8.

Для этого добавил такие строки в конфигурационный файл /etc/mysql/my.cnf:

под разделом [client]
default-character-set=utf8

под разделом [mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
init-connect = "set names utf8"
 
Перезапустил MySQL-сервер: service mysql restart.
Ошибок в журнале /var/log/mysql/error.log пока не выявил.

Новые базы создаются уже с новой кодировкой по умолчанию - UTF-8, без указания дополнительных параметров, то есть:
create database petrov_newdb;
 
1.2. Нужно ли вносить какие либо другие изменения в конфиг, чтобы MySQL-сервер работал корректно? Если да, то какие именно?
1.3. Какой командой проверить/протестировать этот конфигурационный файл MySQL-сервера на ошибки?
1.4. Скажется ли изменение кодировки MySQL-сервера по умолчанию на уже существующие базы данных, где используется другая кодировка (например, cp1251)? Если да, то каким образом?

2.1. Методом «научного тыка» я выяснил, что в терминале (выйдя из оболочки MySQL) можно вручную узнать кодировку определенной базы из файла «db.opt», который находится в папке с базой (для каждой базы свой файл). Например, для базы «sidorov_newdb» путь будет таким:

cat /var/lib/mysql/sidorov_newdb/db.opt

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

2.2. Как узнать кодировку дампа базы/файла MySQL, которая в нём используется (находясь в оболочке MySQL)? Без использования phpMyAdmin.

3.1. Правильно ли я понимаю, что в дампе базы данных (файл с расширением «*.sql») хранится не только текстовая информация, но и картинки, флеш и другое медиа (например для веб-сайтов)? Если да, то возможно ли это содержимое просмотреть, не разворачивая его с помощью веб-сервера?

P.S.: Прошу Вас сильно не ругать!

[Уваров А.С.]

1. Не нужно, не скажется и вообще особого смысла данная настройка не имеет, разве что базы у вас создаются скриптом на автомате.

2.1 SHOW CREATE DATABASE или SHOW CREATE TABLE

2.2 Открыть и посмотреть заголовок

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

[STALKER_SLX]

       1. Возможно ли, конвертировать базу данных с одной кодировкой, например UTF-8, в базу с другой кодировкой – cp1251, не потеряв при этом данные?! Если да, то укажите, пожалуйста, некоторые самые удобные варианты, в том числе и для обратной конвертации: из cp1251 в UTF-8.

      2. Встречались ли кому-нибудь из Вас на практике задачи, где нужно было конвертировать только лишь одну таблицу отдельно от всей базы? Если да, то каким образом?
      3. Существуют ли гибридные комбинации, где база создана в кодировке, например UTF-8, а отдельные таблицы этой самой базы имеют совершенно иную кодировку, например cp1251.
Жизнеспособны ли такие варианты или это все глупости ?!

Спасибо за понимание

[Уваров А.С.]

1. Можно. Есть стандартные функции MySQL для этого: https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html

Насчет "удобных" вариантов - исходите из своих знаний и умений, кому-то проще написать пару SQL-запросов, а кому-то лучше потыкать мышкой в phpMyAdmin.

2. Можно и одну таблицу, и не одну. Методы и инструменты те же самые.

3. Да свободно. Все это вполне жизнеспособно, но только вот заводить подобный зоопарк без крайней на то необходимости не стоит. Внизу скриншот из реальной базы, которая (так исторически сложилось), была создана в latin1, потом в нее писали в cp1251, потом перешли на utf8, а затем на utf8mb4 и сменили движок на InnoDB с MyISAM.

Единственная сложность - обо всем этом нужно помнить, какие данные где и в какой кодировке лежат.

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