Оптимизация работы сайта

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

На самом деле глупо расставлять индексе с "заделом на будущее", если нет функционала, который будет юзать этот индекс, то индекс будет только тормозить и увеличивать место занимаемое БД. Часто бывает так, что при разработке каких то своих выборок, ты начинаешь делать SQL с фильтрами которые раньше нигде не использовались и они начинают промахиваться и CMS начинает "тормозить". Очень часто решается анализом SQL и доустановкой нужных индексов + я видел как индексы слетали, не интересовался по какой причине, но случаи бывали. Ну и вполне возможно самописный модуль, сообщество J не сильно отличается по скилам от сообщества W, многие даже не знают что такое индексы

Хм.. для меня несколько удивительно что индексы тормозят. Когда я учился кодить и работать с базой (не только MySql, но и др) - вроде всегда индексы использовались. Но я уже давно бросил так глубоко копать так что не в курсе.

И я не раз. Это происходило при неправильной миграции базы.

И если через PMA сделать.. вот не помню то ли копирование таблицы то ли изменение кодировки то ли ещё что-то. Теряются и ключи и индексы.

Это всегда было так, индексы ускоряют выборку, но замедляют запись/изменение/удаление, по этому если в таблицу в основном пишут, то ей индексы противопоказаны. У меня был один ИМ на поддержке, там БД была 17Гб, а в месте с индексами занимала место на диске больше 100Гб, ну и все операции записи/удалении/изменения естественно работают дольше с индексами, чем без. По этому например рекомендуют записи с таблицы не удалять а помечать как уаленные, потому что перестроить таблицу индексов на например 30 млн строк операция не быстрая))

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

---------- Добавлено 20.02.2020 в 14:04 ----------

Да, тоже доводилось работать с такой базой данных, но тогда сервера слабее были. У нас тоже была отложенная индексация, которая запускалась на ночь и молотила до утра. Так что индексы могут посадить железо. В таких случаях еще делают разделение функций записи и чтения на разные железки с синхронизацией на уровне СУБД.

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

---------- Добавлено 20.02.2020 в 14:09 ----------

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

danforth, то ,что ты мастер постить тупые мемасики - я в курсе. По существу когда будешь отвечать про webp? Или понял что тупишь и по-тихому решил слиться? Так тогда неча по другим топикам активизироваться.

Да не ребят, я посмотрел там и БД и запросы. Там выключен кэш т.е. идёт по 350-400 запросов к БД. В основном затупы при записи сессии, как принято у джумлы это делается в БД. Я сделал таблицу MEMORY, но что-то хостеру вообще попалам на это.

Да там были места, где нет индексов, но там таблицы по 100 строк. Я рекомендовал менять хостера.

А что за хостер? таймвэб какой нибудь или спейсвэб? или можордомо?