Индексы в ТЗ: поделитесь тонкостями... #538590

Есть ТЗ, добавляю туда индекс по паре колонок, потом делаю НайтиСтроки Если в структуре отбора больше значений, чем колонок в индексе, как оный индекс будет влиять на поиск? Интересует скорость...

Строй индекс исходя из точного набора значений структуры отбора.

Думаю - никак

Нереально, ибо структура меняется и каждый раз переиндексировать - больше времени потеряю

Тогда см.

Определи набор наиболее часто используемых вариантов отбора и переиндексируй нужные сочетания колонок, для остальных случаев - пусть ждут.

мда... Ну почему они всегда делают всё трансректально?...

Все в рамках банальной логики. Что не устраивает то ?

Мне банальная логика подсказывает, что нужно отобрать строки по существующему индексу, а потом среди отобранных уже искать по неиндексным колонкам, как, например, SQL делает...

скл так делает, потому что у него в индекс входит не больше 16 полей :-)

Одно дело крутить таблицы бд  на сервере, а другое - съедать ресурсы клиента на элементы малой применимости.

а кто сказал, что он не так делает? и вообще это действительно узкое место, на которое надо тратить силы для анализа?

Ага. Переделываю поиск по выборке на таблицы...

"кто сказал, что он не так делает" Я не говорил, я спрашивал :-) А говорили выше по ветке

Временные таблицы в запросе?

нет

не увидел утверждения выше... можно попробовать сперва делать Скопировать по тем колонкам, что проиндексированы, а затем НайтиСтроки по оставшимся, можно даже в копии индексы навесить. Но чот сомневаюсь, что будет шустрее... только замеры расскажут как быстрее.

Прежде чем экспериментировать, хотелось бы понять логику... В БТК (большой толстой книге) не нашёл инфы...

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

Ну сейчас я на 10000 строк наоптимизирую, а что потом будет, в реальной ситуации, на 50 000 строк? На 100 000? Знание логики может подсказать более оптимальный вариант...

дык и надо на 50000 строк тестить сразу, если возможно... а для определения влияния индекса не по всем колонкам для НайтиСтроки( можно и на 10тырах поэксперементировать

На реальных объёмах у меня на один запуск будет уходит по полчаса, это не работа...

Если есть возможность, можно попробовать попытаться в том запросе где оно получается поместить его в темп (или если оно собирается без запроса - то просто поместить в темп), проиндексировать в темповой тз максимально возможное количество полей, потом через менеджер ВТ дергать простые селекты с условием из твоего темпа - скорее всего создание индекса на сервере покроет те затраты, которые будут при поиске по ТЗ без индексов (только на больших объемах). На меленьких, к бабке гадалке не ходи - будет проигрывать.

оно, следует читать как "твое тз" :)

Ты уверен, что запрос к БД будет быстрей обращения к памяти?

+24 при учёте того, что код идет &НаСервере...

а скорость - это единственный критерий?

Еще наверняка критерий - "правильность" :-)))

Когда по месяцу себестоимость рассчитывается 17 часов - то да, пока единственный :-) Правильность - на совести 1сников...