BiTel

Вот пришла пора обновляться с 6.0 на 6.1(6.2).
Имеем сейчас Centos 6 (x64), штатный mysql-5.1.73-3 и раздел под БД 100ГБ, которого уже катастрофически не хватает.
Что хочется во время перехода?

Так вот несколько вопросов по последнему пункту:
- кто-то делал перевод БД на UTF-8?
- как переводили базу и сколько это заняло времени?
- как изменился размер баз?
- если ли смысл вообще переводить БД на UTF-8? (желание у меня есть)
- какие подводные камни вылазили при переводе БД?

P.S.
Никто не пробовал использовать для БД BGBilling?
XtraDB/InnoDB Barracuda file format (ROW_FORMAT=COMPRESSED)
или
XtraDB/InnoDB Barracuda file format (Page compression)

Для 6.2 и далее очень рекомендуется utf-8 (и новые установки давно в utf-8 создаются), но всё по желании.
Можно и на 1251 работать. Но лично я бы не смог, нет.
Я нашу базу конвертил простым скриптом с CONVERT каждой таблицы.

_________________
I'm clever. I've got a computer.

как-то вот так:
https://github.com/darkbarker/trifles/b ... ql2utf8.sh
накидывал на скорую руку, но делаются нужные проверки и там всё довольно примитивно вроде как, но советую на копию сделать, конечно)

_________________
I'm clever. I've got a computer.

Спасибо за образец скрипта - было что-то похожее, но Ваш поинтереснее...
Только вот насчет COLLATE utf8_unicode_ci ... я обычно использую utf8_general_ci, да и пишут, что побыстрее работает при поиске.

Просто раздел под БД -100 ГБ, забитый под завязку уже год от модулей Inet - каждый месяц перевожу в MyISAM кучу таблиц.
Таблиц очень много - файлов:

Вот и спрашивал о практических переводах (не пустых баз)...

А что можете сказать по поводу сжатия таблиц модeля Inet, используя
XtraDB/InnoDB Barracuda file format (ROW_FORMAT=COMPRESSED)
или XtraDB/InnoDB Barracuda file format (Page compression)?

Вопрос частично философский. Если гуглить - то можно сторонников и того и того найти, я перечитал кучу инфы на этот счёт и решил, что нет никакого резона использовать utf8_general_ci . Многократного поиска по юникодным строкам в биллинге вроде как нету. При этом utf8_unicode_ci идеологически более верный.

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

Про сжатие ничего не скажу, этот вопрос не изучался у нас вроде как.

_________________
I'm clever. I've got a computer.

А почистить сами таблицы не хотите перед переводом? У нас таблицы типа connection_log_entry_{mid}_201211 занимали очень много места при том, что на диске самих данным давно не было. От старых модулей тоже была куча данных - их забекапили и таблицы удалили.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Пока не чищу, а бекаплю и перевожу в MyISAM( с удалением индексов и партицирования, где есть) - места уменьшается в несколько раз.
Старых модулей пока нету - пока все 7 (семь) модулей Inet рабочие и планируется еще добавлять.
Еще очень хочу поиграться со сжатием таблиц Inet.

Что в итоге получилось со сжатием, если не секрет?