|  | 
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ Добрый день! Уважаемые, вопрос ламерский, но я его всё же задам и для себя закрою навсегда. Есть условная таблица Код: sql 1. 2. 3. 4. 5. 6. 7. И запросы к этой таблице будут очевидными: Код: sql 1. 2. 3. 4. В такой ситуации надо ли в таблице определять такие индексы: Код: sql 1. 2. 3. 4. 5. 6. Дайте пожалуйста дельный совет! ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 11:03 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormotВ такой ситуации надо ли в таблице определять такие индексы Обычно не надо. Но в зависимости от используемой СУБД и её оптимизатора могут быть нюансы. Posted via ActualForum NNTP Server 1.5 ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 13:21 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormotДобрый день! Уважаемые, вопрос ламерский, но я его всё же задам и для себя закрою навсегда. Есть условная таблица Код: sql 1. 2. 3. 4. 5. 6. 7. И запросы к этой таблице будут очевидными: Код: sql 1. 2. 3. 4. В такой ситуации надо ли в таблице определять такие индексы: Код: sql 1. 2. 3. 4. 5. 6. Дайте пожалуйста дельный совет! Формально, решение принимается на таких вещах как план запроса и представлении о селективности индексируемого поля. (Например, для поля типа пол, обычные индексы могут только ухудшить. Лучше какой-нибудь bitmap. Но такой для оперативных БД вообще не очень подходит. У Оракла, Фул скан считывает по несколько блоков за раз, а с индексом по одному.) Но составной индекс для такого запроса выглядит как-то не очень. Составной напрашивался бы при условии WHERE aa.fkObjID=…. AND orderNum =… Т.е. по этому запросу без дополнительной информации только KEY fkIdx (fkObjID), И то при условии что мало строк получим при условии aa.fkObjID=${OBJ_ID}. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 14:36 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ vadiminfoТ.е. по этому запросу без дополнительной информации только KEY fkIdx (fkObjID) И то только если индекс на внешний ключ не создаётся сервером автоматически. Как я и сказал выше. Posted via ActualForum NNTP Server 1.5 ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 14:51 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ Dimitry SibiryakovНо в зависимости от используемой СУБД и её оптимизатора могут быть нюансы. +++ При двоичной сортировке и необходимости супер-быстрого выполнения запроса, может вообще появится желание аж сделать индекс: fkObjID, orderNum, objName 1) поиск по индексу 2) исключение сортировки за счет считывания упорядоченных данных из индекса (зависит от БД и настроек, сортировка должна быть binary, для Oracle могут потребоваться хинты INDEX_ASC) 3) все поля результата в индексе, исключается обращения к исходной таблицы Сортировка по индексу - крайне приятная вщеь, если в результате выбираются десятки-сотни тысячь записей Отстувие обращение к исходной таблице - вместо рандом доступа к индексу и исходной таблице, получаем упорядоченный (последовательный) доступ к индексу. Шминделя крутящихся дисков говорят спасибо ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 15:43 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ Leonid Kudryavtsev, мало ли какая мне сортировка в такой выборке понадобится. Надо с каждым полем (и не с одним) FK склеивать? По-моему, лишнее это. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 18:12 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ KreatorXXILeonid Kudryavtsev, мало ли какая мне сортировка в такой выборке понадобится. Надо с каждым полем (и не с одним) FK склеивать? По-моему, лишнее это.wat? переведите пожалуйста.. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 26.09.2019, 21:57 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormot, 1. Первичный ключ где? 2. Уникальный индекс надо сделать. Он покроет как FK, так и вопрос целостности данных. Уникальные индексы вообще не для скорости работы создаются и не для того, что они кому-то очень нравятся. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 27.09.2019, 08:17 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormotДайте пожалуйста дельный совет! для начала надо разделять логические условия на таблицу и "физические". Под логическими будут определены такие вещи как PK и требования уникальности, сервер для них создаст необходимые индексы и они не зависят ни от каких запросов. Дальнейшие индексы и необходимость в них определяется исключительно как с данными будут работать, например нужно определить кластерный индекс. Необходимость в каждом конкретном индексе определяется типами запросов к базе, OLAP/OLTP, результатами нагрузочных тестов итп ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 28.09.2019, 01:21 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ если такой индекс: Код: sql 1. слепить при таком ORDER BY: Код: sql 1. то он вообще не сработает потому что orderNum работает ПОСЛЕ fkObjID ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 28.09.2019, 09:06 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ stenfordдля начала надо разделять логические условия на таблицу и "физические". Под логическими будут определены такие вещи как PK и требования уникальности, сервер для них создаст необходимые индексы и они не зависят ни от каких запросов. Дальнейшие индексы и необходимость в них определяется исключительно как с данными будут работать, например нужно определить кластерный индекс. Необходимость в каждом конкретном индексе определяется типами запросов к базе, OLAP/OLTP, результатами нагрузочных тестов итп Охеренно понятный и аргументированный ответ! Спасибо! Сергей Васкецов1. Первичный ключ где? 2. Уникальный индекс надо сделать. Он покроет как FK, так и вопрос целостности данных. Уникальные индексы вообще не для скорости работы создаются и не для того, что они кому-то очень нравятся. 1. Первичный ключ там - это id SERIAL 2. Хорошо, учту. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 28.09.2019, 12:25 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormot, СУБД-то какая? Некоторые СУБД умеют использовать индекс KEY objOrdIdx (fkObjID, orderNum) для отбора записей по fkObjID и последующей сортировки по orderNum. CHAR(255) выглядит странно. Почему не VARCHAR ? И так ничего и не было сказано про статистику/демографию данных. А это важно для решения использовать или не использовать тот или иной индекс. Например, если условие aa.fkObjID=${OBJ_ID} отбирает половину записей таблицы, то никакие индексы не помогут, за исключением, разве что, покрывающего. Будет ли толк от покрывающего индекса - тоже зависит от множества факторов, вплоть до того, лежит ли он уже в кэше (и помещается ли туда) или нет. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 28.09.2019, 12:39 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ miksoft,  СУБД - MariaDB 10.3 CHAR(255) - это просто тут написал. Весь пример таблиц - чисто для наглядности. Сама идея только что есть параметр по которому отбирают, и есть по которому сортируют. Статистика базы относительно равномерная предполагается. Т.е. для разных ${ObjID} сравнимые кол-ва записей. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 28.09.2019, 19:14 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormotВ такой ситуации надо ли в таблице определять такие индексы: Код: sql 1. Зависит от, но скорее стоит, чем нет. kormot Код: sql 1. Совершенно бессмысленно. kormot Код: sql 1. Такой индекс может иметь смысл, если количество orderNum на один objID велико и если СУБД сумеет его использовать. Но скорее всего, он окажется на уровне первого по полезности. kormot Код: sql 1. Если мешать не будет, лучше определить. Бывает, что декларативные ограничения целостности очень лихо спасают задницу от неприятностей. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 29.09.2019, 15:00 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ Для этого запроса подойдут индексы KEY fkIdx (fkObjID), или KEY objOrdIdx (fkObjID, orderNum) один из двух. Второй потенциально может быть испльзован для ORDER BY но если записей немного, скажем, 10-30, то смысла в составном индексе вместо по одному полю, мало. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 01.10.2019, 12:52 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ Большое спасибо Уважаемые, за полезные ответы! ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 03.10.2019, 11:15 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ для 10-30 индекс вообще не нужен индекс от сотен начинается, даже от 1000 ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 03.10.2019, 13:20 |  | ||
| 
Какие стоит указать индексы? | |||
|---|---|---|---|
| #18+ kormot, Тут надо делать индекс KEY fkIdx (fkObjID), ИЛИ KEY objOrdIdx (fkObjID, orderNum) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.10.2019, 16:10 |  | ||
|  | 

| start [/forum/topic.php?fid=32&msg=39872707&tid=1539904]: | 0ms | 
| get settings: | 8ms | 
| get forum list: | 12ms | 
| check forum access: | 3ms | 
| check topic access: | 3ms | 
| track hit: | 41ms | 
| get topic data: | 10ms | 
| get forum data: | 2ms | 
| get page messages: | 49ms | 
| get tp. blocked users: | 1ms | 
| others: | 14ms | 
| total: | 143ms | 

| 0 / 0 | 
