Проблема с индексами sql
Использовал поле longtitle для количества товара при синхронизации через mSync. Чтобы поле сделать числовым и сортируемым залез в phpMyAdmin и поменял varchar на decimal(12,2) убрав его в отдельный индекс BTREE. Но после этого синхронизация стала есть кучу ресурсов сервера. Сейчас нужно заново синхронизировать 17000 позиций, хостинг ругается на огромное превышение Нагрузки MySQL
Совсем не знаком с БД, не могу понять что можно с этим сделать. Предполагаю что сломал индекс content_ft_idx ведь до этих манипуляций там был один уникальный элемент, а теперь все 12124 ресурса.
Совсем не знаком с БД, не могу понять что можно с этим сделать. Предполагаю что сломал индекс content_ft_idx ведь до этих манипуляций там был один уникальный элемент, а теперь все 12124 ресурса.
Поблагодарить автора
Отправить деньги
Комментарии: 8
Я думаю вам поможет только бэкап базы если он есть. Ну и mSync передаёт остатки из любого поля которое вы ему укажите, в базе ковыряться не нужно.
спасибо. с бекапом не получится уже к сожалению. Поменял поле количества на Weight, отключил все возможные плагины (например moddevtools тоже срабатывал на каждый обновляемый товар при синхронизации) но всё равно жутко ресурсоёмкий процесс получается
Просто нет слов. Достойно рубрики «Курьёзы и юмор». А заказчика жалко.
нет заказчика) самостоятельные эксперрименты. Пара слов были бы всё-таки полезны… я бы и сам с удовольствием посмеялся потом
Тогда мы вам очень сочувствуем, но придётся всё сносить.
конструктивно. Форум для сочувствия оказывается, а я думал для работы над ошибками. В чём суть «Курьёза и юмора» то? и как в следующий раз не загубить базу? да, совсем нет знаний, но беда в том, что нет на столько, что нет идей что искать в гугле, поэтому и приходится беспокоить глупыми вопросами людей на форуме.
В базе я сделал три действия: из общего индекса FULLTEXT убрал поле Longtitle, поставил ему тип BTREE и поменял varchar на decimal(12,2) больше никаких действий с базой. Вокруг этого читаю форумы, но не нахожу в чём собственно юмор.
В базе я сделал три действия: из общего индекса FULLTEXT убрал поле Longtitle, поставил ему тип BTREE и поменял varchar на decimal(12,2) больше никаких действий с базой. Вокруг этого читаю форумы, но не нахожу в чём собственно юмор.
Ну тут нужно следующее учесть:
1. После обновления системы у Ваши вмешательства с БД скорее всего полетят.
2. Если вы хотите в site_content использовать свои, в ручную добавленные поля, то погуглите — есть решения через плагины (только так не надо делать, да и вообще трогать site_content).
3. Лучше сделать расширение таблицы site_content, как это сделано, например в minishop2. А тк вы используете minishop2, то почему вы не используете ОПЦИИ??? они как раз для подобных целей — идеальны.
4. mSync — не знаю точно как работает, но знайте одно, если у вас кол-во товаров начинает превышать 10...20 тыс, то Вам скорее всего необходимо писать свой вариант mSync притом скорее всего на прямых запросах через modx--qwery. Это сложнее, но вы сможете быстро делать то что вам нужно.
4.1. Если товаров планируется более 20… 30 тыс, то имейте в виду, что добавление товара с ростом их общего кол-ва приводит к постепенному снижению производительности операций на чтение и запись этих товаров, особенно это чувствуется после сброса кеша и особенно при импорте-экспорте стандартными средствами. И тут или смотреть в сторону других Систем или Учить mysql + php или обратиться к профильным разработчикам, которые учтут нагрузки и прочие нюансы.
1. После обновления системы у Ваши вмешательства с БД скорее всего полетят.
2. Если вы хотите в site_content использовать свои, в ручную добавленные поля, то погуглите — есть решения через плагины (только так не надо делать, да и вообще трогать site_content).
3. Лучше сделать расширение таблицы site_content, как это сделано, например в minishop2. А тк вы используете minishop2, то почему вы не используете ОПЦИИ??? они как раз для подобных целей — идеальны.
4. mSync — не знаю точно как работает, но знайте одно, если у вас кол-во товаров начинает превышать 10...20 тыс, то Вам скорее всего необходимо писать свой вариант mSync притом скорее всего на прямых запросах через modx--qwery. Это сложнее, но вы сможете быстро делать то что вам нужно.
4.1. Если товаров планируется более 20… 30 тыс, то имейте в виду, что добавление товара с ростом их общего кол-ва приводит к постепенному снижению производительности операций на чтение и запись этих товаров, особенно это чувствуется после сброса кеша и особенно при импорте-экспорте стандартными средствами. И тут или смотреть в сторону других Систем или Учить mysql + php или обратиться к профильным разработчикам, которые учтут нагрузки и прочие нюансы.
Большое спасибо за советы!!!
Систему обновлял, те изменения не потёрлись, но я понял что так не нужно делать, спасибо. В целом для моей задачи хватило стандартного поля weight куда я записываю количество, его я не менял.
Написать на форум решил так как именно после этих манипуляций потребление ресурсов резко выросло, но похоже простого решения уже нет, значить будем думать как оптимизировать синхронизацию.
А на счёт своего варианта mSync идея хорошая. 1с выдаёт 2 файла import.xml и ofers.xml и в два этапа синхронизирует, сначала товары, потом предложения, наверняка можно сначала обработать их, вытащить только нужную информацию и в один этап провести синхронизацию.
Систему обновлял, те изменения не потёрлись, но я понял что так не нужно делать, спасибо. В целом для моей задачи хватило стандартного поля weight куда я записываю количество, его я не менял.
Написать на форум решил так как именно после этих манипуляций потребление ресурсов резко выросло, но похоже простого решения уже нет, значить будем думать как оптимизировать синхронизацию.
А на счёт своего варианта mSync идея хорошая. 1с выдаёт 2 файла import.xml и ofers.xml и в два этапа синхронизирует, сначала товары, потом предложения, наверняка можно сначала обработать их, вытащить только нужную информацию и в один этап провести синхронизацию.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.