![]() |
Индексы, Состовные первичные ключи, Индексация представлений
Здравствуйте, уважаемые программисты :)
Подскажите пожалуйста, как быть в такой ситуации: У меня в БД есть таблицы где 20 000 записей, причем ежедневно добавляются новые записи и также осуществляется выборка данных в виде отчетов. 1) Можно ли создавать индексы в ежедневно обновляемые таблицы или лучше воспользоваться индексированным представлением? 2) Нужно ли делать первичным ключом автоинкремент? Понимаю что трудно ответить не видя БД, подскажите пожалуйста где можно почитать просто и доступно об индексации? Заранее большое спасибо. |
Цитата:
Цитата:
Почитать можно на oszone.net - Статьи по MS SQL (http://oszone.net/4482/Microsoft_SQL_Server) |
Вот ведь везде пишут, что:
Цитата:
Провела анализ запросов с помощью "Помощника по настройке ядра СУБД" (используя SQL Server Profiler, создала XML-файл трассировки (test.xml), в которую вошли команды Select, Insert и Update. А потом с помощью "Помощника по настройке ядра СУБД" провела анализ, указав в качестве файла рабочей нагрузки test.xml. (кстати это не может изменить мою БД? Команды Insert и Update, при анализе не будут же реально выполняться? ) В итоге рекомендаций по созданию индексов не было. А вот когда анализировала только команды Select, мне вышел в отчете список некластерных индексов, которые желательно создать. Как же быть? |
И еще позвольте вопрос.
В свойствах индекса, смотрю раздел - Фрагментация. Заполненность страниц(средний процент полных страниц): 88.11% Общая фрагментация(процент логической фрагментации, для индекса Heap =0%): 66.67% Эти параметры плохие? (мне на курсах говорили что процент фрагментации дб<30% так ли это? ) |
Цитата:
|
Согласен с Busla, 20 000 - это мизер для современного железа. Я думаю, что индексация, что представления в данном случае будут работать одинаково. Единственно, можно составить пропорцию соотношения Select и Update/Insert. Если больше выборок, выбираем одно, больше вставок/обновлений - другое.
В любом случае, прироста(да и падения) производительности не будет при таких объемах. |
Еще вопрос появился :)
Уважаемые программисты, как по вашему что правильнее: в таблице Users id series number lastname name ... 1) Сделать первичным ключом автоинкремент(id) и написать уникальный индекс по полям series,number (паспорт) 2) Написать составной первичный ключ по полям: series,number ? (у меня Microsoft SQL Server 2005) |
1. Делешь ID первичным ключем с автоинкрементом
2. Делаешь уникальный индекс по полям паспорта. Таким образом, ты сможешь по ID всегда найти нужную запись + избавишься от проверки внесения дублированных записей по паспорту. |
А если у меня совсем нет выборки по id, а всегда поиск по полям series+number. В этом случае нужен первичный ключ по id? сортировка по id увеличит быстродействие в любом случае? или будет лучше сделать только уникальный индекс для series+number?
|
Уважаемые программисты, разрешите пожалуйста еще вопрос:
итак у меня Microsoft SQL Server 2005. В таблице dbo.kladr (кладр) для поля code создала уникальный, некластеризованный индекс. измеряю время выполнения запросов: 1) [sql]SELECT * FROM dbo.kladr WHERE (CODE LIKE '__00000000000') ORDER BY name[/sql] t=0,2626 2) [sql]SELECT * FROM dbo.kladr WHERE right(CODE, 11) = '00000000000' ORDER BY name[/sql] t=0,1286 Почему второй запрос быстрее? ведь когда CODE вычисляемое значение, индекс не работает, а значит и запрос дб медленнее, разве нет? |
Оператор LIKE при поиске ищет все подряд, не обращая внимания на индекс. Особенно это заметно если писать LIKE '%текст%'.
А во втором случае идет жесткое количество символов и нет необходимости просматривать все подряд, потому и работает быстрее. |
Delirium,спасибо Вам! А можно еще вопрос?
Цитата:
|
zvezda_t, ну будет у тебя первичный ключ, и пусть себе будет, не будет он тормозить твою базу в любом случае :)
И уникальный индекс тоже не помешает в данном случае. Вообще, у тебя какая стоит задача, оптимизировать быстродействие или создать рабочую базу? В случае небольшого (до 100 000 записей) количества записей быстродействие будет нормальным что с ключом, что без :) |
Delirium, базу я уже создала там порядка 20000 записей, но она с большой скорость растет. Поэтому сейчас моя задача оптимизировать быстродействие Smile
|
zvezda_t, не имея реальной загрузки сервера большими объемами, объективных данных не получить. Узкие места могут вылезти в самых неожиданных местах - начиная от индексации и заканчивая, например, неверно выбранным типом RAID массива для сервера. Так что конечный результат будет виден позднее:)
|
Время: 12:43. |
Время: 12:43.
© OSzone.net 2001-