Оптимизация с выбранымми

[Grafline]

Не первый раз замечаю странность возможно ошибка или так задумано но думаю можно как то решить.
Пример структуры: есть таблица 1 в ней 500 разделов, в нее в вложена таблица 2 в ней 10 тысяч записей.
В таблице 2 30 - 40 полей из которых половина это запросы запросы в другие таблицы и формулы с результатами. вычислений.

Теперь о проблеме выбираю например фильтрами 2000 записей, делаю с выбранными обновить простое логическое поле значение с да на нет.... И вот этот процесс занимает в среднем 20 минут...

Что пробовал, и от куда проблема:
1. Пробовал переделать запросы на динамические
- С плюсов да отрабатывает обновление быстрее но есть минусы
- с минусов, приходиться мудрить чтоб использовать в формулах, и что хуже время открытия страницы сразу увеличиваться в много раз - НЕ подходит.
2. Писать формулы с прямыми запросами к БД не через редактор - да частично ускоряет работу в особенности ели сразу сохранять результат Аяксом но все равно долго.
3. Делать через автоматизацию изменении только 1 поля ( Ранее помогало, до перехода на пхп 7 - 8 на сколько помню)

Методом проб выяснил что сейчас при изменении 1 любого поля в таблице 2 происходит полное пере сохранение ( как следствие перерасчет всех полей)

Предлагаю добавить в обновление или в автоматизацию возможность выбора ( галочки или любого другого) Обновлять все поля или только те что указаны

Сделать на 1 кнопку больше автоматизацией или своим запросом или любым удобным способом думаю не проблема. При этом ели надо обновить все нажать обновить все а если только 1 поле то его. Логично при любом обновлении всегда менять дату обновления но остальные поля зачем каждый раз дергать?

Возможно есть уже какое то решение или нужно что то отключить в коде. Заранее спасибо за любой совет или идею.

Текущая проблема сильно замедляет рутинные процессы пользователей. Пробовал на пхп 7.13 - 8.0 Результат не меняется. При этом типовой запрос ( заменить одно значение на другое и дату обновления на текущую даже через ПХП май админ у 50 000 строк занимает секунды)

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

[nruslan2]

как вариант в 3.2.1 версии есть логи, которые показывают время затраченное на выполнение, среди них можно как раз увидеть то что дольше всего выполняется и уже смотреть в этом направлении.(проверять можно и на малой выборке!)

Например вложенный select работает в разы дольше чем конструкция inner join. только переписав этот момент у себя я в разы увеличил скорость отклика системы. (те изначально запрос в поле php был написан через селект)

[Grafline]

У меня сейчас на одной версии 3.0 и на двух 3.1 Просто каждое обновление требует поправки той части кода что менял. Планировал на 3.3 Очень нужны фильтры, есть своя конструкция но то скорей костыль чем стабильное решение. Думаете обновление на 3.2 хоть немного решит проблему?

Ну и можно подробнее как меняли селект сюда или в личку как удобнее. Может пример есть какой оттестированный.

Ряд полей действительно можно оптимизировать но это дает не большой результат даже на сильном железе. Поэтому я и предложил вести возможность именно обновлять указное поле, а не все, я знаю какие у меня тормозят... Пробовал методом исключения на копии.

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

[nruslan2]

обновление ничего не изменит в плане нагрузке, но в 3.2.1 есть инструмент который отследит что тормозит

был запрос примерно был select a from b where a=(select v from m where n=1), а сделал select a from b inner join m on a=m where n=1

[support]

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

Тут я могу порекомендовать только сервер по мощнее.

[Grafline]

Вопрос не в мощностях не не на одном из серверов не использует при запросе и четверти процессора, оперативки также с большим запасом. Проверял в разных комбинациях.
Для чего так сделано я понимаю. Да чтобы пользователь обычным обновлением не вызвал ошибку.
По этому и предложил вынести в автоматизацию возможность включить. То есть если я назначаю на быстрое изменение полей то я понимаю что эти поля не завязаны в других местах.
Справочник таблицы 2 собирает данные из других таблиц. Да если мы обновляем то есть для этого кнопка нажал обновляет пошел пить чай. Но изменение 1 или нескольких полей ( пример количество и наличие) В первом число в втором логическое поле. Они не идут в другие таблицы и им ненужные все указанные выше проверки в моем случае.

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

[Grafline]

обновление ничего не изменит в плане нагрузке, но в 3.2.1 есть инструмент который отследит что тормозит

был запрос примерно был select a from b where a=(select v from m where n=1), а сделал select a from b inner join m on a=m where n=1

Спасибо за наводку буду пробовать.
Я так понимаю это также приходиться восстанавливать после обновления версий? Изменения вносили в основной код или писали отдельный Палагин?

[nruslan2]

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

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

советую на 3.2.1 просто проверить логи) ( не обязательно обновлять боевую машину разверните на тестовой!)

[Grafline]

Вот тут можно по подробнее, если я верно понимаю тип поля MySQL Запрос и MySQL Формула используют селект. Как вы обошли это не меняя код? Может я просто не туда копаю. У меня большая часть зависимых полей через них построены + логично сущности и числовые поля. ( Некоторые с 2.6 и 2.8 еще запросы но они работают верно что на пхп 5.6 что на 7 и выше) Думал в их сторону тоже.

Есть альтернатива? Я пробовал с запросами в MySQL Запрос разными но по моему там в любом случае общие правила в коде прописаны...

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

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

[nruslan2]

ну так в sql формуле и пишется формула, просто получается в моем случаи я писал формулу которая работала, но не так эфективно!
приведите пару ваших формул из поля sql формула