|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
11.08.2006, 14:09
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
День добрый! Насколько я понял из наблюдений за сервером и чтения форума (я с Информиксом совсем недавно) - он автоматически строит индексы на ключи (первичные и внешние). Соответственно у меня несколько вопросов: 1. Индекс на первичный ключ (по умолчанию) - некластерный. Можно такое поведение как-то изменить? 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 14:46
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Евгений Фадеев Насколько я понял из наблюдений за сервером и чтения форума (я с Информиксом совсем недавно) - он автоматически строит индексы на ключи (первичные и внешние). Если такого индекса нет, то он строит сам, а если есть -- то его и пользует. Евгений Фадеев 1. Индекс на первичный ключ (по умолчанию) - некластерный. Можно такое поведение как-то изменить?Создать самому? Но два момента: записи таблицы упорядоченными по индексу будут только в момент постройки индекса, далее из-за DML операций они таковыми уже не будут, и самое главное это нафиг не надо. Евгений Фадеев2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)?Выбросить нельзя. Такие индексы (на внешние ключи) он использовать будет, например при удалении из справочника, при соединении со справочником. Зачем их не использовать? Зачем хинты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 14:52
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Евгений ФадеевДень добрый! Насколько я понял из наблюдений за сервером и чтения форума (я с Информиксом совсем недавно) - он автоматически строит индексы на ключи (первичные и внешние). Соответственно у меня несколько вопросов: 1. Индекс на первичный ключ (по умолчанию) - некластерный. Можно такое поведение как-то изменить? Создайте индекс раньше, чем первичный ключ. Еще есть оператор alter index Евгений Фадеев 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? Внешнего ключа без индекса не бывает. Использовать индекс или нет, решает оптимизатор. Почему вы думаете, что индекс вам помешает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 14:52
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Евгений ФадеевДень добрый! Насколько я понял из наблюдений за сервером и чтения форума (я с Информиксом совсем недавно) - он автоматически строит индексы на ключи (первичные и внешние). Соответственно у меня несколько вопросов: 1. Индекс на первичный ключ (по умолчанию) - некластерный. Можно такое поведение как-то изменить? Можно, нужно построить уникальный кластерный индекс а потом создавать ПК. В этом случае сервер будет пользоваться индексом построенным заранее. Евгений Фадеев 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? Нельзя. Для FK индекс нужен по обьективным причинам 1. По полям PK=FK очень часто делается join. 2. Проверка целостности. При попытке удаления PK записи поверка наналичие FK записи производится по индексу. 3. Каскадное удаление. Не понимаю в чем может быть выигрыш от отсутствия индекса под FK? и зачем может пондобится давить FK индекс хинтами ? Может лучше вообще не строить FK если он мешает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 14:59
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Итого в сухом остатке: 1. С первичными ключами понятно. Забиваем. 2. Индексы на внешние ключи. Вопрос на засыпку: всегда ли наличие индекса ускоряет SELECT? 3. (to onstat-) Внешние ключи нужны не для ускорения чего бы то ни было, а для определения ограничений в рамках схемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 15:01
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
ЗЫЖ Целостность можно поддерживать с помощью триггеров и check констрейнтов, тогда индексы можно не делать. С помощью триггеров можно много чего интересного наделать, например в качестве pk сделать поле(я) вьюхи (таблицы из другой бд). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 15:06
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Евгений Фадеев 2. Индексы на внешние ключи. Вопрос на засыпку: всегда ли наличие индекса ускоряет SELECT?Всегда. Оптимизатор решает использовать или нет. Всегда замедляют insert. Всегда ускоряют update, delete (в смысле когда фильтр нормальный, информикс -- блокировщик). На каждое всегда естественно найдутся исключения, но писать лень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:08
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Журавлев ДенисВсегда. Оптимизатор решает использовать или нет.То есть сервер их строит всегда, а потом оптимизатор мучается выбором? :) Журавлев ДенисВсегда замедляют insert.Это понятно. Журавлев ДенисВсегда ускоряют update, delete (в смысле когда фильтр нормальный, информикс -- блокировщик).А если происходит UPDATE индексированного поля? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:16
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Журавлев ДенисЗЫЖ Целостность можно поддерживать с помощью триггеров и check констрейнтов, тогда индексы можно не делать.Да все можно - зачем только? Если все тоже самое можно делать гораздо проще, нагляднее, быстрее и дешевле?! Журавлев ДенисС помощью триггеров можно много чего интересного наделать, например в качестве pk сделать поле(я) вьюхи (таблицы из другой бд).Стоя на лыжах в гамаке? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:22
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Евгений ФадеевТо есть сервер их строит всегда, а потом оптимизатор мучается выбором? :)Ага, он комсомолец. Евгений Фадеев Это понятно.Я рад. Евгений ФадеевА если происходит UPDATE индексированного поля?А если delete? В общем зачем я вам объясняю если вы и так все знаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:26
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Журавлев ДенисВ общем зачем я вам объясняю если вы и так все знаете.:)) Я не все знаю. Я про Информикс - совсем мало. Я с ним всего пару месяцев сожительствую. На самом деле за ответы спасибо. Мне они были нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:34
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Евгений ФадеевДа все можно - зачем только? Если все тоже самое можно делать гораздо проще, нагляднее, быстрее и дешевле?!Ага, сегодня тяпница, будем развлекатся. Erwin раньше так генерировал триггера -- ух, только батоны жми, писофкейк. Очень напрягал меня информикс автоиндексами в ситуации: таблица 200 млн. записей, есть мой индекс (fk, f1), а он пративный еще избыточный (fk) хочет. Поработав с информиксом 2 года я понял что создавать несколько бд в одном инстансе -- идиотия, и лишний геморрой. Был случай: бд 400 таблиц, две таблицы с естественными ключами, остальные сурогаты, конечно естественный ключ пришлось изменить, добавить поле и исключить уникальность, для того чтоб старый код хоть как-нибудь работал, таблицу переименовали, создали вью (с именем ляля_tbl -- гыгы), изображающее из себя старую таблицу, и целостность поддерживать триггерами выполняя селекты на вью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:45
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Евгений Фадеев 3. (to onstat-) Внешние ключи нужны не для ускорения чего бы то ни было, а для определения ограничений в рамках схемы. Я и об этом написал onstat- 2. Проверка целостности. При попытке удаления PK записи поверка наналичие FK записи производится по индексу. Другие базы данных могут проверять по таблице(данным), но Infromix проверку FK делает именно по индексу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 16:56
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
onstat- Евгений Фадеев 3. (to onstat-) Внешние ключи нужны не для ускорения чего бы то ни было, а для определения ограничений в рамках схемы. Я и об этом написал Я это к тому что onstat-Может лучше вообще не строить FK если он мешает?Ну и (если начать придираться, чего делать не хочется) - ключ не строится, а объявляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 17:14
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Тяпничное: Поработав два года с ораклом я понял какое счастье, что в информиксе по умолчанию планы запросов не шарятся между сессиями и для каждого курсора строятся заново. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 17:18
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Журавлев ДенисТяпничное: Поработав два года с ораклом я понял какое счастье, что в информиксе по умолчанию планы запросов не шарятся между сессиями и для каждого курсора строятся заново.Э... А в чем счастье-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 18:27
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Евгений Фадеев onstat- Евгений Фадеев 3. (to onstat-) Внешние ключи нужны не для ускорения чего бы то ни было, а для определения ограничений в рамках схемы. Я и об этом написал Я это к тому что onstat-Может лучше вообще не строить FK если он мешает?Ну и (если начать придираться, чего делать не хочется) - ключ не строится, а объявляется. Ну если быть окончательно педантичным то не ключ, а ограничение добавляется (alter table ...... add constraint ......). Я прошу прощения за то, что нечаянно ввел Вас в заблуждение некорректным переводом(интерпретацией). Я не собирался придираться, мне просто интересно чем в данном случае Евгений Фадеев 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? мешает индекс на FK? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.08.2006, 19:47
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Евгений ФадеевЭ... А в чем счастье-то?Гыгыыгы. В том. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.08.2006, 19:59
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Для Фадеева OFFTOPIC: Как дела на новом месте? Пиши на мыло sher хороший человек terlis точка ru. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.08.2006, 19:12
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Журавлев Денис Евгений Фадеев 2. Индексы на внешние ключи. Вопрос на засыпку: всегда ли наличие индекса ускоряет SELECT?Всегда. Оптимизатор решает использовать или нет. Не соглашусь. К тому же и оптимизатор не всегда такой умный, как хотелось бы. Журавлев ДенисНа каждое всегда естественно найдутся исключения, но писать лень. В том то и дело, что эти исключения иногда играют большое значение и вполне понятно желание Евгения управлять возможностями. Как и в случае с автоматическим построением индексов для внешних ключей (как, например, у Оракла, когда автоматом не строится). Но все же, если сравнивать в общем, то я бы все таки оставил принудительное построение индексов, т.к. это намного лучше, чем когда люди вообще не строят индексы на ключах (видел пару раз такие промышленные БД на Оракле, когда у заказчика через несколько месяцев эксплуатации "вдруг" все начинало жутко тормозить, а у разработчика на малых объемах летало). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.08.2006, 19:39
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
Тан Евгений Фадеев 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? Почему вы думаете, что индекс вам помешает? Пример такого "мешающего" индекса - автоиндекс на ключ "пол", где всего два значения М и Ж. Надо доказывать неэффективность такого индекса ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.08.2006, 21:23
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
vasilisПример такого "мешающего" индекса - автоиндекс на ключ "пол", где всего два значения М и Ж. Надо доказывать неэффективность такого индекса ? А можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.08.2006, 08:46
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
vasilisвсего два значения М и Ж. А что так мало ? Обычно 3, иногда 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.08.2006, 10:15
|
|||
|---|---|---|---|
Индексы на ключи |
|||
|
#18+
vasilis Тан Евгений Фадеев 2. Можно ли выбросить некоторые индексы на внешние ключи (например в ситуации, когда таблица длиной в несколько десятков миллионов записей ссылается на таблицу длиной в десяток записей)? Или с этим нужно жить (либо он сам такие индексы пользовать не будет, либо ему нужно хинтами это задавать)? Почему вы думаете, что индекс вам помешает? Пример такого "мешающего" индекса - автоиндекс на ключ "пол", где всего два значения М и Ж. Надо доказывать неэффективность такого индекса ? А это зависит от распределения данных. И если согласно распределению индекс не эффективен, тогда он не будет использоватся оптимизатором. Зато без индекса большой проблемой будут попытки изменить значения ключа в главной таблице. Или записи из нее удалить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.08.2006, 11:22
|
|||
|---|---|---|---|
|
|||
Индексы на ключи |
|||
|
#18+
Тан А это зависит от распределения данных. И если согласно распределению индекс не эффективен, тогда он не будет использоватся оптимизатором. Индексы на таблицы размером меньше одной страницы почти никогда не используются, хотя можно попробовать что будет если все поля таблицы в индекс включить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=44&tablet=1&tid=1608596]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 310ms |
| 0 / 0 |
