Удалить, если не в запросе

У меня есть таблица поиска (##lookup). Я знаю, что это плохой дизайн, потому что я дублирую данные, но это значительно ускоряет мои запросы. У меня есть запрос, который заполнит эту таблицуУдалить, если не в запросе

insert into ##lookup select distinct col1,col2,... from table1...join...etc...

Я хотел бы, чтобы смоделировать такое поведение:

delete from ##lookup 
insert into ##lookup select distinct col1,col2,... from table1...join...etc...

Это ясно обновить таблицу правильно. Но это много вставки и удаления. Это бесполезно с моими индексами и блокирует таблицу для выбора.

Эта таблица также может быть обновлено что-то вроде:

delete from ##lookup where not in (select distinct col1,col2,... from table1...join...etc...) 
insert into ##lookup (select distinct col1,col2,... from table1...join...etc...) except if it is already in the table

Второй путь может занять больше времени, но я могу сказать, «без блокировки» и я буду иметь возможность выбрать из таблицы.

Любые идеи о том, как написать запрос во втором случае?

источник

2010-06-15 kralco626

DELETE LU 
FROM ##lookup LU 
LEFT OUTER JOIN Table1 T1 ON T1.my_pk = LU.my_pk 
WHERE T1.my_pk IS NULL 

INSERT INTO ##lookup (my_pk, col1, col2...) 
SELECT T1.my_pk, T1.col1, T1.col2... 
FROM Table1 T1 
LEFT OUTER JOIN ##lookup LU ON LU.my_pk = T1.my_pk 
WHERE LU.my_pk IS NULL

Вы также можете использовать WHERE NOT EXISTS вместо ЛЕВЫЙ JOIN и выше искать небытия строк.

Возможно, вы также захотите изучить инструкцию MERGE, если вы используете SQL 2008. В противном случае вы не синхронизируете таблицы - вы сохраняете синхронизацию PK. Если один из столбцов изменяется в одной таблице, а не другой, который не будет отражен выше.

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

источник

2010-06-15 17:46:42

ya наилучшим образом, идеальным решением было бы использовать «метриализованный вид» или индексированный вид, поскольку он вызывается на SQL-сервере. Однако, чтобы индексировать представление, вы не должны использовать «self joins», в этом случае self-join даже включает в себя использование тех же таблиц дважды в соединении, даже если это не является технически самосоединением. Поэтому нельзя использовать эту опцию, которая была бы оптимальной. Поверьте мне, мне и нескольким людям намного умнее, чем я провел много часов, чтобы придумать лучший солетон. Индексирование исходных таблиц до смерти только дошло до нас, и запросы не могут быть оптимизированы ... – kralco626

но, я полностью согласен с вами. Это жуткое решение ...если только Microsoft разрешит мне использовать представление ... Для моей проблемы есть работа arround, но для меня это слишком сложно понять. Я задал вопросы об этом здесь: http://stackoverflow.com/questions/3046058/need-some-serious-help-with-self-join-issue Если эта проблема будет решена, я не буду этого делать. – kralco626

Все данные DELETE регистрируются, что убивает производительность, если вы планируете уничтожить всю таблицу. В зависимости от количества строк, с которыми вы имеете дело, вы можете просто использовать незаписанный TRUNCATE.

Как долго вы принимаете инструкцию SELECT? Вы можете попробовать что-то вроде этого, если выбор занимает мало времени, и вы часто не выполняете его.

выберите отчетливый ... INTO # tempTable1 из table1 ... присоединиться ... и т.д. ...

начать транзакцию удаление таблицы ## поиска выберите * в ## поиска из # tempTable1 совершить транзакцию

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

источник

2010-06-19 23:48:14 mattmc3

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

Удалить, если не в запросе

ответ

Смежные вопросы