Таблица xf_search_index в XF

Зачем? Я думаю что все непечатные символы он вырезает из запроса.
Вы много думаете. Разберитесь с работой встроенного поискового движка и поймёте для чего это нужно. Либо поймёте, что это не нужный мусор и исправите это недоразумение. Благо, движок расширяем в этом плане.
А пока вы никакого понятия не имеете, читать утверждения о том, что что-то работает тем, или иным образом - крайне забавно.
 
Если это то, о чём я думаю - это прекрасно разруливается конфигурированием веб-сервера.
Не знаю кто о чем думает.
Я сделал что-бы движок не генерировал и не сжимал каждый раз большой css, кстати там их два.
А скачал его, сжал в GZ, разместил его на сайте, и отдаю уже готовым, статичным с заголовком header set content-encoding gzip, который указал для него через rewrite в htaccess. В движке закоментировал генерацию. Время генерации страницы и серверная нагрузка уменьшились.
 
Последнее редактирование:
Это, и другие оптимизации конечно я сделал "под себя". Другим может это и не нужно. Хотя, наверное мало кто откажется что-бы его сайт открывался быстрее.

это прекрасно разруливается конфигурированием веб-сервера.
Сервер не нужно конфигурировать.
Все решается на уровне сайта, и маленькой директивы в htaccess.
 
Последнее редактирование:
Долго расписывать, но вот взять хотя-бы только символы CHAR(10) .
В mysql они занимают 10 байт каждый. А там CHAR(10) + CHAR(13) .
Зачем они там ? Это не печатные символы возврата каретки и переноса строки. Они нужны только для корректного отображения текста на экране. Кто-нибудь ищет возврат каретки ?
Если быть настолько загруженным, то можно дойти до сути жизни и познать её.

Эта оптимизация (с удалением двух символов, размер которых вкупе будет от 2 до 8 байт - ) освободит до 2 мб для одной строки, в которых опять же может не содержаться эти два символа вовсе. И когда дело доходит до такого абсурда, то стоит вспомнить, что БД всегда занимала не мало места, особенно для большого количества строк данных.
Там хранятся эти переходы за тем, чтобы хоть как-то поиск на MySQL работал по словам, а не оператором LIKE, который может занять процессорное время на большое количество времени, чем нынешний Full text index.

Не нужно доводить всё до абсолюта и ужираться оптимизацией индексов и якобы "сократил размер бд на 25%". Удалите на своём форуме темы и посты, которые не несут смысловой нагрузки и перестройте индекс из АП.
 
Не нужно доводить всё до абсолюта и ужираться оптимизацией индексов и якобы "сократил размер бд на 25%".
Ну, не нужно так не нужно.
Буду потихоньку сам экспериментировать, есть еще куча идей )
 
До абсурда - это когда заходишь в базу и удаляешь все индексы со всех колонок во всех таблицах.
Экономия? Да. Но в обмен на скорость поиска записей (и не только).
 
  • Мне нравится
Реакции: Hope
Не переборщи с натрием.
Не, я форумом практически не занимаюсь. Там отдельный админ и модераторы есть
Он на 100 рублевом хостинге, а сегодня обнаружил что места на хостинге кирдык, вот и полез ужать везде по немногу
Цена следующего тарифа там что-то мне нравится ))
 
Последнее редактирование:
Когда место снова закончится, но уже из-за кол-ва контента - будете сносить старый? Не позорьтесь, увеличьте объём места.
 
Не позорьтесь, увеличьте объём места.
Ну был-бы это чисто мой форум, я может бы подумал. А я помогаю пацанам чисто из спортивного интереса. Даже оплатил хостинг со своего кармана. Но самый дешевый, потому как с дочерью Рокфеллера не знаком что-бы заниматься большой благотворительностью ))
 
Современный облачный хостинг провайдер | Aéza
Назад
Сверху Снизу