[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Индексация таблиц или представление
zvezda_t
Здравствуйте, уважаемые программисты smile.gif

Подскажите пожалуйста, как быть в такой ситуации:

У меня в БД есть таблицы где 20 000 записей, причем ежедневно добавляются новые записи и также осуществляется выборка данных в виде отчетов.

1) Можно ли создавать индексы в ежедневно обновляемые таблицы или лучше воспользоваться индексированным представлением?
2) Нужно ли делать первичным ключом автоинкремент?
Понимаю что трудно ответить не видя БД, подскажите пожалуйста где можно почитать просто и доступно об индексации?

Заранее большое спасибо.



 ! 

М
В нарушение всех норм, канонов и правил, от имени всего мужского населения форума, поздравляю нашу Звезду с первым днём весны.
Bezdna




Спустя 9 минут, 53 секунды (24.02.2011 - 15:46) Evilsoul написал(а):
Цитата
1) Можно ли создавать индексы в ежедневно обновляемые таблицы или лучше воспользоваться индексированным представлением?
2) Нужно ли делать первичным ключом автоинкремент?

2 - не обязательно, но как по мне лучше делать.
1 - не уверен что правильно понял, можно добавить столбик допустим с датами их добавления, обновления.

ЗЫ часики на левой ручке нужно носить smile.gif ну если ты только не левша smile.gif

Спустя 3 часа, 35 минут, 30 секунд (24.02.2011 - 19:22) sergeiss написал(а):
Цитата (zvezda_t @ 24.02.2011 - 16:36)
Можно ли создавать индексы в ежедневно обновляемые таблицы....

Я тоже не понял этот вопрос smile.gif При чем тут, когда таблица обновляется? Индексы нужны для более быстрой выборки данных. Нужны они - создавай. Вне зависимости, насколько часто данные обновляются.

Спустя 12 часов, 12 минут, 34 секунды (25.02.2011 - 07:34) zvezda_t написал(а):
Цитата
Я тоже не понял этот вопрос smile.gif При чем тут, когда таблица обновляется?

sergeiss, но ведь везде пишут, что:
Цитата
Индексы повышают производительность операций
выборки, но ухудшают производительность при вы-
полнении таких операций, как добавление данных,
их модификация и удаление
. Вызвано это тем, что
при выполнении подобных операций СУБД должна
еще и динамически обновлять индекс.

А у меня в таблицу в равной степени, и добавляются записи и осуществляется выборка.
Провела анализ запросов с помощью "Помощника по настройке ядра СУБД"
(используя SQL Server Profiler, создала XML-файл трассировки (test.xml), в которую вошли команды Select, Insert и Update. А потом с помощью "Помощника по настройке ядра СУБД" провела анализ, указав в качестве файла рабочей нагрузки test.xml. (кстати это не может изменить мою БД? Команды Insert и Update, при анализе не будут же реально выполняться? )
В итоге рекомендаций по созданию индексов не было.
А вот когда анализировала только команды Select, мне вышел в отчете список некластерных индексов, которые желательно создать.


Evilsoul
Я всю жизнь ношу на правой smile.gif и я не левша) Как то попробовала на левой и в тот же день разбила... (кстати Путин тоже на правой носит biggrin.gif )


Спустя 2 часа, 3 минуты, 59 секунд (25.02.2011 - 09:38) zvezda_t написал(а):
И еще позвольте вопрос. smile.gif
В свойствах индекса, смотрю раздел - Фрагментация.
Заполненность страниц(средний процент полных страниц): 88.11%
Общая фрагментация(процент логической фрагментации, для индекса Heap =0%): 66.67%

Эти параметры плохие? (мне на курсах говорили что процент фрагментации дб<30% так ли это? )

Спустя 3 дня, 4 часа, 6 минут, 13 секунд (28.02.2011 - 13:45) silius написал(а):
Цитата

Индексы повышают производительность операций
выборки, но ухудшают производительность при вы-
полнении таких операций, как добавление данных,
их модификация и удаление. Вызвано это тем, что
при выполнении подобных операций СУБД должна
еще и динамически обновлять индекс.


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

Спустя 13 минут, 26 секунд (28.02.2011 - 13:58) sergeiss написал(а):
Цитата (silius @ 28.02.2011 - 14:45)
перед запросом, когда нужно было вытаскивать данные я создавал индексы, а после запроса снова удалял их, но в таблицах было примерно 500К строк

Что за изврат такой??? Для 500К строк создание индекса будет не таким уж и быстрым. Надо вставку оптимизировать, а не индексы пересоздавать постоянно.

Забудь про эту идею и больше никому её не советуй!!!

Спустя 1 час, 44 минуты, 18 секунд (28.02.2011 - 15:42) zvezda_t написал(а):
Уважаемые программисты, если вы знаете ответы на вопросы выше написанные - расскажите пожалуйста smile.gif

Я вот продолжаю войну с индексами.
В таблице users, создала "уникальный, некластеризованный" индекс по двум полям: серия и номер паспорта.
При попытке записи нового пользователя, выходит предупреждение:

Цитата
Warning: mssql_query() [function.mssql-query]: message: Cannot insert duplicate key row in object 'dbo.users' with unique index 'IX_ser_num'. (severity 14)


Я проверила - совпадений пользователей по паспортным данным в БД нет. Почему же индекс ругается?

Спустя 1 час, 15 минут, 54 секунды (28.02.2011 - 16:58) sergeiss написал(а):
Покажи, как именно индексы созданы... У меня есть подозрение, судя по ошибке, что у тебя созданы 2 уникальных индекса, а не один. Или поле с серией объявлено уникальным.

Спустя 14 часов, 28 минут, 1 секунда (1.03.2011 - 07:26) zvezda_t написал(а):
sergeiss, это моя ошибка. unsure.gif
В процедуре у меня создавалась еще одна запись в эту же таблицу без паспортных данных. Отсюда - первая запись проходила, вторая ругалась.
Извините. rolleyes.gif

Спустя 1 час, 19 минут, 35 секунд (1.03.2011 - 08:46) zvezda_t написал(а):
Цитата (zvezda_t @ 25.02.2011 - 06:38)
И еще позвольте вопрос. smile.gif
В свойствах индекса, смотрю раздел - Фрагментация.
Заполненность страниц(средний процент полных страниц): 88.11%
Общая фрагментация(процент логической фрагментации, для индекса Heap =0%): 66.67%

Эти параметры плохие? (мне на курсах говорили что процент фрагментации дб<30% так ли это? )

Какой процент фрагментации дб?

Спустя 3 часа, 20 минут, 43 секунды (1.03.2011 - 12:07) zvezda_t написал(а):
Еще вопрос появился smile.gif

Уважаемые программисты, как по вашему что правильнее:
в таблице Users
id
series
number
lastname
name
...


1) Сделать первичным ключом автоинкремент(id) и
написать индекс по полям series,number (паспорт)
2) Написать составной первичный ключ по полям: series,number
?

(у меня Microsoft SQL Server 2005)

Спустя 23 минуты, 50 секунд (1.03.2011 - 12:30) Snus написал(а):
zvezda_t
Естественно составной. Серии и номера могут повторяться, а вот в связке серия + номер - уникальные записи получают, что исключает дубликаты smile.gif

Спустя 13 минут, 5 секунд (1.03.2011 - 12:43) linker написал(а):
Если есть выборка, значит нужны индексы. Выборка всегда будет работать медленнее, чем вставка/удаление/изменени. Тем более при изменении/удалении также используются те самые индексы, что и при обычной выборке.

Поэтому индексы нужны в любом случае.

Спустя 2 минуты, 31 секунда (1.03.2011 - 12:46) Snus написал(а):
zvezda_t
Цитата
2) Написать составной первичный ключ по полям: series,number

Только не первичный, а уникальный.

Спустя 10 минут, 1 секунда (1.03.2011 - 12:56) zvezda_t написал(а):
Цитата (Snus @ 1.03.2011 - 09:46)
zvezda_t
Цитата
2) Написать составной первичный ключ по полям: series,number

Только не первичный, а уникальный.

а почему не первичный составной? rolleyes.gif

Спустя 22 минуты, 28 секунд (1.03.2011 - 13:18) Snus написал(а):
zvezda_t
Первичный ключ по сути используется для быстрого обращения к строке по ID

Спустя 18 часов, 46 минут, 18 секунд (2.03.2011 - 08:05) zvezda_t написал(а):
А если у меня совсем нет выборки по id, а всегда поиск по полям series+number. В этом случае нужен первичный ключ по id? сортировка по id увеличит быстродействие в любом случае? или будет лучше сделать только уникальный индекс для series+number? rolleyes.gif

Спустя 1 час, 22 минуты, 57 секунд (2.03.2011 - 09:28) Snus написал(а):
zvezda_t
`id` PRIMERY KEY + автоинкремент обязательны.
Ты можешь делать выборку по чему угодно. К примеру ты выводишь
SELECT `id`, `series`, `number` FROM `users` WHERE `series` = '1234' AND `number` = '1234567' 

А если тебе нужно отредактировать запись, то ты передаешь полученный id строки. И дальнейшие махинации производишь через
 ... WHERE `id` = 'XXX'

Делать так можно, но неправильно
UPDATE `users` SET `series` = '4321' WHERE `series` = '1234' AND `number` = '1234567'

Спустя 3 минуты, 30 секунд (2.03.2011 - 09:31) linker написал(а):
Индексы устанавливаются на те поля, по которым происходит поиск/изменение/удаление.

Спустя 24 минуты, 21 секунда (2.03.2011 - 09:56) zvezda_t написал(а):
Цитата
Делать так можно, но неправильно


Snus, ничего себе! а я именно так и делаю :(

/*у меня series и number -не изменяемые поля и поэтому делаю так:*/
UPDATE `users` SET `name` = 'Иван' WHERE `series` = '1234' AND `number` = '1234567'


почему не правильно?
если я буду перед изменением айдишник изменяемой записи вытаскивать, это же лишний запрос, а значит работать медленнее будет. :ph34r:

Спустя 52 минуты, 32 секунды (2.03.2011 - 10:48) Snus написал(а):
zvezda_t
Если ты работаешь на чистом SQL (без скриптов с выборкой), то используй дальше свой метод, а если ты выводишь скриптом на экран записи с Иванами, то при выборке получай id и работай уже непосредственно с ним.

Спустя 3 часа, 54 минуты, 32 секунды (2.03.2011 - 14:43) zvezda_t написал(а):
Уважаемые программисты, помогите мне пожалуйста разобраться с таким вопросом:

у меня Microsoft SQL Server 2005
В таблице dbo.kladr (кладр) для поля code создала уникальный, некластеризованный индекс.

измеряю время выполнения запросов:
1)
SELECT * FROM dbo.kladr WHERE (CODE LIKE '__00000000000') ORDER BY name

t=0,2626

2)
SELECT * FROM dbo.kladr WHERE right(CODE, 11) = '00000000000' ORDER BY name

t=0,1286

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

есть ответ:
Цитата
Индексы лучше всего подходят для поиска слева направо, а не наоборот


Цитата
Можно попробовать сократить перебор серверу, указав допустимые значения этих символов, например если там только цифры - то использовать шаблон '[0-9][0-9]00000000000'.

не помогло. еще медленнее стал запрос

Цитата
Если у вас в основном идет поиск с неизвестными первыми символами - можно попробовать сделать такой финт:
1. Создаете в таблице вычислимое поле RevCODE = REVERSE(CODE) PERSISTED.
2. Создаете по нему индекс.
3. Переписываете условие как RevCODE = '00000000000__'.


_____________

Что ты сделал сегодня - для завтра?
"Приидите ко Мне вси труждающиеся и обремененнии и Аз упокою вы, возмите иго Мое на себе и научитеся от Мене яко кроток есмь и смирен сердцем и обрящете покой душам вашим, иго бо Мое благо и бремя Мое легко есть."(Мф. 11:28-30)
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.