Самые распространенные заблуждения об индексах в мире 1С

0. YPermitin 9072 28.11.19 10:36 Сейчас в теме
"Магия" индексов привела к множеству заблуждений об их работе. Попробуем развеять некоторые из них в контексте 1С.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. VmvLer 28.11.19 10:54 Сейчас в теме
Пока дочитал до
И так, поехали!

подустал.
Зачем такие длинные прелюдии? это ведь не драмкружок.
red80; Velesstroy_OOO; Afanasyev.sv@mail.ru; Sword; KRJ; mike1970; Yashazz; nkp14108; Дмитрий74Чел; trickster; YPermitin; +11 Ответить
2. YPermitin 9072 28.11.19 10:55 Сейчас в теме
(1) чтобы подготовить к лонгриду :)
3. user-z99999 22 28.11.19 12:28 Сейчас в теме
(2)
Скрипты для каких версий ms sql ?
4. YPermitin 9072 28.11.19 12:30 Сейчас в теме
(3) от 2012 и выше.

На 2008 практически не проверял, нет под рукой просто.
42. Afanasyev.sv@mail.ru 06.12.19 20:21 Сейчас в теме
(1) плюсую, 70% воды

Зашёл в другие публикации - тоже самое. Сочинение "как я провел лето". Читать отпало желание.
43. YPermitin 9072 06.12.19 20:33 Сейчас в теме
(42) расстроили. А я старался.
5. Free1CforAll 28.11.19 13:11 Сейчас в теме
(0) автор, как удается столько писать и интересно.

Можно уже книгу напечатать :)
Sword; davdykin; +2 Ответить
8. YPermitin 9072 28.11.19 13:19 Сейчас в теме
(5) боюсь, она не будет пользоваться спросом)))
Слишком узкая тематика)))
6. katakuna 28.11.19 13:17 Сейчас в теме
Большое Вам спасибо за труд.
mvxyz; jekichan; Sword; mike1970; mogl; nkp14108; ids79; kuzyara; davdykin; EVKash; Eleepod; xxxAndricxxx; YPermitin; +13 Ответить
7. YPermitin 9072 28.11.19 13:18 Сейчас в теме
9. starik-2005 2180 28.11.19 13:53 Сейчас в теме
Аффтор, пеши есчё.

Только не понял, нафига внутри запроса с ВТ запрос на номенклатуру? С первого взгляда достаточно заменить соединение с левого на внутреннее.

ЗЫ: Имхо, оставлен вопрос о том, почему индексы помогают запросам выполняться быстрее...
YPermitin; +1 Ответить
11. YPermitin 9072 28.11.19 14:15 Сейчас в теме
Благодарю!

(9)
ЗЫ: Имхо, оставлен вопрос о том, почему индексы помогают запросам выполняться быстрее...


Я поэтому добавил ссылки на базовый материал, а то текста было бы слишком много.


(9)
Только не понял, нафига внутри запроса с ВТ запрос на номенклатуру? С первого взгляда достаточно заменить соединение с левого на внутреннее.


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

В теории это значит, что:
1. Сначала нам придется получить результаты всех наборов в этом вложенном запросе.
2. Потом выполнить внутреннее соединение временной таблицы с результатом этого подзапроса (ну то есть виртуальной таблицы).
Если мы накладываем условия в параметрах виртуальной таблицы, то они сразу же устанавливаются в условиях самого подзапроса, и мы не получим лишние данные.

Но это в теории. На практике же оптимизатор SQL Server ведет себя как настоящий оптимизатор, прокидывая условия из соединений во вложенные запросы, тем самым исправив неоптимальную выборку. Это действительно работает и можно подтвердить экспериментально.
К сожалению, оптимизатор так не всегда может сделать и это зависит от статистики, кэша планов запросов и др. То есть в некоторых ситуациях может случиться так, что запрос будет выполнен самым неоптимальным образом.

На PostgreSQL оптимизатор тоже обрабатывает такие ситуации, но менее успешно. По крайней мере "игры" с этим делом в прошлом году были не в пользу PG.

Ту же картину можно увидеть, если использовать виртуальные таблицы среза последних в динамических списках (если итоги для среза не включены). Часто оптимизатор СУБД тоже "прокидывает" условия соединения во внутренние условия вложенных запросов.

В общем, можно довериться оптимизатору СУБД и не писать эти условия, но можно быть параноиком и явно указать ему как нужно отбирать данные :)
20. Darklight 22 28.11.19 17:04 Сейчас в теме
(этот пост не является комментарием к посту 11 - и размещён под ним случайно)

Лично я считаю, что в гипотетически будущей платформе 1С: Предприятие 9 правильным было бы вынести все прямые вопросы производительности (понятно что это не касается текстов запросов, например) за рамки конфигуратора 1С (вернее среды разработки) в отдельный продукт. Я бы разделил конфигуратор на два продукта (а то и три-четыре-пять, но третий и четвертый, и пятый продукты пока не буду тут осуждать - производительности они не касаются):

1. Собственно среда разработки - в которой создаётся базовая архитектура конфигураций 1С Предприятия - т.е. метаданные элементов платформы и связанные с ними алгоритмы - то, что непосредственно касается программистов 1С и архитекторов баз данных (увы или нет - но в рамках корневой архитектуры платформы 1С: Предприятие - проектирование базы данных и алгоритмов к ней ведётся в одной среде и их разделение - не целесообразно без разрушения всей корневой архитектуры платформы 1С) Если не выделять это в отдельные продукты - то тут же должно производиться и проектирование дизайна интерфейсных форм и прочих выходных макетов.

2. Технологический конфигуратор (Административный инструмент) - а вот сюда должны быть вынесены все средства чисто по администрированию платформы 1С, начиная от управления развёртывание и бэкапированием, контролем ошибок, включая управление пользователями и их правами, и заканчивая анализом и настройкой производительности. То есть всё то, что, как мне кажется, должно входить в навыки специалиста(эксперта, профессионала) по технологическим вопросам платформы 1С: Предприятие (и отчасти администратора баз данных).

Соответственно, именно в этот технологический конфигуратор должны входить инструменты, как по анализу производительности СУБД и базы данных (ну и других проблем СУБД тоже) – т.е. сюда должны быть сразу включены средства а-ля 1С Центр управления производительностью. Так и инструменты по настройке этой производительности: начиная от гибкого управления индексами (ведь «теперь этим занимается специалист» – и нет нужды шибко упрощать этот процесс), и закачивания вопросами управления файловыми группами СУБД, секционированием, и настройкой кластеров (как 1С, включая отдельные сервера - 1С Дата акселераторы (долой консоль севрера 1С – всё нужно свести в этот инструмент); так и СУБД - ну надеюсь 9-я генерация платформы-таки позволит размещать базу распределённой на разных серверах СУБД без сторонних извращений).

То есть – тут должен быть частично реализован функционал СУБД – но в единой обобщённой (для всех поддерживаемых СУБД) среде, понятной и привычной для тех, кто работает с продуктами 1С. Тем более, что я прекрасно понимаю, что отдельных специалистов технологическим вопросам в большинстве компаний не будет (но об этом ниже будет замечание), и данным инструментом будут пользоваться и программисты (но вряд ли начинающие, а начинающие – если и будут там что-то делать – то строго по готовым инструкциям); но, кто бы не работал с данным инструментом - всё-таки нужно будет получать определённые знания по его использованию – достойные отдельного «двухтомника» администрирования и отдельных курсов и сертифицированы специалистов для разного уровня квалификации.

Соответственно, я считаю, что программист не должен управлять индексами – это не его дело – его дело – это реализация логики функционирования приложения. Он не должен разбираться в тонкостях выполнения его алгоритмов, на тех или иных СУБД, и заниматься анализом планов запросов и сбором статистики работы запросов.

Но, программист должен иметь возможность оказывать влияние на управление производительностью (но не безоговорочное). К пример, программист мог бы:

1. Писать запросы – Технологический специалист, анализируя статистику выполнения которых (ну или просто получая отчеты о вновь написанных или структурно переработанных старых запросах, проводя их тестовое выполнение) – принимал бы решения по настройке индексов. Ну или выдавал бы рекомендации программисту – по перезаписи таких запросов (анализ должен быть двойной – в терминах 1С Предприятие и в терминах СУБД – но программист должен получать замечания к запросам в терминах 1С Предприятие). Более того, в первый продукт – а-ка среда разработки – можно тоже встроить средства статистического (и прямого) замера выполнения алгоритмов – чтобы более менее продвинутый программист сам мог их анализировать и делать выводы – по их производительности – т.е. продвинутый профайлеровщик (в т.ч. запросов) в этом инструменте тоже нужен. Как им же должна быть снабжена и консоль составления запросов (даже если запросы пишутся прям в редакторе кода). При этом, хорошо сразу прикреплять к запросам тест-юниты – чтобы их можно было тестировать вне рабочей среды исполнения (естественно изолированно - не изменяя рабочие данные) – это поможет анализировать запросы и технологическим специалистам, которые могли бы прогонять эти тесты, в т.ч. не тривиальные – требующие предварительной дата-генерации

2. Создавать виртуальные таблицы (ну или view в терминах СУБД; в т.ч. материализованные, но за их техническое исполнение – должна отвечать платформа 1С Предприятие, тем более, что возможности view в разных СУБД отличаются). В общем случае – это не просто отдельно созданные описания источников данных, с обращением к СУБД (в общем случае не обязательно с обращение к базе данных даже) – тут может быть реализован достаточно мощный механизм, как описания повторного используемого кода, так и оптимизации выборки данных, включая их кеширование (вот 1С Дата акселераторы - это тема как раз для развития до данного механизма). Но программист лишь описывает, своё желание – получать данные из такого источника и использует его в коде. Все тонкости его технического воплощения – на плечах платформы и с контролем (управлением) со стороны технологического специалиста. В т.ч. и необходимость создавать индексы под такие выборки. То есть – программисты должны стараться все серьёзные (по объёму данных или частоте использования) выносить в такие вот виртуальные таблицы (в простейшем случае – представляющие просто параметризованные макрозапросы) – и выбирать данные уже из них. А настройка нужных индексов для обеспечения эффективности такой выборки (как для view – если он материализован, так и для исходных данных) – это уже дело технологического специалиста (в т.ч. он же решает – будет ли в итоге это подзапрос, или сначала нужно создать временную таблицу, в т.ч. со своими индексами – причём это всё тоже может быть вариативно – в зависимости от параметров выполнения – которые будут фактически передаваться в виртуальную таблицу – как отчасти это делает 1С Предприятие 8 со своими виртуальными таблицами – разве что пока не научилась превращать их во временные с индексами – но кто знает, может ещё научится в ближайшие десятилетия).

3. Делать пометки к полям, которые программист считает необходимым проиндексировать. Но это лишь рекомендательные пометки. Для специалиста по технологическим вопросам – чтобы он мог проанализировать эти поля для индексирования с повышенным приоритетом. Метка, должна иметь и пояснительный комментарий, и привязку к решаемой задаче, и привязку к какой-то классифицированной группе обобщения – когда разные элементы можно обобщённо анализировать в единиц структуре группы. Ну и пометка может иметь признак будущей или текущей критичности – выставляемая когда продвинутый программист твёрдо уверен в том, что этот индекс будет критически нужен в будущем (когда наберётся достаточно данных – и это будет не длительный процесс) или нужен уже сейчас (данных уже достаточно) – и нужно постараться реализовать этот индекс (возможно отключив другие – менее приоритетные).

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


Ну и в конце, несколько слов о ситуации, когда компания не может себе позволить иметь даже самого примитивного специалиста по технологическим вопросам (даже в качестве обученного программиста или системного администратора):

1. Если компания работает с очень небольшими базами – то она, будет использовать и простую версию платформы в которой даже не будет такого инструмента как «Технологический конфигуратор» (вместо него может быть упрощённый продукт по развёртыванию баз на серверах 1С Предприятие – что-то типа консоли управления кластерами 1С). Но тут, значит, и заботиться о гибкой настройке не требуется – в этом случаем минимальную оптимизацию на себя должна брать платформа 1С (ну и СУБД). Чего-то особо гибкого и оптимального тут не требуется. Вполне будет достаточно примерно текущего уровня автоматического создания индексов как на текущих релизах 1С: Предприятие 8. Ну разве, что нужно будет ещё бегло проанализировать созданные программистом виртуальные таблицы и безоговорочно удовлетворить настоятельные просьбы создать тот или иной индекс.

2. Покрупнее компаниям стоит подумать о размещении базы в облаках (это явно будет главным трендом второй половины XXI века, когда и настанет эпоха гипотетической платформы 1С: Предприятие 9) – там оптимизацией производительности займутся местные специалисты (а уровень углублённого анализа будет определяться текущим контрактом).

3. Другим же компаниям, с локальным размещениям баз, но уже использующих более продвинутую платформу, имеющую продукт «Технологический конфигуратор» – настоятельно будут рекомендовать хотя бы раз в год вызывать специалиста по технологическим вопросам со стороны – чтобы он приходил и анализировал состояние производительности (и не только) СУБД, проводил настройку и давал рекомендации другим специалистам (в т.ч. программистам). Тем более, что в таких компаниях вряд ли будет использоваться версия продукта с самой продвинутой лицензией – значит средства оптимизации производительности будут несложными (урезанными) – и вызов специалиста вряд ли будет дорогим.

4. Ну, или можно использовать внешние онлайн сервисы (в т.ч. бесплатные), которые будут подключаться к «Технологическому конфигуратору» и использовать его возможности для анализа и настройки информационной базы и кластерной архитектуры (думаю тут Вячеслав Гилёв подсуетится, да и не только он).
5. Да что там – если с оптимизацией справятся онлайн сервисы – то с ней могут справятся и встроенные в платформу аналитические механизмы – об этом ниже.

Как, я упомянул выше в первом пункте – простая версия платформы (ну там Базовая или гипотетическая Стандартная) могут даже не иметь такого инструмента, как «Технологический конфигуратор» - и там платформа настраивает индексы «по старинке», очень ограничено и не очень оптимально. Анализируя лишь метаданные по простым схемам.

Но в более продвинутой версии платформы (Профессиональная, Корпоративная…) – встроенный анализатор уже может быть куда помощнее. И это важно - умные автоматизированные технологии анализа и оптимизации – это тоже будет тренд второй половины XXI века – и 1С Предприятие 9 не должна будет в этом отставать!


Встроенный AI-анализатор производительности в определённых случаях сможет подменять отсутствующего специалиста по технологическим вопросам. И выполнять его функции, то есть:

1. Собирать и анализировать статистику выполнения запросов (и не только)

2. Строить модели прогнозов (экстраполяцию) роста данных, требуемых ресурсов и количества операций чтения/записи данных в будущем – и оценивать изменения производительности.

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

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

5. При наличии настроенных полномочий, ставить эксперименты по изменению архитектуры производительности – собирать статистику (на тестовом или на даже на рабочем контуре – без деструктивных вмешательств); более того – после глубокого анализа метаданных и статистики даже генерировать новую архитектуру хранения данных – и тестировать её (параллельно) – а далее уже перелагать её программистам и архитекторам баз данных, с приложением результатов анализа и статистики.

6. Динамически мониторить состояние СУБД и менять настройки оптимизации – при выявлении новых более оптимальных схем (в т.ч. после существенного изменения карты данных, или сценариев работы с ними)

7. Собирать (направлять – если разрешено) статистику и рекомендуемые сценарии настройки из единого центра сбора данных о производительности – который будет консолидировать "мировой" опыт применения тех или иных подходов по оптимизации, и по соответствию уровня оборудования и его конфигурации, объёмам данных и операций над данными. И на основе этой статистики – тоже выдавать свои рекомендации.

8. Автоматически проводить регламентные операции по обслуживания СУБД. И контролировать их процесс.

Умный AI-анализатор/администратор/технологический специалист может много чего ещё уметь делать самостоятельно (как делать, так и просто анализировать, прогнозировать и информировать – смотря как будет настроен). Тут, конечно, очень важен будет первоначальный процесс развёртывания такой интеллектуальной системы. Вот тут, нужен будет эксперт по технологическим вопросам. Но это условно «разовая» операция – и дальше система уже будет жить своей жизнью, без лишних затрат – хотя, всё равно, раз в год – хорошо бы, чтобы её контролировал специалист.
Но главный смысл в том, что компании, купившие, к примеру, локальную платформу 1С: Предприятие 9 Профессиональный выпуск – и не желающие иметь ни штатного, ни приходящего специалиста по технологическим вопросам. Могли бы разово потратиться на развёртывание такой AI-системы (вряд ли такие компании смогли бы даже самостоятельно успешно развернуть даже 1С Предприятие 8 УПП или даже Торговлю 11). И дальше полагаться на продвинутые AI-возможности оптимизации. Не напрягая оными своих непродвинутых программистов.

Ну, а купившие выпуск КОРП – уж наверняка будут иметь как минимум приходящего специалиста по технологическим вопросам – но даже для него такой встроенный AI-помощник был бы хорошим подспорьем (особенно грамотно постоянно подстраиваемый с большой свободой к экспериментам и анализу, которую и предполагает использование лицензии КОРП – что нужна не для всех, а только тем, кому ОЧЕНЬ важны вопросы оптимизации производительности) – он бы смог выполнять много рутины и подготавливать много аналитических материалов для специалиста – а уже он бы принимал конечные решения, в т.ч. отложенно запланированные, для автоматического выполнения AI-помощником в ближайшее технологическое окно.



Ну, я вот так вижу себе процесс оптимизации в гипотетической платформе будущего – 1С Предприятие 9 (ждать которую в обозримом будущем, увы, не стоит – это лишь мои фантазии). Буду, рад, если найдутся желающие высказать своё мнение по данному вопросу (любое – как за так и против) – можете даже поставить оценки данному комментарию, в зависимости от того – согласны Вы или нет, с данным материалом!
Lucechiaro; alevnev; Synoecium; TipsyKID; user774630; +5 Ответить
10. Darklight 22 28.11.19 14:02 Сейчас в теме
Спасибо за статью.
Хочу поднят тему запроса из статьи
ВЫБРАТЬ
	ТоварыНаСкладах.Период КАК Период,
	ТоварыНаСкладах.ВидДвижения КАК ВидДвижения,
	ТоварыНаСкладах.Номенклатура КАК Номенклатура,
	ТоварыНаСкладах.Характеристика КАК Характеристика,
	ТоварыНаСкладах.Назначение КАК Назначение,
	ТоварыНаСкладах.Склад КАК Склад,
	ТоварыНаСкладах.Помещение КАК Помещение,
	ТоварыНаСкладах.Серия КАК Серия,
	ТоварыНаСкладах.ВНаличии КАК ВНаличии,
	ТоварыНаСкладах.КОтгрузке КАК КОтгрузке
ИЗ
	РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
ГДЕ
	ТоварыНаСкладах.Номенклатура = &Номенклатура

УПОРЯДОЧИТЬ ПО
	Период
Показать


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

Так же тут остался не рассмотрен (хотя изначально поднят но тут же забыт) вопрос а как же тут сделать эффективный отбор, с отбором, таки, всей номенклатуры, но по конкретному складу?

За запросы по анализу недостающих (ну или избыточных) индексов спасибо - хотя это, бесспорно, очень обширная тема - для целой статьи!
Но, тем не менее, жаль, что нет ни одной отсылки такому инструменту как 1С Корпоративный инструментальный пакет (в частности к ЦУП; а так же к его сторонним аналогам), которые бы позволили подходить к управлению индексами более корректно и конкретно. Считаю, что правильно было хотя бы упомянуть эти инструменты и рассказать как они помогают принимать более обдуманные решения по созданию тех или иных индексов (ну или не помогают - об этом тоже стоило бы написать).
ILNIK; davdykin; YPermitin; +3 Ответить
12. YPermitin 9072 28.11.19 14:34 Сейчас в теме
(10)
Но, тем не менее, жаль, что нет ни одной отсылки такому инструменту как 1С Корпоративный инструментальный пакет (в частности к ЦУП; а так же к его сторонним аналогам), которые бы позволили подходить к управлению индексами более корректно и конкретно.


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

ЦУП и, например, PerfExpert однозначно могут помочь понять что нужно поменять в конфигурации индексов. А дать описание этому можно, но уже не здесь и сейчас. Нужен отдельный гайд)


(10)
Но так и не привели ответа - а как же правильно посчитать остатки/обороты с отбором по измерениям, когда как раз обычные таблицы остатков/оборотов за период не подходят!


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

Как получать остатки и обороты без виртуальных таблиц эффективно?
Тут очень много кейсов, и решений тоже. Например, если нужно посчитать по всей номенклатуре, но по конкретному складу:
1. Можно добавить индекс по складу, но он может не помочь если записей много и СУБД посчитает, что тут лучший вариант это сканировать таблицу. Возможно, это использовать индекс "Склад + Период" и отбирать записи по периоду, но можем также столкнуться с тем, что объемы данных все равно будут большими, малая селективность.
2. Если получать большие объемы через таблицу движений, то сам регистр накопления теряет смысл. Мы же перестаем использовать итоги. Возможно, кому-то подойдет вариант по созданию неплатформенного индекса в самой таблице итогов. Да, это противоречит ЛС и это уже много раз обсуждали, но иногда может сильно понадобиться.

Можно предложить какие-нибудь более конкретные кейсы для разбора и по возможности я бы их описал.
13. Dorosh 144 28.11.19 14:46 Сейчас в теме
Спасибо за отличную статью. ИМХО ее бы прекрасно дополнила часть про использование Tuning Wizard для сочинения нужных индексов
davdykin; YPermitin; +2 Ответить
15. YPermitin 9072 28.11.19 14:52 Сейчас в теме
(13) надо подумать об этом.

Благодраю!
14. user1274438 28.11.19 14:48 Сейчас в теме
Правильно ли я понимаю, что
в соответствии с порядком полей индекса

подразумевает, что есть разница между
WHERE ((T1._Fld1551 = @P1)) -- Фильтр по разделителю данных
AND ((T1._Fld32140 = @P2)) -- Фильтр по дате графика
AND ((T1._Fld32138RRef = @P3)) -- Календарь
AND ((T1._Fld32139 = @P4)) -- Год
и
WHERE ((T1._Fld1551 = @P1)) -- Фильтр по разделителю данных
AND ((T1._Fld32138RRef = @P3)) -- Календарь
AND ((T1._Fld32139 = @P4)) -- Год
AND ((T1._Fld32140 = @P2)) -- Фильтр по дате графика
?
YPermitin; +1 Ответить
16. YPermitin 9072 28.11.19 14:54 Сейчас в теме
(14) тут имеется ввиду не порядок того, как условия накладываются в самом запросе. Главное чтобы они подходили под структуру индекса, под порядок полей в нем.

То есть если бы мы сделали в запросе условие так, что первое поле в индексе было бы НЕ задействовано, то этот индекс бы не использовался.

А то как Вы условия напишите в запросе - не важно. Оптимизатор сам будет решать какой план ему выбрать и как данные в итоге получать.
17. user1274438 28.11.19 15:07 Сейчас в теме
(16) если в таком случае применить это правило в вышеприведенном примере про календарные графики
накладывать фильтр нужно от первого поля и так далее по порядку

т.е. до последнего поля индекса _Fld32140 (дата графика)
то предыдущее утверждение в этом же предложении
Да, можно не делать отбор по всем полям из состава индекса

может вызвать некоторое противоречие

P.S.
без намека на тролололо
18. YPermitin 9072 28.11.19 15:14 Сейчас в теме
(17)
может вызвать некоторое противоречие


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

Подумаю, может упрощу текстовку или добавлю GIFку для наглядности.

+
19. akim2040 20 28.11.19 17:01 Сейчас в теме
Очень доходчивая статья несмотря на долгое вступление. Открыли глаза на некоторые вещи, спасибо!

ЗЫ может под спойлер прелюдию?
21. muskul 29.11.19 03:22 Сейчас в теме
Очень познавательно
YPermitin; +1 Ответить
22. davdykin 24 29.11.19 07:13 Сейчас в теме
А на счет книги, я бы на вашем месте подумал )). Статьи у вас очень удачные, большое спасибо за ваш труд.
ids79; YPermitin; +2 Ответить
23. YPermitin 9072 29.11.19 07:29 Сейчас в теме
(22) тогда и мемы придется в книгу добавлять :)
mogl; acanta; +2 Ответить
28. ids79 5610 29.11.19 09:24 Сейчас в теме
(22)Я тоже голосую за книгу )).
YPermitin; +1 Ответить
30. DoctorRoza 29.11.19 14:07 Сейчас в теме
Юрий! Можно сваять свою инфо-конфигурацию. В нее выкладывать свои статьи. Сделать грамотный рубрикатор, другие авторы подтянутся.
24. ByNiko1984 29.11.19 07:34 Сейчас в теме
(0) прочитал статью и понял, что не знаю еще столько, что можно учиться пару лет.

Статья может напугать новичков, особенно мем в конце статьи :)

Ну а так достойно сделано!
YPermitin; +1 Ответить
25. YPermitin 9072 29.11.19 07:55 Сейчас в теме
26. lmnlmn 61 29.11.19 08:56 Сейчас в теме
Прочитал и тут же захотелось бросить вверенную на разработку задачу и открыть профайлер на SQL-сервере! Отличный материал!
davdykin; ids79; YPermitin; +3 Ответить
27. YPermitin 9072 29.11.19 08:58 Сейчас в теме
(26) спасибо за добрые слова!
29. VmvLer 29.11.19 11:06 Сейчас в теме
логичнее выбрать жанр книги "драма"
а сюжет построить классический
он - 1С-эксник
она - Фузинка
жестокий мир был против их союза и они, устав бороться, за один
присест съели годовой запас грибов своих отделов разработки.
31. comol 4346 02.12.19 17:25 Сейчас в теме
Крутейшая статья. Спасибо за труд.
YPermitin; +1 Ответить
34. YPermitin 9072 02.12.19 18:45 Сейчас в теме
32. a.ivanov 02.12.19 18:31 Сейчас в теме
Ты! Да, ты! Ты разработчик 1С, который не прочитал ни одной книжки про субд которую используешь и не знаешь про сайты docs.microsoft.com или postgresql.org. Эта статья для тебя.
sevushka; KTo; +2 Ответить
36. YPermitin 9072 02.12.19 18:46 Сейчас в теме
(32) никогда не слышал об этих сайтах!

Им точно можно доверять? :D

:)))))))))))
33. acanta 02.12.19 18:37 Сейчас в теме
У нас есть ещё и файловая СУБД от 1с и в ней все это не так уж плохо, но она вроде как триал или демо, не знаю как правильно это называется.
YPermitin; +1 Ответить
35. YPermitin 9072 02.12.19 18:45 Сейчас в теме
(33) я с файловой базой мало работал. Хорошо это или плохо - не знаю. Но это так :)
37. KTo 03.12.19 05:05 Сейчас в теме
Любая магия это отсутствие знаний.
YPermitin; +1 Ответить
38. triviumfan 21 03.12.19 21:19 Сейчас в теме
И снова они... ничего нового.
ЗЫ: вру, новое оформление статьи.
YPermitin; +1 Ответить
39. YPermitin 9072 03.12.19 21:20 Сейчас в теме
40. eaa 04.12.19 11:54 Сейчас в теме
Возник вопросец. До прочтения статьи считал, что для работы индекса достаточно наложить фильтр на все поля измерений и не важно в какой последовательности. А субд сама выстроит порядок. Всё-таки я был не прав?
YPermitin; +1 Ответить
41. YPermitin 9072 04.12.19 12:12 Сейчас в теме
(40) если вы накладываете на все поля индекса, то он будет работать эффективно. Все правильно.

Но! Отбор должен быть селективным. Если в результате отбора вернется 50% записей таблицы, то индекс будет бесполезен.

Также не обязательно накладывать отбор на все поля. Нужно, чтобы отбор накладывался на поля в соответствии с их порядком в индексе (при этом не обязательнотв тексте запроса порядок отборов делать, СУБД сама определит как нужно). Например, индекс:
- Номенклатура
- Склад
- Серия

Чтобы индекс работал можно установить отбор только о номенклатуре. Или по номенклатуре и складу, или номенклатуре и складу и серии.

А вот отюоры только оп серии, только по складу, только по серии и складу не позволят использовать индекс.

Ну и не забываем про селективность. Плюс есть еще и другие факторы, влияющие на использование индекса.
acanta; eaa; +2 Ответить
44. acanta 06.12.19 20:42 Сейчас в теме
Индексы в дбф были практически последней темой в курсе, поэтому про них забыли. Мне до сих пор непонятно чем отличаются idx в FoxPro от cdx в 1с.
И как их ухитрились впихнуть в один файл с метаданными и таблицами. И как оно должно открываться по сети.
Вопрос зачем не стоит - ибо в файловой базе 7.7. визуально можно определить в файловом менеджере какие таблицы были изменены при записи и проведении документа, что несекьюрно.
Читать словарь dd для понимания необязательно, многие программисты так делают, и считают это чем то вроде научного открытия, выполненного методом научного тыка. Что вполне соответствует действительности.
Интересно, есть ли отличия в индексах СУБД SQL, postgres и файловой 1с.
Вывод: за индексами нужно ухаживать, но нельзя дать инструкцию как это сделать, нужно как то видеть их состояние в комплексе с тем что именно индексируется.
В этом и состоит магия.

Вопрос - если 1с публикатор не настолько хорош, может есть возможность добавлять какойто специальный сетевой протокол, вместо TCP, по аналогии с 3g - 5g мобильной связью, чтобы работать в сети с файловой базой было возможно? Или это совсем бред?
Оставьте свое сообщение
Вопросы с вознаграждением