edogs, мне реально глубоко пофигу, что и как там что считает :)
Я поделился новинкой. которую реализовали в MariaDB. Кому надо заюзают, кому не надо пусть живут дальше.
Вы сами тестировали сжатые таблицы полностью? Я тестировал. Это УГ на динамических проектах. Именно в этом и проблема, что индексы тоже сжимаются, и чтобы их считать они разжимаются каждый раз.
А тут и индексы целы и информация сжата.---------- Добавлено 13.11.2019 в 18:45 ----------Вот есть тесты по сжатию персоны:
https://mydbops.wordpress.com/2019/10/06/save-space-on-mysql-data-with-column-compression/
И там как раз при сжатии полностью таблицы, не всё так радужно по экономии места:
---------- Добавлено 13.11.2019 в 19:08 ----------
Только рекомендую делать так:
1. Сделать копию таблицы, можно даже через phpmyadmin. Просто когда будет делаться копия, она будет делаться на чистую и если было много удалений в таблице, то они тоже очистятся и освободится место. Напоминаю, что при InnoDB данные не удаляются, а просто помечаются как удалённые и скрываются, и место не освобождается.
2. Ужать всё, что надо на копии таблицы
3. Переименовать таблицы копию на OLD, а копию переименовать на оригинал.
Я тоже такое юзаю для доров. И хотел найти такое же, но без изменения скриптов и структуры данных. И оказывается реализовали. Кстати это ещё раньше появилось в Percona Server Mysql, там более расширенный функционал.
Просто процессоры это не только гигагерцы, это ещё всякие интересные инструкции и сопроцессоры, которые помогают как раз выполнять сжатие и разжатие + не забываем, что разжатие идёт с распределением по всем ядрам т.е. это долисекунды для многоядерного сервера. А вот чтение с диска, это более дорогое удовольствие в плане скорости. На современных веб сервера уже давно всё упёрлось в диск, процессор просто отдыхает в основном. Да и Чё?! ему делать то? 1 раз просчитать мелкий PHP скрипт, а потом заниматься передачей данных с диска пользователю.
Да ничего она не грузит. Уже давно не IBM386 стоит. То что, у большинство nginx сжимает на лету данные и отдаёт клиенту в доли секунды не напрягает, никто не париться.
Кто же спорит, если у вас там по 1 ляму посетителей на сайте, там уже по другому надо делать и решать. И то возможно при стресс тестах там всё будет нормально.
Я же говорю о новинке, которая может пригодиться как и мне.
Вот как раз для этого, чтобы НЕ выносить и НЕ менять структуру рабочего проекта и реализовали такой функционал. НО! Если даже структуру "правильная", почему и не сжать тоже эти данные массивные.
---------- Добавлено 13.11.2019 в 11:56 ----------
Сама база в производительности вообще не меняется т.к. все данные и индексы доступны также без сжатия, время уходит исключительно на процессор и момент декомпрессии. По умолчанию там стоит степень сжатия 6, я думаю это оптимальное соотношения размер данных и скорость их разжатия.
Я просто до этого тестировал, когда таблица в полном сжатии т.к. у неё тип Сжатый. Вот там ППЦ производительность падает. Кому нужен такой тип таблиц, я даже не знаю. Если только хранить какие-то архивы, которые запрашивают раз в неделю, на динамические сайты, вообще не катит.---------- Добавлено 13.11.2019 в 12:05 ----------
Именно так, поэтому я сжимал новостной сайт, где текст новости 2500-5000 знаков. Сжимать данные до 255 символов не вижу смысла реального.
доступ можете на файлы в личку скинуть? Я что-то в такие чудеса не верю. Возможно при подключении не учитывается кодировка.
В меню, "Кодировка", стоит utf-8?
Визуально всё ли читается в самом файле, никаких проблем кодировкой нет?
Теперь создавайте БД новый и туда заливайте этот архив
Сделайте экспорт БД и посмотрите, через notepad++ в UTF8 всё ли там. И сделайте импорт в чистую другую базу.
Что-то сомневаюсь, что там всё ок :)
У каждой таблице такое или там у нас latin стоит у всех таблиц?
В PHPmyadmin отображается всё нормально?
И урл сайта покажите.
Обмен шила на мыло.
