|
|
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Вот, придумал пока обедал: Сделать табличку (LastDeletedID bigint) и в триггере на удаление заносить туда max(id) from deleted, а в выборке max(ID) использовать максимум из ident_current и LastDeletedID. Будет всегда правильное значение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 14:03:30 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
А если так: select max(ID) from table (NOLOCK) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 14:05:26 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Если смотреть на планы выполнения, то и Select Max(Id) from tabl1 и select top 1 ID from table order by id desc - либо table scan, при отсутствии индексов на id - либо (clustered) index scan при наличии индекса на id. Поэтому просто упираемся в скорость чтения таблицы(индекса). А так как таблица очень большая, то нужно вести речь о скорости чтения дисков. Другими словами - либо увеличиваем производительность дисков - либо решаем это решаем проблему через дополнительные таблицы. Можно рассмотреть и вариант VVG_, но если вы утверждаете что записи "удаляются редко... и в основном штучно", то вообще можно в триггере "запоминать" все удаленные ID. Рядом с 300 000 000 таблицей даже пара тысяч будет смотреться "жалко". ЗЫ 2akuz я не монстр - это точно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 14:37:56 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
я тоже не монстр... но мне приходилось отказываться от identity вообще.... поле генерировал на лету на клиенте.... от текущего maxid.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 16:13:59 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
А если вставить запись в транзакции получить ID и откатить? (: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:00:30 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
А почему бы не использовать кластерный индекс по id (desc) ? Или вставка будет очень долго занимать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 18:41:36 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
нужно использовать обычный сластерный индекс по полю id.... не desc конечно... ;)) так как поле ID identity - добовлятся будет всегда в конец... вот такой запрос должен работать быстро...( по кластерному индексу) select top 1 ID from table option(nolock) order by id desc или select max(ID) from table option(nolock) group by id если выполняется долго нужно смотреть статистику.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 19:08:14 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Мне кажется, что проблема в ТАКОЙ организации хранения данных. Наверняка в этой табле хранятся данные за все года или события различающиеся по одному признаку, которые ни чего не стоит развести и по таблям, и по файлам, и по дискам. Именно это даст ощутимый прирост скорости и позволит в дальнейшем правильно развивать хранилище. Многие автоматические навороты для мини хранилищ абсолютно противопоказаны монстрам. ЗЫ Убей свои иллюзии и перестань думать, что ты монстр. Фсе. МЯФ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 19:46:50 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Как всегда, я предпочитаю не решать проблемы, а снимать их. У меня жуткие сомнения, что этот поиск нафиг не нужен. Обрисуйте, для чего используется этот max. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2002, 22:34:11 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Два кота! Ну, ты вообще правду матку рубанул, прям в глаза. Ты аккуратнее с людьми они такие ранимые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 14:18:32 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
to Tracer MiCe если написано >есть поле ID(Pk, identity) то значит кластерный индекс скорее всего есть и его уже попробовали поиск по некластерному индексу будет быстрее в сило его физической организации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 14:42:38 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Сделал таблицу: CREATE TABLE [t] ( [f1] [int] IDENTITY (1, 1) NOT NULL , [f2] [int] NULL , CONSTRAINT [PK_t] PRIMARY KEY CLUSTERED ( [f1] ) ON [PRIMARY] ) ON [PRIMARY] Вставил 301545854 записей. select max(f1) from t --время выполнения =0. Что я делаю не так? Как получить 6 минут? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 18:31:06 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Да, размер данных - 5Гиг, индекс - 13мег ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 18:34:08 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
to VAT все дело в волшебных пузырьках... скорее всего таблица, по которой запрос идет 6 минут имеет не 2 поля, а с десяток и поэтому на одном блоке данных помещается всего несколько ROWs. Хотя 6 минут и 0 все равно непонятно...пусть покажут нам исходные данные :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 19:41:14 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Да хрень какая-то ... не может этого быть, чтобы так долго было. Ищите ошибку не к коде... Маразм какой-то ... PS При вычислении примера 2+2 запрос выполнятся 6 мин. Пожалуйста помогите написать правильно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2002, 20:58:28 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
Автор топика сбежал куда-то. Ну подумайте, народ, а зачем ищется этот самый max? Что-бы прибавить к нему единичку и получить уникальный ключ? Так есть GUID и identity. А где это участвует? Строки кластерного индекса нумеруются? А нафиг это надо? Это номер документа? Так нумерацию, во-первых, можно каждый год или даже месяц начинать с единицы. Во-вторых, если это все-же номер документа и нумерацию сбрасывать нельзя, то с уверенностью в 99.9% модно предположить, что там есть поле DateTime. и при ежедневной вставке в 30 000 000 (неужели правда?), максимальное значение будет в интервале getdate() - 1/24 (час). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 00:33:18 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
А стоит ли так долго говорить о таблице, которая при таких объемах вставки загнется через 70 дней от переполнения поля int? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 07:11:24 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
кто-то сказал неправильно про identcurrent() и все поверили. попробуй: create table t (id int identity primary key) insert into t default values insert into t default values insert into t default values select * from t delete t where id>1 SELECT IDENT_CURRENT('t') drop table t ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 08:04:37 |
|
||
|
Опытным монстрам SQL
|
|||
|---|---|---|---|
|
#18+
все проблемы упираются в скорость... если данные вливаются непрерывно.... через булк ... порциями... и с базой еще и работают... 2 Опытный монстр SQL а ты пробовал свой код именно в этой ситуации? и 2 All есть таблица.... пусть тяжелая.... есть ключ.... идент... рассмотрим 2 варианта... кластерный и не кластерный индекс... при кластерном - добавлятся будет всегда в конец набора данных..... потерь на добавление нет.... а вот на вставку и удаление - есть..... при обычном индексе - равномерная нагрузка на добавление и вставку.... но нагрузка только на этот идекс... дык вот при огромных размерах данных , с постоянным добавлением и редким удалением - кластерный индекс именно то что нужно..... а вот причина почему 6 мин. .... обычный индекс персчитывается после булк.... а кластерному пересчитываться при этом не нужно.... макс нужен чтобы сделать идентити инсерт в таблу... иначе сервер может захлебнуться.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 16:17:20 |
|
||
|
|
start [/forum/topic.php?fid=46&startmsg=32068358&tid=1818726]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
| others: | 223ms |
| total: | 370ms |
| 0 / 0 |
