(My) производительность SQL: обновление одного поля по сравнению со многими ненужными полями - PullRequest
10 голосов
/ 23 июня 2011

Я обрабатываю форму, которая имеет много полей для пользователя, который редактирует существующую запись.пользователь, возможно, изменил только одно поле, и я обычно делал бы запрос на обновление, который устанавливает значения всех полей, хотя большинство из них не меняются.я мог бы сделать какое-то отслеживание, чтобы увидеть, какие поля действительно изменились, и обновить только те, которые изменились.Есть ли разница в производительности между обновлением всех полей в записи по сравнению только с тем, что изменилось?Есть ли другие причины, чтобы пойти с любым методом?метод дробовика довольно прост ...

Ответы [ 6 ]

7 голосов
/ 23 июня 2011

Я бы сказал, что это зависит от следующего:

  • Размер обрабатываемых данных
  • Расположение сервера базы данных относительно приложения
  • Время, необходимое для выполнения любых проверок на изменение данных

Если вы передаете большие объемы данных и / или соединение является удаленным, вам следует выполнить несколько тестов, чтобы выяснить, можно ли повысить производительностьотслеживая изменения.В противном случае вы, вероятно, обнаружите, что это незначительно, если предположить, что одной записью манипулируют.

4 голосов
/ 23 июня 2011

Я бы сказал, пойти на дробовик, но это действительно зависит от многих вещей и от того, как вы используете БД.

  • Один пользователь или миллионы одновременных пользователей?
  • поля маленькие или тоже есть большие поля для текста / блобов?
  • Является ли приложение, где форма заполняется рядом с БД или через сеть или Интернет?

Вам необходимоУчтите, что UPDATE должен будет не только сохранить новые (даже неизмененные) поля в таблице, но также:

  • проверить ограничения внешнего ключа
  • обновить всеиндексы в обновленных полях

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

2 голосов
/ 23 июня 2011

Вы можете фактически потерять производительность, обновляя только отдельные поля.Если вы используете подготовленные операторы, то база данных уже скомпилировала план запроса для обновления всех полей.Если вы начнете обновлять случайные поля, вам придется анализировать запрос каждый раз при обновлении, теряя преимущество подготовленных операторов.Я не уверен, насколько это повлияет на MySQL, но я знаю, что это может быть значительным для SQL Server и Oracle.

2 голосов
/ 23 июня 2011

Если вы говорите о разумном количестве данных (например, 1 КБ +), тогда может потребоваться оптимизация.Если этот оператор / таблица часто запускается / обновляется (несколько раз в секунду?), Несколькими пользователями и т. Д., Возможно, стоит оптимизировать.

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

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

1 голос
/ 23 июня 2011

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

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

0 голосов
/ 23 июня 2011

Я бы выбрал метод дробовика, и его легко понять и реализовать. Хит производительности должен быть незначительным.

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