Индексы лучше всего создавать по столбцам с большим числом уникальных значений в них, а также по столбцам, которые при использовании в качестве фильтров в выражениях WHERE возвращают небольшое количество строк.

Например не следует создавать индексы по столбцу status

FAM	STATUS
Петров	Женат
Иванов	Разведен
Сидоров	Женат
Иволгин	Разведен
Сидоренко	Холост
Кличко	Женат
Митин	Женат
...	...
Яковлев	Холост

Использование индекса, построенного на данных столбца STATUS
для классификации, не является оправданным. Например, следующим запрос
SELECT * FROM tbl WHERE STATUS = 'Женат'
вызывает непрерывный поток обращений от таблицы к индексу и наоборот. Из-за того, что условие WHERE STATUS = 'Женат' возвращает большой объем данных, серверу базы данных придется постоянно читать сначала данные из индекса, затем соответствующую строку из таблицы и т. д. В данном случае гораздо более эффективным было бы простое сканирование всех данных таблицы, поскольку значительная ее часть все равно должна быть прочитана.

Alexbootch, понял. У меня что-то тиа того, только номера, но ради чистоты эксперимента попробую почитать, хочу проверить -- будет быстрее или медленнее визуально. Если будет так же или медленнее, то нафиг надо такое счастье

в нормальной базе медленнее быть не может. Это может быть верно только для совсем безумных структур БД, когда скажем все значения в индексированной колонке одинаковые.

Проверил, чтение, даже по сети, очень быстрое -- выборка из базы в 45000 событий по одному номеру с индексированным столбцом меньше секунды, но теряет некоторую информацию при записи одного поля из другой таблицы. Таких дыр -- процентов десять по номеру и это -- в пиках нагрузки, в штатном режиме дыр нет. Надо как-то ускорить выборку полей из смежной таблицы. Возможно ее тоже придется индексировать по столбцу поиска.

какую именно иформацию?

Alexbootch, при получении данных, по определенному коду, выбирается поле одной из смежных таблиц и приклеивается к основному запросу на запись, но вроде, разобрался. При выборе были переставлены точки FormatStrihga, прикол в другом -- как оно умудрялось правильно читать, вот этого я не понял , вообще (чистый нонсенс), но исправил. Дальше буду смотреть соответствие, но смежные таблицы проиндексировал и убрал поиск по rowid, хорошо, что были резервные поля id, по ним и проиндексировал. Все хорошо, но размер в полтора раза увеличился с 40 кб до 57 кб

nesco, для хранения индекса требуется физическая память и иногда бывает так что индекс разрастается больше самой таблицы, для которой он был построен.

Alexbootch, да и фиг с ними, с этими килобайтами. Практически ушел от применения rowid, но есть некоторые места, гле никак не могу от него избавиться. Вот например: как заполнить поле id c автоинкрементом, начиная с 1 не применяя rowid от начала таблицы до конца, после удалении одной из строк -- предположим id было 1,2,3,4,5,6, а после удаления стало -- 1,2,3,5,6. Вот тут надо пересчитать последовательность id и привести ее к виду 1,2,3,4,5 (лучше всего в одной группе запросов), с rowid получилось, а вот без него никак.

по какой причине если не секрет? Некоторое время назад доказывалась истинность обратного...


каждая новая задача оригинальнее предыдущей. nesco, основываясь на предыдущем опыте этого же поста полагаю имеет смысл излагать задачу полностью. Глядишь научимся как все нормальные люди делать сортировку с перемещением записей, идентифицировать эти записи по уникальному идентификатору(а не псевдополю), обходится без пересчета индексов, которые будучи однажды прописанными меняться по идее не должны...

Dilma, ну что ты издеваешься? Мне предложили, я и подписался.Вот тут как раз я и столкнулся с тем, что при удалении теряется последовательность уникального индекса (об этом и были ранние посты)... Остальное известно.
А вот перемещение записей вообще не требует, оказывается, изменения однажды присвоенного индекса. Еще раз каюсь за тупой и необдуманный, затеянный мной, спор

уникальным он потому и называется, что будучи присвоенным один раз не меняется впоследствие. Есть основания считать, что индекс, для которого всегда поддерживается условие I(n) = I(n-1) + 1 (следующий на единицу больше предыдущего) - есть занятие бессмысленное(не оправданное). Точнее можно сказать при наличие примера.

Тут, похоже, мне надо хорошенько подумать. Я уже начинаю понимать, что такая последовательность действительно не нужна. В самом главном месте, там где оформляются динамические каналы, я вообще отошел от каких-либо индексов и использую другой признак (всеже пустой спор помог и заставил изменить алгоритм в лучшую сторону, сократив при этом еще и занимаемую динамическую память).

именно об этом уже и писалось не раз

Alexbootch, не катит тут Vacuum, совсем не катит. Сегодня в этом еще раз убедился, что Vacuum срабытывает только если переоткрыть базу. Rowid остается неизменным до закрытия базы. Вот об этом было писано мной с примером http://www.dev.hiasm.com/xf/topic.php?t=7798&start=30

Редактировалось 4 раз(а), последний 2022-04-03 04:00:35