|
|
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Люди!!! Подскажите Влияет ли на скорость работы количество полей составного ключа, если влияет, то как ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 12:53 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
А что значит скорость? Скорость вставки данных? Скорость выборки по полям входящим в составной ключ в инструкции Where ...? В одном случае замедлиться, в другом возрастет (может быть). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 12:58 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Скорость открытия таблицы SELECT * FROM MYTABLE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 13:00 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
В таком запросе не повлияет, даже если вобще не будет индексов и ключей имхо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 20:04 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
для All: >...если влияет, то как ? для Stanislav: КЛЮЧ сам по себе на скорость не влияет (он отвечает за целостность данных). На скорость влияет ИНДЕКС, который может строиться и не по ключевому полю. Т.о. КЛЮЧ<>ИНДЕКС, хотя любое ключевое поле обязательно индексируется. ИНДЕКС влияет на скорость положительно если ты производишь фильтрацию или сортировку по индексированным полям. Т.о. при выборке всех записей (SELECT * FROM MYTABLE), как правильно заметил fedd, наличие индексов не существенно. ИНДЕКС влияет отрицательно на скорость выполнения запросов на добавление, изменение и удаление записей, т.к. кроме изменения непосредственно самих данных будут вноситься изменения и в индексы. ИТОГО: не стоит делать ВСЕ поля индексированными, впрочем, как и не стоить оставлять без индекса поля, по которым ты чаще всего отбираешь и сортируешь записи... Но все это, конечно, имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 21:31 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
2 Нуф Нуф ИНДЕКС влияет на скорость положительно если ты производишь фильтрацию или сортировку по индексированным полям. Нет нет нет и еще раз нет. В смысле не всегда. Индекс с плохой селективностью влияет на скорость отрицательно. Ну а в остальных случаях - положительно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 02:25 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
для Лох Позорный: >Индекс с плохой селективностью ... :) А, стесняюсь спросить, возметесь ли вы объяснить вопрошающему, учитывая вашу любовь к пространным изложениям и предпологаемый уровень знаний автора топика, что такое "селективность"? Т.е. чем и почему одинаковые поля "Дата" в разных таблицах имеют различную "селективность"? :) Хм... А может и можно объяснить... "Повторяемость значений", имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 15:39 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Вот что не надо объяснять так это слово селективность-> селект-> Select. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 15:45 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Селективность - характеристика индекса, показывающая, насколько сильно уменьшается базовый набор при наложении условия на это поле. Лучшая селективность - у уникального индекса. Пример индекса с плохой селективностью. В поле 2 значения (True/False) 50 на 50 - селективность низкая, эффективнее не использовать индекс, а просканировать всю таблицу и на ходу отсеять ненужные записи. Если же те же самые 2 значения но распределение не 50 на 50, а, скажем 99 (False) к 1 (True), и выбирается строки со значением "True" (1%), то выгоднее взять индекс, выбрать нужный прощент записей, и только их и считать из базы. Если при тех же 99 к 1 надо отобрать записи с "False" (99%) - опять полное сканирование. Насколько мне известно, в оракле индекс не используется если собранная статискика показывает, что условие на этот индекс отсеивает меньше чем 95% записей (оставляет больше 5%) от общего числа. Кстати, в одном своем проекте совершенно независимо от оракла пришел к той же цифре (5%). Это подтверждает гипотезу вселенского разума К сожалению аксес не собирает такую статистику, и использует (или не использует) индексы как бог на душу положит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 15:55 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
2Лоху >использует (или не использует) индексы как бог на душу положит. Ну с рекодсетами вроде понятно как индекс использовать, а вот как с обычными селектами быть? Не уж то не знаешь? Судя по твоим топикам - ты Большой Любитель мучать индексы :) Давай -колись! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 16:03 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
2 Сенин Виктор Да откуда ж я знаю захочет аксес индекс использовать или нет? Я что, гадалка что-ли? Знаю способ заставить его не использовать ненужный индекс. Просто сделать из поля вычисляемое поле (типа вместо "Where Field1=123" написать "Where Field1+0=123"). А вот наоборот, заставить аксес выбирать по индексу если он сам этого не захотел - ну хрен его знает как... З.Ы. На Большого Любителя могу и обидеться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 16:11 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
А "Повторяемость значений", имхо, лучше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 16:20 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Тогда уже неповторимость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 16:21 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
2Лоху > На Большого Любителя могу и обидеться Да уж, это я не подумавши написал (ударение на "и") так, что прелагаю понимать смысл слова "Любитель" как любящего свое дело, да еще с большой буквы! Пойдет? :) Так, как заставить не исползовать индекс вроде понятно. Как заставить? Судя по showplan.out - у меня только PrimaryKey используется. М.б. все-таки внедрах SQL89/92 зарыты инструкции по установке хинтов. Ведь есть не документированный Check, AUTOINCREMENT и т.п. Второй вопрос - как заставить Access произвести перекомпиляцию (типа - обновить статистику) сохраненых запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 16:49 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
2 Виктор Сенин Ну ты же знаешь как, зачем тогда спрашиваешь? Пробел в запрос добавляешь и сохраняешь. Вот запрос и перекомпиляется, план меняется. Засада в том, что меняется иногда не в лучшую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:09 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
>Ну ты же знаешь как, зачем тогда спрашиваешь? Про планы я мало знаю :( Можно сказть - ноль В MSDN ничего не нашел. Где еще искать - хрен его знает. В книгах - либо лажа либо до конца не договаривают. >Пробел в запрос добавляешь и сохраняешь Насколько я знаю при сжатии информация об планах хериться, значит прийдется при каждом открытии базы добавлять пробел и сохранять запрос через DAO.QueryDefs - но тогда план точно обновиться? Как узнать какие запросы без плана? А точно ли план был построен? В какой системной таблице они храняться? Можно было бы на основе анализа ее делать вывод.Как через просмотр Showplan.out понять что запрос выполнился с планом? Как... как... как... К черту этот Акес - лучще пойду SQL-сервер помучаю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:22 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Пепелац без гравицапы не летает. Запрос без плана не выполняется. Если у запроса плана нет - при попытке исполнить запрос аксес его сначала откомпилирует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:24 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Пепелац без гравицапы летает. Только в пределах планеты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:26 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Ой... Вспомнил! А что достоуважаемый Олл скажет на счет Рашмо? Кажется, было заявлено (читал у Гетца), что составленный математическим образом составной индекс (или как там у него это называется? Карта? Множество?) работает быстрее всех прочих вариантов выборки! Таким образом, ежли я фильтрую записи по полю с около-уникальными значениями (индекс оправдан) и по полю с совсем не уникальными значениями (индекс не оправдан, с точки зрения учавствующих собеседников), то чтобы воспользоваться этой самой Рашмой (да прастят меня мелко-мягкие и лисы) мне нужны индексы по обоим (обеим? обам?) полям! Ну и что скажет Олл?! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:30 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Описания рашмора под рукой нет к сожалению... Вроде основная его прелесть именно при одновременном использовании двух и более индексов. Если тебе индекс невыгодно использовать - то и рашмор тебе не помошник. Я так понимаю, а как оно на самом деле - хз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 17:59 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Еееех... Я бы процетировал, но там написано, что "Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав". Даже эта цитата, имхо, поподает под "никакая часть" //законопослушный пятачок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 19:16 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
И х%й с тобой Цитируй дальше Лучше бы описание рашмора выложил да? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 22:18 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
>И х%й с тобой Всегда со мной! В подарок на днюху: Преимущества технологии Rushmore Поддерживаемая Jet технология Rushmore заключается в создании карты значений индексов, с помощью которой поиск значений нескольких индексированных полей выполняется исключительно быстро. Однако вы не можете сами определить, будет ли Jet использовать эту технологию при выполнении вашего запроса. Jet просто применяет ее всегда, когда это возможно. Для этого критерии отбора данных из любой входящей в запрос таблицы должны относиться к полям, принадлежащим разным индексам. Если для отбора записей в запросе используется только один критерий или если критерии относятся к полям, по котоым таблица не индексирована, технология Rushmore применяться не будет. Технология Rushmore работает как с собственными, так и с присоединенными таблицами Access, а также с присоединенными таблицами dBASE. Запросы включающие таблицы ODBC, Btrieve, Paradox или другие таблицы ISAM, не могут выполняться по технологии Rushmore. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 22:43 |
|
||
|
Составной ключ
|
|||
|---|---|---|---|
|
#18+
Где-то еще видел инфу по Рашмору, но, че-та, найти не могу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2003, 22:55 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32176477&tid=1681227]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 402ms |

| 0 / 0 |
