rPman

Но при нынешних ценах на дисковое пространство попытка добыть пару лишних мегабайт сжатием - крайне неразумное занятие. Дополнительные процессорные ресурсы на него стоят куда как дороже.

люто плюсую.

Но если прямо очень нужно, то советую вместо сжатия средствами БД, попробовать сжать средствами файловой системы (например btrfs - zstd, 16 уровней сжатия), можно поиграть с разным размером кластера, что может сильно повлиять на результат... особенно если в базе данных соседние поля с одинаковыми данными, а движок их упаковывает независимо.

Скорость записи в базу данных на сжатом диске сильно упадет, особенно если делать большой размер кластера (так как это увеличивает степень сжатия), но вот скорость чтения, особенно с hdd, даже может подрасти (особенно при хорошей степени сжатия), но должно много всего совпасть.

НАСТОЯТЕЛЬНО рекомендую файлы индексов не сжимать, за исключением случаев, когда они целиком и полностью влезают в оперативную память и запись в базу данных не производится.

ОБЯЗАТЕЛЬНОЕ тестирование всей конструкции на реальных данных перед запуском в продакшен, иначе можно получить проблему, и конечно же бакапы, без них ничего делать даже не начинай.

p.s. наилучшее сжатие можно получить, если грамотно его реализовать на стороне самого приложения, ведь его разработчик знает, где какие данные как лежат, как их можно эффективно перераспределить и главное, есть библиотеки типа того же zstd, когда можно держать несколько словарей для сжимаемых данных, специально собранных под свои наборы данных,.. отличный пример сжатие xml/json файлов, где теги/атрибуты могут занимать до 90% пространства,.. и при маленьком размере сжимаемого куска, словарь на них будет в каждом куске свой.. а вот общий словарь для всего пакета файлов позволит на порядок сократить их объем.

p.p.s. само собой, замена xml/json на правильно созданный protobuf исключит эту проблему в зачатке

Смотри что выполняется в базе show processlist, в идеале профилируй все запросы, смотри какие больше всего времени выполняются, сделать это можно как на стороне приложения (бакэнда), особенно если используется какая то прослойка для базы данных, так и средствами базы данных, гугли mysql slow query log (на самом деле там куча способов проанализировать работу но чаще удобнее это делать со стороны бакэнда)

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

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

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

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

SELECT CASE
  WHEN USER() =='one@localhost' THEN 1
...
  ELSE 0
END

т.е. местом хранения тут будет код хранимой процедуры или вьюхи а для ее обновления потребуется вызов ddl

Информации мало, но проверьте внимательнее, возможно между запросом и ответом от базы данных стоит еще какой то код, может в нем ошибка?

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

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

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

Консоль в windows с кодировкой cp866, поэтому и 'кракозяблы'… что в test.txt?
mysql .... -e "select * from table" > test.txt

Пожалуйста, умоляю, не делайте постраничную выборку… всеми силами избавляйте пользователя от постраничного сканирования… это сложно/медленно для сервера (недавно анализировал очередной высер для распила госбюджета — выборка записи из справочника из 13т. записей 1500 страниц… кому такой бред нужен, кстати тормозит по 3 секунды на любой пшик)

Любой выбор больше 10-20 записей должен быть исключен (на самом деле можно потерпеть и 100… но больше значит где то забыли сделать возможность указания критерия выбора), там где это возможно — введением категорий, и в любом случае сделать полнотекстовый поиск-фильтр для данных с максимальной информативностью о результатах.

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

Ответ кроется в том, как именно происходит поиск в строках? сравнение, подстрока like, полнотекстовый индекс. Что ищется… случайная строка или ключевое слово (подстроки, заранее определенные и редко изменяемые, максимум дополняемые). Так же очень важно каких запросов больше и на сколько (изменения, добавления, удаления, чтение или поиск).

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