none
INSERT и падение производительности - проблема RRS feed

  • Вопрос

  • Привет всем :)

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

    Потому вопрос в следующем...

    Как в 2005ом сиквеле оптимизируют запрос на INSERT,UPDATE,DELETE? Ведь если я не ошибаюсь эта тройка терроризирует физ HDD?

     

    Заранее благодарен за полезные комментарии

     

    • Перемещено SachinW 2 октября 2010 г. 0:14 MSDN Forums Consolidation (От:SQL Server для разработчиков)
    4 сентября 2010 г. 21:06

Ответы

  • Временные таблицы никто не отменял ни в 2005, ни в 2008ом, а по оптимизации нет однозначного ответа или совета по оператору, какждый запрос оптимизируется индивидуально с учетом всех особенностей вашей системы
    http://www.t-sql.ru
    • Помечено в качестве ответа I.Vorontsov 7 сентября 2010 г. 4:59
    5 сентября 2010 г. 5:26
    Модератор

Все ответы

  • Table variables?

    Вопрос насчет оптимизации команд INSERT/UPDATE/DELETE непонятен.


    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    5 сентября 2010 г. 3:59
  • Временные таблицы никто не отменял ни в 2005, ни в 2008ом, а по оптимизации нет однозначного ответа или совета по оператору, какждый запрос оптимизируется индивидуально с учетом всех особенностей вашей системы
    http://www.t-sql.ru
    • Помечено в качестве ответа I.Vorontsov 7 сентября 2010 г. 4:59
    5 сентября 2010 г. 5:26
    Модератор
  • Временные таблицы никто не отменял ни в 2005, ни в 2008ом, а по оптимизации нет однозначного ответа или совета по оператору, какждый запрос оптимизируется индивидуально с учетом всех особенностей вашей системы
    http://www.t-sql.ru


    Ух - успокоили :)

    А насчет оптимизации, то нужно ли обязательно подкреплять временную таблицу под INSERT? Потому как читал по каждой такой транзакции обращение идет к винту, а это уже не гуд или можно обойтись физ таблицами ? :)

    7 сентября 2010 г. 19:37
  • Vopros sformulirovan stranno. Pri INSERT zapisi fisicheski zapysyvajutsja v fail na diske, tak chto v chem zdes' vopros? Pri lubom INSERT budut I/O operacii. See also http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/6912605b-db1d-41c1-9198-b073b511adb5

    Drugoj vopros, chto mozhno dat' odnu kommandu INSERT vypolnjajushuju multiple inserts, a mozhno zapisat' otdel'no insert dlja kazdogo znachenija, e.g.

    insert into Table (Field1, Field2) values (@Val1, @Val2)

    insert into Table (Field1, Field2) values (@Val10, @Val20)

    ili

    insert into Table (Field1, Field2) Select @Val1, @Val2

    union all

    insert into Table (Field1, Field2) select @Val10, @Val20

     

    Vo vtorom sluchae budet odna tranzaksija, poetmo kod vypolnitsja bystree.

    Optimal'nyj razmer batch (skol'ko insert vypolnjat' srazu) podbiraetsja v zavisimosti ot mnogix faktorov.


    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    7 сентября 2010 г. 20:25
  • Временные таблицы никто не отменял ни в 2005, ни в 2008ом, а по оптимизации нет однозначного ответа или совета по оператору, какждый запрос оптимизируется индивидуально с учетом всех особенностей вашей системы
    http://www.t-sql.ru


    Ух - успокоили :)

    А насчет оптимизации, то нужно ли обязательно подкреплять временную таблицу под INSERT? Потому как читал по каждой такой транзакции обращение идет к винту, а это уже не гуд или можно обойтись физ таблицами ? :)


    как уже заметила Naom, в любом случае обращение к диску не избежать, возможно вы что-то напутали изначально, ибо утверждение:

     "Как-то возник вопрос касательно INSERT... При данной транзакции падает производительность, но где-то читал, что нужно оптимизировать при помощи временных таблиц."

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

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


    http://www.t-sql.ru
    8 сентября 2010 г. 13:26
    Модератор
  • Нет, не напутал :) Понятно, что тарабанить винт все равно предется, но как свести обращение к диску максимально реже? Меня напутали в начале с рассказами об отмене временных таблиц в 2005ом сиквеле - это да :) А так в принципе понятно... Подкрепить временную таблицу и по мере определенной её заполненности уже будет идти выходящий на запись в файл. Или я уже и здесь напутал :) ?
    8 сентября 2010 г. 18:15
  • Kakuju zadachu Vy reshaete i kakimi sredstvami? Opredelites' s zadachej, a potom mozhno budet razgovarivat' predmetno.

    Naprimer, kak ja pokazala, mozhno s pomosh'ju odnj komandy vypolnit' INSERT srazu mnogix zapisej, a mozhno delat' INSERT po odnoj zapisi. Eto, estestvenno, daet raznicu.


    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    8 сентября 2010 г. 18:36