Проблема с индексами sql
Использовал поле longtitle для количества товара при синхронизации через mSync. Чтобы поле сделать числовым и сортируемым залез в phpMyAdmin и поменял varchar на decimal(12,2) убрав его в отдельный индекс BTREE. Но после этого синхронизация стала есть кучу ресурсов сервера. Сейчас нужно заново синхронизировать 17000 позиций, хостинг ругается на огромное превышение Нагрузки MySQL
Совсем не знаком с БД, не могу понять что можно с этим сделать. Предполагаю что сломал индекс content_ft_idx ведь до этих манипуляций там был один уникальный элемент, а теперь все 12124 ресурса.
Совсем не знаком с БД, не могу понять что можно с этим сделать. Предполагаю что сломал индекс content_ft_idx ведь до этих манипуляций там был один уникальный элемент, а теперь все 12124 ресурса.
Комментарии: 8
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
В базе я сделал три действия: из общего индекса 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 или обратиться к профильным разработчикам, которые учтут нагрузки и прочие нюансы.
Систему обновлял, те изменения не потёрлись, но я понял что так не нужно делать, спасибо. В целом для моей задачи хватило стандартного поля weight куда я записываю количество, его я не менял.
Написать на форум решил так как именно после этих манипуляций потребление ресурсов резко выросло, но похоже простого решения уже нет, значить будем думать как оптимизировать синхронизацию.
А на счёт своего варианта mSync идея хорошая. 1с выдаёт 2 файла import.xml и ofers.xml и в два этапа синхронизирует, сначала товары, потом предложения, наверняка можно сначала обработать их, вытащить только нужную информацию и в один этап провести синхронизацию.