Проблема с индексами sql

Использовал поле longtitle для количества товара при синхронизации через mSync. Чтобы поле сделать числовым и сортируемым залез в phpMyAdmin и поменял varchar на decimal(12,2) убрав его в отдельный индекс BTREE. Но после этого синхронизация стала есть кучу ресурсов сервера. Сейчас нужно заново синхронизировать 17000 позиций, хостинг ругается на огромное превышение Нагрузки MySQL




Совсем не знаком с БД, не могу понять что можно с этим сделать. Предполагаю что сломал индекс content_ft_idx ведь до этих манипуляций там был один уникальный элемент, а теперь все 12124 ресурса.
vrm13
06 марта 2020, 09:07
modx.pro
580
0
Поблагодарить автора Отправить деньги

Комментарии: 8

Артур Шевченко
12 марта 2020, 01:07
0
Я думаю вам поможет только бэкап базы если он есть. Ну и mSync передаёт остатки из любого поля которое вы ему укажите, в базе ковыряться не нужно.
    vrm13
    12 марта 2020, 08:15
    0
    спасибо. с бекапом не получится уже к сожалению. Поменял поле количества на Weight, отключил все возможные плагины (например moddevtools тоже срабатывал на каждый обновляемый товар при синхронизации) но всё равно жутко ресурсоёмкий процесс получается
    Сергей Шлоков
    12 марта 2020, 09:37
    0
    Просто нет слов. Достойно рубрики «Курьёзы и юмор». А заказчика жалко.
      vrm13
      12 марта 2020, 10:19
      0
      нет заказчика) самостоятельные эксперрименты. Пара слов были бы всё-таки полезны… я бы и сам с удовольствием посмеялся потом
        Артур Шевченко
        13 марта 2020, 09:15
        0
        Тогда мы вам очень сочувствуем, но придётся всё сносить.
          vrm13
          13 марта 2020, 10:14
          0
          конструктивно. Форум для сочувствия оказывается, а я думал для работы над ошибками. В чём суть «Курьёза и юмора» то? и как в следующий раз не загубить базу? да, совсем нет знаний, но беда в том, что нет на столько, что нет идей что искать в гугле, поэтому и приходится беспокоить глупыми вопросами людей на форуме.

          В базе я сделал три действия: из общего индекса FULLTEXT убрал поле Longtitle, поставил ему тип BTREE и поменял varchar на decimal(12,2) больше никаких действий с базой. Вокруг этого читаю форумы, но не нахожу в чём собственно юмор.
            Алексей Смирнов
            13 марта 2020, 22:55
            +1
            Ну тут нужно следующее учесть:
            1. После обновления системы у Ваши вмешательства с БД скорее всего полетят.
            2. Если вы хотите в site_content использовать свои, в ручную добавленные поля, то погуглите — есть решения через плагины (только так не надо делать, да и вообще трогать site_content).
            3. Лучше сделать расширение таблицы site_content, как это сделано, например в minishop2. А тк вы используете minishop2, то почему вы не используете ОПЦИИ??? они как раз для подобных целей — идеальны.
            4. mSync — не знаю точно как работает, но знайте одно, если у вас кол-во товаров начинает превышать 10...20 тыс, то Вам скорее всего необходимо писать свой вариант mSync притом скорее всего на прямых запросах через modx--qwery. Это сложнее, но вы сможете быстро делать то что вам нужно.
            4.1. Если товаров планируется более 20… 30 тыс, то имейте в виду, что добавление товара с ростом их общего кол-ва приводит к постепенному снижению производительности операций на чтение и запись этих товаров, особенно это чувствуется после сброса кеша и особенно при импорте-экспорте стандартными средствами. И тут или смотреть в сторону других Систем или Учить mysql + php или обратиться к профильным разработчикам, которые учтут нагрузки и прочие нюансы.
              vrm13
              14 марта 2020, 08:47
              0
              Большое спасибо за советы!!!

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

              А на счёт своего варианта mSync идея хорошая. 1с выдаёт 2 файла import.xml и ofers.xml и в два этапа синхронизирует, сначала товары, потом предложения, наверняка можно сначала обработать их, вытащить только нужную информацию и в один этап провести синхронизацию.
      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
      8