Для чего НЕ нужны индексы

0. Олег Филиппов (comol) 2964 16.01.16 19:06 Сейчас в теме
Индекс лишним не бывает? Чем больше индексов, тем лучше? А не проиндексировать ли это измерение на всякий случай?
Если подобные вопросы иногда возникают в вашей голове, то эту статью прочитать было бы весьма полезно.

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

Комментарии
1. Сергей Старых (tormozit) 4314 17.01.16 10:23 Сейчас в теме
Опечатка "выжных"->"важных"
2. Дмитрий Асташов (gislink) 35 17.01.16 11:15 Сейчас в теме
Почитал с удовольствием. Есть еще программисты, способные просто и доступно разъяснять непростые для понимания вещи. Большое спасибо.
assanoff; Бубузяка; fishca; +3 Ответить
3. Сергей Старых (tormozit) 4314 17.01.16 12:13 Сейчас в теме
Хорошо бы еще про использование в индексах полей типа Булево рассказать.
4. Сергѣй Батанов (baton_pk) 207 17.01.16 12:28 Сейчас в теме
У всех таблиц 1С есть кластерный индекс.

А как же регистры расчёта?
Vladimir_Konyrev; Yashazz; comol; AlX0id; +4 Ответить 2
5. Алексей 1 (AlX0id) 17.01.16 14:03 Сейчас в теме
В MS SQL существуют 2 физических операции Index Seek и Index Scan. Index Seek - это хорошо, Index Scan - плохо.
Index seek означает просмотр индекса в порядке упорядочивания, либо по B-Дереву, Index Scan - обычная операция просмотра всех
записей таблицы, аналогичная всем известной Table Scan. Чаще всего данная операция присутствует в случае "неполного покрытия" индекса,
Если в индексе, к примеру, есть поле "Контрагент, Номенклатура" а отобрать записи надо по "контрагенту, номенклатуре и заказу покупателя". 

Это ваще что?
Зачем умные ребята из микрософт понаделали "хороших" и "плохих" операторов? Почему не сделали только хороших?
Индекс скан будет использоваться в случае "неполного покрытия"?? О_О
6. Марат Хафизов (Painted) 16 17.01.16 16:50 Сейчас в теме
А еще индекс не нужен для маленьких таблиц. Интересно вот с какого размера индекс начинает себя оправдывать?
7. ivanov660 ivanov660 (ivanov660) 336 17.01.16 19:17 Сейчас в теме
Вспомним УТ 10.2, 10.1, даже 10.3, по-моему... В каждом документе был индекс по полю "Организация". В последних версиях его нет. Как думаете, почему?

Как на счет включения в базе ограничения по RSL с ограничением по полю организация? Как написано в методике от 1С: при выполнении запросов в которых происходит соединение, условие и т.п. по полям, то соответствующие поля должны быть проиндексированы. Так в итоге индексы должны быть?
8. Олег Филиппов (comol) 2964 17.01.16 22:33 Сейчас в теме
(4) baton_pk, Честно забыл про них, пока пусть так повесит, сам просвещусь какие там индексы и поправлю :)
9. Олег Филиппов (comol) 2964 17.01.16 22:35 Сейчас в теме
(5) AlX0id,
Зачем умные ребята из микрософт понаделали "хороших" и "плохих" операторов

Ну ребята то сделали только хорошие операторы... Будь воля MS SQL он бы всегда делал только Index Seek. Но вот прикладные разработчики 1С регулярно вынуждают его пользоваться index scan :)
10. Олег Филиппов (comol) 2964 17.01.16 22:35 Сейчас в теме
(6) Painted,
Интересно вот с какого размера индекс начинает себя оправдывать
Опытным путём 2000 было в MS SQL... по крайней мере в 2008 так.
11. Олег Филиппов (comol) 2964 17.01.16 22:41 Сейчас в теме
(7) ivanov660,
включения в базе ограничения по RSL с ограничением по полю организация
RLS конечно :). Тут всё зависеть будет опять же от селективности... условия соединения. 1С в методике "не лезли в дебри" а написали как будет верно в общем случае. Если у вас в базе 10-ок организаций SQL соединит эти таблицы вложенными циклами, и просмотрев всю таблицу и будет полностью прав, следовательно индекс там не сдался. Но это не отменяет того что RLS вам внесёт полный хаус в запросы к БД и что в итоге получится надо смотреть только в профайлере :)
12. Яков Коган (Yashazz) 2092 18.01.16 14:13 Сейчас в теме
Ну что, книжку Филиппова пополам с методичкой с "1С-Эксперта" более-менее пересказал в общих чертах, молодец.
...интересно, долго ещё на Инфостарте будет пользоваться такой популярностью завуалированный плагиат?
qwinter; starik-2005; +2 3 Ответить 2
13. Иван Ли (Irwin) 60 18.01.16 14:29 Сейчас в теме
(4) baton_pk, не только регистры расчета. Если регистр сведений периодический (кроме по подчинению регистратору) и у него нет измерений, то кластерный индекс также не создается. Платформа 8.3.7
14. Сергѣй Батанов (baton_pk) 207 18.01.16 15:51 Сейчас в теме
(13) Irwin,
8.3.7 я ещё не смотрел, но ИТС пишет следующее:

Периодический регистр сведений

Индекс: [ОРРХ | ОРНР1 +] Период + [Измерение1 + ...] (Кластерный)
Условие и описание: Всегда.


PS. Или имелся ввиду НЕпериодический?
15. Олег Филиппов (comol) 2964 18.01.16 16:03 Сейчас в теме
(13) Irwin, (14) baton_pk, Для этого я написал
Это лишь общие правила, по которым платформа создаёт индексы на уровне СУБД. В каких-то деталях они могут отличаться, тем более в разных версиях платформы.
16. Олег Филиппов (comol) 2964 18.01.16 16:15 Сейчас в теме
(12) Yashazz,
завуалированный плагиат

Источники не книжка Филиппова, в которой эти вопросы незаслуженно упущены.

Был такой сайт - SQLCMD... там человек оочень подробно объяснял селективность, плотность, кардинальность. Сейчас сайт закрыли, у меня только архив остался.
В русскоязычном варианте аналогов не видел.

Оcновной англоязячный источник: Inside the SQL Server Query Optimizer - Benjamin Nevarez
И Grant Fritchey, SQL Server Query Perfomance Tuning

+ личный опыт конечно.

Вы видимо из статьи прочитали только начало (теорию) и конец (краткие рекоммендации), которые есть везде, но лишними не будут.
Krio2; fzt; fancy; hulio; tormozit; +5 Ответить 1
17. Сергей Носков (Sergey.Noskov) 710 18.01.16 16:19 Сейчас в теме
(12) Yashazz, базовые знания из области архитектуры СУБД вы считаете плагиатом методичек?
18. Сергей Носков (Sergey.Noskov) 710 18.01.16 16:50 Сейчас в теме
(16) comol,
Был такой сайт - SQLCMD... там человек оочень подробно объяснял селективность, плотность, кардинальность. Сейчас сайт закрыли, у меня только архив остался.
В русскоязычном варианте аналогов не видел.

В текстовом формате действительно информации мало. На techdays есть видео доклад "О самой частой причине выбора нестабильного/неэффективного плана запроса, или Оценка Кардинальности: что это такое, и как с ней бороться" в двух частях от Алексея Эксаревского про кардинальность, оценку стоимости запроса и все что с этим связано. Много, местами скучновато но подробно и с примерами.
19. Иван Ли (Irwin) 60 18.01.16 16:53 Сейчас в теме
(14) baton_pk, как раз периодический, но без измерений (исключая периодичность по позиции регистратора).
20. Олег Филиппов (comol) 2964 18.01.16 17:41 Сейчас в теме
21. Сергѣй Батанов (baton_pk) 207 18.01.16 17:58 Сейчас в теме
(20) comol,

беглый гуглёж дал вот это:
http://www.oszone.net/17922/
http://www.oszone.net/17920/

Там можно скачать видео и презентацию. Сам не смотрел ещё.

Кстати, советую ещё Pro SQL Server Internals - чтиво очень хорошо проясняет картину мира.
22. Сергей Старых (tormozit) 4314 18.01.16 18:05 Сейчас в теме
(21) Качество плохое. Я тоже не нашел выше качества. Видимо это оригинал =(
23. Олег Филиппов (comol) 2964 18.01.16 18:57 Сейчас в теме
(22) tormozit, (21) baton_pk, (18) Sergey.Noskov,
Как Сергей писал загуглил на teachdays.
Оригинал наверное тут:
https://www.techdays.ru/videos/4309.html
https://www.techdays.ru/videos/4310.html

И ещё до кучи: https://www.techdays.ru/videos/4303.html

Ещё наверное полезно было бы SQLCMD архив выложить. Сайт закрыт, поэтому наверное ни чьи (с) я не нарушу.

Плюсаните пост, пусть вверх всплывёт, глядишь кто-нибудь ещё прочитает и станет больше суммарных знаний в мире 1С :)
А архивчик со статьями только в самом посте внизу подцепился :(
Прикрепленные файлы:
_sql_cmd.rar
alex3067; SirStefan; agro23; Danil.Potapov; WizaXxX; oleg21592; TreeDogNight; Arrigo; gaglo; ikekoval; zzz14; Sergey.Noskov; AlX0id; Bronislav; ivanov660; _Z1; tormozit; +17 Ответить 4
24. Андрей М (_Z1) 38 18.01.16 22:13 Сейчас в теме
(23) Спасибо за архив.
Жалко только что нет комментариев к статьям.
в комментариях тоже были очень ценные сведения.

По статье в чем то Вы не совсем правы. ( но обсуждение этого на мой взгляд принесет
вреда больше чем пользы - тем более это Ваша статья - Ваше виденье ms sql )
25. ivanov660 ivanov660 (ivanov660) 336 18.01.16 23:10 Сейчас в теме
Архивчик сайта занятный, только что-то устарело с 2013 года, жалко нет обновления.
26. Сергей Носков (Sergey.Noskov) 710 19.01.16 13:39 Сейчас в теме
(23) comol, да, это те самые ссылки, качества лучше не нашел, но это не принципиальный момент.
По индексам так же есть отличный доклад Дмитрия Короткевича https://www.techdays.ru/videos/4303.html новичкам в разработке (особенно уверенным что чем больше индексов тем лучше) смотреть обязательно.
27. Олег Филиппов (comol) 2964 19.01.16 19:08 Сейчас в теме
(26) Sergey.Noskov, Пасиб. Включил в "заплюсованый" пост. Судя по всему соберём инфу в комментах и включу в основную статью :)
28. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 19.01.16 23:17 Сейчас в теме
(0)
3) Если индекс покрывает почти всё условие запроса - оцените число записей, которое придётся перебрать СУБД при
данной выборке, если оно невелико (менее нескольких тысяч) - не создавайте нового индекса

садись, два, приходи к нам на курсы, расскажем про дедлоки
29. Андрей Бурмистров (Andreynikus) 914 20.01.16 00:18 Сейчас в теме
Спасибо, хорошая статья, но есть несколько замечаний.
1. Вы написали
«Index Scan - обычная операция просмотра всех
записей таблицы, аналогичная всем известной Table Scan. Чаще всего данная операция присутствует в случае "неполного покрытия" индекса»


Здесь сразу несколько заблуждений.
1.1. Очень часто разработчики путают понятия покрывающего индекса и индекса подходящего под условия. Покрывающий индекс – это индекс который содержит в себе все поля возвращаемые в запросе, т.е. поля из раздела ВЫБРАТЬ. А индекс не подходящий под условия это как раз то, что вы описали.
1.2. Операция Scan всегда означает полный (а не частичный) просмотр всей таблицы или индекса, единственное исключение это когда в запросе есть ключевые слова ВЫБРАТЬ ПЕРВЫЕ тогда скан будет не всей таблицы/индекса, а только первых записей. Частичный скан в плане запроса будет выглядеть как оператор Seek но с условием Where, в графическом плане появится раздел Predicate.
2. По поводу чистки кэша после обновления статистики, сейчас SQL Server достаточно умный что бы самостоятельно перекомпилировать планы для тех таблиц, по которым было обновление статистики, не нужно этого делать еще раз.
3. У временных таблиц по умолчанию нет индексов. У регистра расчета нет кластерного индекса, но это все мелочи и можно посмотреть через вышеуказанную обработку.
4. Я бы дополнил статью разбором ситуаций, когда индекс есть но не может быть использован из-за неоптимально написанного запроса.
Danil.Potapov; m.s.moiseev; oleg21592; temsan; Yashazz; gadjik; tormozit; Vladimir_Konyrev; Gilev.Vyacheslav; +9 1 Ответить 3
30. Николай Зайков (Mortiferus) 270 20.01.16 08:31 Сейчас в теме
я вроде человек с высшим образованием (физик), а ничегошеньки не понял и, главное, ничего полезного не почерпнул. А где же конкретные примеры, как надо и как не надо использовать эти самые индексы? Может я такой "тугой", а все остальные такие "вумные", но для меня статья - "полный ноль". Даже те небольшие бесплатные видеоуроки с курсов 1С дали на порядок больше информации. Простите уж...
31. fzt fzt (fzt) 20.01.16 09:21 Сейчас в теме
(30) Mortiferus, окай. Вот тебе одна из полезняшек:
Данные любой таблицы в MsSQL будут кластеризованы (грубо говоря идти в том-же порядке на жестком диске) по одному из индексов. Зная какой это индекс, можно заставить летать то, что летать не может. можно переработать запросы, существенно сократив время их выполнения. Как-раз для случая, когда вернется 50% таблицы, логично данные таблицы сложить по порядку на диске, в котором ожидается их чтение. Таким образом чтение станет последовательным как для данных, так и для индекса. Физика HDD?

Разумеется при использовании SSD положением данных на диске можно пренебречь. Но не другими благами кластеризации. Вообще жаль что вам не интересно. Проблема в том, что разработчики и доработчики конфигураций активно и бездумно добавляют индексы реквизитам объектов. Статья о них и скорее для них.
32. Олег Филиппов (comol) 2964 20.01.16 11:06 Сейчас в теме
(28) Gilev.Vyacheslav,
расскажем про дедлоки
А заодно прочитаем про версионник? :)
33. Олег Филиппов (comol) 2964 20.01.16 11:14 Сейчас в теме
(29) Andreynikus, 1.1 ну по контексту понятно наверное... неполное покрытие условий индекса имелось ввиду
1.2 так и написано вроде...
2 Тестил на 2012 - нифига он этого не делал. В SQLCMD человек тестил на 2008 - не делал. Поэтому ваше утверждение что "сейчас MS SQL достаточно умный"... можно трактовать как "кому достаточно, а кому не достаточно". 2014 ещё дааалеко не у всех, и просто не проверял.
3 Ну конечно ориентировочно. Про регистры рассчетов забыл и уже указали
4 Этих ситуаций разбор это ещё на статью... притом не одну... Даже вон люди курсы отдельные придумали. Моя цель была чуть углубиться в работу оптимизитора... чтобы такие ситуации люди смогли разбирать сами...

34. Олег Филиппов (comol) 2964 20.01.16 11:17 Сейчас в теме
(30) Mortiferus,
а ничегошеньки не понял
Я старался, и у меня не получилось видимо :(. Почитайте Дейта попробуйте http://www.ozon.ru/context/detail/id/2309312/ потом вернитесь к статье.
ничего полезного не почерпнул
Ну последнюю часть прочитайте.
35. Сергѣй Батанов (baton_pk) 207 20.01.16 11:17 Сейчас в теме
(32) comol,
А заодно прочитаем про версионник? :)

Заодно вспомним, что не все сидят на 8.3 с отключенным режимом совместимости.
36. Олег Филиппов (comol) 2964 20.01.16 11:24 Сейчас в теме
(35) baton_pk, Ну я ещё до 8.3 писал что нужно бы включать: http://infostart.ru/public/91879/ и 8.3 тут не причём, если не полениться то можно сделать "жизнь чуть более приятной".
37. Сергѣй Батанов (baton_pk) 207 20.01.16 11:32 Сейчас в теме
(36) comol,
людям, которые не понимают такой элементарщины в индексах, лучше не пытаться
сделать "жизнь чуть более приятной".


чревато волной статей "как я гордо восстанавливал базу после своих кривых рук"
Gilev.Vyacheslav; +1 Ответить
38. Андрей Бурмистров (Andreynikus) 914 20.01.16 11:35 Сейчас в теме
(33) comol,
2. А как вы тестили перекомпиляцию если не серкрет? На моих тестах все перекомпилирутся, главное что бы план был не тривиальный. Тем более что в документации MS SQL написано что после обновления планы будут перекомпилироваться https://msdn.microsoft.com/ru-ru/library/ms190397(v=sql.120).aspx а документации Microsoft в отличии от документации 1С в большинстве случаев можно верить :)

4. Насчет отдельных курсов на эту тему, можете ссылку кинуть?
39. Олег Филиппов (comol) 2964 20.01.16 14:07 Сейчас в теме
(38) Andreynikus,
На моих тестах все перекомпилирутся
Да ладно? :))) Создайте табличку, создаёте руками левую статистику, создаёте индекс и вызываете предполагаемый план выполнения. ИМХО если бы при каждом запросе к СУБД MS SQL пересчитывал статистику и перекомпилировал планы выполнения запросов вы бы наслаждались песочными часиками большую часть времени своей работы. Более детально в (23) архивчик скачайте и там есть эта тема подробно. SQL 2012/2008 работает точно так.

Про курсы это к Гилёву он там уже выше что-то предлагал в этом роде :)
40. Андрей Бурмистров (Andreynikus) 914 20.01.16 14:24 Сейчас в теме
(39) comol,
Зачем смотреть предполагаемый план? Смотреть надо на фактический, они ведь могут отличаться.
Можете мне скинуть тот скрипт где создается такая таблица, меняется статистика а главное выполняется тот самый запрос? Или скажите точно где можно скачать этот пример.
Я еще раз повторю, если план запроса тривиальный, тогда естественно ничего перекомпилироваться не будет, в этом нет смысла.

ИМХО если бы при каждом запросе к СУБД MS SQL пересчитывал статистику и перекомпилировал планы выполнения запросов вы бы наслаждались песочными часиками большую часть времени своей работы.


Естественно СУБД не будет пересчитывать статистику при каждом выполнении запроса об этом никто и не говорит. Читайте пожалуйста внимательнее, план будет перекомпилироваться только если по таблице была обновлена статистика. То что перекомпиляция будет только один раз кажется на столько очевидным, что не требует уточнений.
41. Андрей Бурмистров (Andreynikus) 914 20.01.16 14:29 Сейчас в теме
(39) comol,
Про курсы это к Гилёву он там уже выше что-то предлагал в этом роде :)


Есть такая поговорка: слышу звон да не знаю где он :)

Есть курсы по оптимизации 1С, которые кстати я и веду :)
Но тема индексов там лишь одна из многих тем. Отдельных курсов только про индексы, как вы написали, я не встречал, хотя с удовольствием бы на них сходил.
Gilev.Vyacheslav; +1 Ответить 1
42. Сергѣй Батанов (baton_pk) 207 20.01.16 14:49 Сейчас в теме
Кажется, мы теряем правильное направление.

Раз сюда начали слетаться гуру, может, кто-нибудь подробнее расскажет нам про статистику?

Про то, что статистика строится по одному столбцу; про то, когда и как создаётся автоматическая статистика, про 200 шагов (почему их 200?); про автоматическое обновление статистики, автоматическое асинхронное обновление статистики - про это вообще некоторые такую бредятину несут иногда.
43. Сергей Носков (Sergey.Noskov) 710 20.01.16 14:51 Сейчас в теме
(29) Andreynikus,
1.2. ...когда в запросе есть ключевые слова ВЫБРАТЬ ПЕРВЫЕ тогда скан будет не всей таблицы/индекса, а только первых записей. Частичный скан в плане запроса будет выглядеть как оператор Seek но с условием Where, в графическом плане появится раздел Predicate.

т.е. операция сканирования индекса, если в запросе указано ПЕРВЫЕ, в плане запроса будет отображаться как операция Seek (поиск)?

44. Андрей Бурмистров (Andreynikus) 914 20.01.16 15:10 Сейчас в теме
(43) Sergey.Noskov,
Это 2 разных предложения про две разные вещи.
Если указано ВЫБРАТЬ ПЕРВЫЕ тогда будет операция Scan но это не означает что будет скан всей таблицы/индекса, будет просто чтение нескольких первых записей.

Частичный скан это другая история никак не связанная с ВЫБРАТЬ ПЕРВЫЕ. Частичный скан - это когда часть данных ищется по индексу, а часть сканируется.
45. Олег Филиппов (comol) 2964 20.01.16 15:22 Сейчас в теме
(40) Andreynikus,
план будет перекомпилироваться только если по таблице была обновлена статистика
Почти угадали. Только, к сожалению, не всё так просто....
Но дело в том что статистика сама не всегда обновится тогда когда нужно...

Или скажите точно где можно скачать этот пример
написал же - в (23) 2-я статья. Я тоже не всегда людям доверяю, поэтому всё смотрел и проверял сам, можете тоже проверить и убедиться, тем более полезно будет :).

если план запроса тривиальный, тогда естественно ничего перекомпилироваться не буде
вооо. Вы не пути истинном. А теперь осталось определить что понимается под "тривиальный". В плане может быть только 2 операции, но при этом если он не перекомпилится то вся база "станет ....ом" :)


46. Олег Филиппов (comol) 2964 20.01.16 15:25 Сейчас в теме
(41) Andreynikus,
Есть курсы по оптимизации 1С, которые кстати я и веду :)
О_о....
Ну уж тогда вам известно что
разбором ситуаций, когда индекс есть но не может быть использован из-за неоптимально написанного запроса

настолько избитая тема, что про неё ещё не рассказал только ленивый...
47. Олег Филиппов (comol) 2964 20.01.16 15:27 Сейчас в теме
(42) baton_pk, (23) SQLCMD 2-я статья... но там уже явно "не для всех"...
48. Сергѣй Батанов (baton_pk) 207 20.01.16 15:43 Сейчас в теме
(47) comol, так я и хотел бы увидеть объяснение "для всех", как в этой статье про индексы.
А не ссылку на статью, где лично я для себя нового ничего не открыл при беглом просмотре.
Gilev.Vyacheslav; +1 Ответить 1
49. Олег Филиппов (comol) 2964 20.01.16 16:49 Сейчас в теме
(48) baton_pk,
где лично я для себя нового ничего не открыл при беглом просмотре
О_о... Я раза 4 читал и каждый раз открывал что-то новое... ну наверное ты просто глубоко очень разбираешься в деталях работы оптимизатора MS SQL... Про статистику конечно ещё есть что написать... Но тут наверное "простой 1С-ник" вряд ли на что-то сможет повлиять. Подумаю вообщем...
50. Сергѣй Батанов (baton_pk) 207 20.01.16 18:01 Сейчас в теме
(49) comol,
наверное ты просто глубоко очень разбираешься

ну если только как-то так
51. Андрей Бурмистров (Andreynikus) 914 20.01.16 19:49 Сейчас в теме
(45) comol,
Почти угадали. Только, к сожалению, не всё так просто....
Но дело в том что статистика сама не всегда обновится тогда когда нужно...


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

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

База встанет если люди по вашему совету будут использовать чистку процедурного кэша всего сервера в рабочее время, такого делать ни в коем случае нельзя. Если уж так приспичило чистить процедурный кэш, можно это делать хотя бы для одной базы, а не для всего сервера.
Gilev.Vyacheslav; +1 Ответить 1
52. Андрей Бурмистров (Andreynikus) 914 20.01.16 19:57 Сейчас в теме
(46) comol,
Не соглашусь с вам, информации в контексте 1С на этот счет крайне мало, да не в контексте 1С тоже не особо то много. Большая часть русскоязычных статей сводится к описанию того что является и что не является SARG аргументом, в лучшем случае еще селективность упомянут. Но ведь в этой теме есть еще много чего интересного.
53. Олег Филиппов (comol) 2964 20.01.16 23:20 Сейчас в теме
(51) Andreynikus,
не считаете же вы что люди пишущие документацию MS SQL будут нас дезинформировать
Нет конечно ни в коем случае, всё чистая правда, как и в документации к 1С :))))).
изменилось только предполагаемое число строк
сущие мелочи в принципе... оно никак на план не влияет, и вообще SQL накой то фиг их считает, тратит лишнее время :)
такого делать ни в коем случае нельзя
конечно конечно... ни в коем случае нельзя... и статистику обновлять нельзя... оно всё само сделает, и вообще руками лучше не лезть - убъёт :). Не очищайте процедурный кэш, попробуйте на рабочем сервере пару дней... и ещё в базе в которой постоянно изменения, таблицы чистятся, запросы новые поялвяются.
Это лучшая рекоммендация в принципе... так к вам больше обращений будет ;). Которые очень легко решаются :)



54. Олег Филиппов (comol) 2964 20.01.16 23:48 Сейчас в теме
(52) Andreynikus, Ой ну не смешите. Учимся пользоваться поиском. Только по инфостарту:

http://infostart.ru/public/81694/
http://infostart.ru/public/378766/
http://infostart.ru/public/128175/
http://infostart.ru/public/308762/
http://infostart.ru/public/98628/
http://infostart.ru/public/374023/
http://infostart.ru/public/184361/
http://infostart.ru/public/374023/
http://infostart.ru/public/256292/

Отбалды в принципе, но прочитайте, ознакомьтесь - приобщитесь :)
55. Иван Ли (Irwin) 60 21.01.16 12:12 Сейчас в теме
(31) fzt, немного не так. То, что записи в таблице отсортированы, не значит, что они так и хранятся.
Физически записи в кластерном индексе отсортированы только в пределах страницы. Сами страницы отсортированы логически – горизонтальными ссылками между страницами, но располагаться на диске могут как угодно. Поэтому никакого последовательного чтения не будет.
56. Сергѣй Батанов (baton_pk) 207 21.01.16 12:17 Сейчас в теме
(55) Irwin,
отсортированы только в пределах страницы

более того, даже сами записи не отсортированы, а лишь хранится отдельно в конце страницы список с необходимым порядком записей.
57. Алексей 1 (AlX0id) 21.01.16 12:50 Сейчас в теме
(55) Irwin,
Тем не менее, операция дефрагментации индексов будет пытаться их привести к такому порядку. Так что иногда все-таки может быть и последовательное чтение %)

(56) baton_pk,
А это с точки зрения головки HDD должно быть пофиг - читается всегда страница целиком.
58. Сергѣй Батанов (baton_pk) 207 21.01.16 13:23 Сейчас в теме
(57) AlX0id,
с точки зрения головки HDD должно быть пофиг

Это да, я просто внёс теоретическое уточнение :)
59. Андрей Бурмистров (Andreynikus) 914 21.01.16 13:27 Сейчас в теме
(53) comol,
Я вижу вы любите путать теплое с мягким, либо просто сами не понимаете о чем говорите. Дальнейший диалог считаю бессмысленным.

P.S. Ни одна из приведенных ссылок не отвечает полностью на вопрос, почему индекс не используется даже когда он существует, везде только обрывки информации, что только подтверждает сказанное выше.
60. Олег Филиппов (comol) 2964 21.01.16 16:17 Сейчас в теме
(59) Andreynikus,
не отвечает полностью на вопрос, почему индекс не используется даже когда он существует
Вы всё ещё верите в существовании полного и всеобъемлющего ответа на этот вопрос? А в Деда Мороза или Санта Клауса тоже? :))))

Дальнейший диалог считаю бессмысленным

+100500
61. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 21.01.16 20:49 Сейчас в теме
(32) comol, не пори чушь, на запись версионник не поможет
62. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 21.01.16 21:04 Сейчас в теме
касаемо статьи в целом - почему не надо создавать индекс на каждый столбец и без этой статьи понятно - разумеется, индексы отлично себя показывают, пока вы выполняете запросы на выборку данных оператором SELECT, но как только начинается частый вызов операторов INSERT, UPDATE и DELETE, так пейзаж очень быстро меняется
но даже тут не все однозначно:
приоритеты задач тоже имеют значение - если мне нужно загрузить массив данных быстро в ущерб коллективной работе - я могу удалить хоть все индексы, если мне важнее коллективная параллельная работа, я наоборот пожертвую скоростью одного потока в пользу параллельности...
starik-2005; comol; +2 Ответить 1
63. Олег Филиппов (comol) 2964 21.01.16 22:43 Сейчас в теме
(61) Gilev.Vyacheslav, Оу
придётся перебрать СУБД при
данной выборке
речь то про чтение оказывается ;)
64. Олег Филиппов (comol) 2964 21.01.16 22:58 Сейчас в теме
(62) Gilev.Vyacheslav,
и без этой статьи понятно
но даже тут не все однозначно
Поэтому продолжаю верить что лишний раз обратить внимание на эти проблемы необходимо :)
65. fzt fzt (fzt) 22.01.16 07:47 Сейчас в теме
66. fzt fzt (fzt) 22.01.16 08:08 Сейчас в теме
(56)(57)(58) все это действительно нужно вываливать на неофита?
67. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 22.01.16 09:22 Сейчас в теме
(63) comol, покажи мне базу данных, в которую данные не пишутся, а как у тебя записи в таблице возникают, селектом? или рассказываешь про удобную часть, а неудобная за рамками статьи?
68. Олег Филиппов (comol) 2964 22.01.16 13:01 Сейчас в теме
(67) Gilev.Vyacheslav, Ну ты же изначально писал про дедлоки... которые возникают потому что при переборе записей они блокируются...
Так вот, в версионнике такая блокировка не приводит к дедлоку.

У меня в режиме версионирования дедлоки только при обменах возникают... Но с ними разделаться получилось только отказавшись от обменов :)
69. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 22.01.16 16:10 Сейчас в теме
(68) comol, я изначально писал что глупость рекомендовать "не создавать индексы", провоцируя захват избыточных данных
если в каком-то режиме не будет дедлоков, то вылезет таймаут/отсутвие версии или прочая "неприятность".

Не надо писать "не создавайте индексов если мало записей", не вводи в заблуждение людей.
70. Олег Филиппов (comol) 2964 24.01.16 14:47 Сейчас в теме
(69) Gilev.Vyacheslav,
таймаут/отсутвие версии или прочая "неприятность"
ну на практике у меня таких "неприятностей" не возникало, когда лишние индексы посносил.

Не надо писать "не создавайте индексов если мало записей"
по-моему это дискуссионный вопрос... а не "истина в последней инстанции".
Потому как
приоритеты задач тоже имеют значение

71. Роман С (Dach) 93 03.02.16 12:04 Сейчас в теме
Прочитал. И комментарии тоже. Остались вопросы.

Давайте на конкретных примерах, прямо, чтобы вообще всем было понятно.

Например, самая распространенная ситуация сейчас: платформа 8.3, MS SQL, режим работы ReadCommitedSnapshot. Конфигурация на УФ, работа в тонком клиенте, управляемые блокировки. Сервер СУБД нормально настроен: статистика, шринк, реиндекс и все остальное. Если контора "побохаче", то для tempdb куплен промышленный ssd.

1. Есть большой регистр накопления, 5-7 измерений к примеру, несколько ресурсов, несколько реквизитов. Все измерения ссылочные. В регистр осуществляется частая параллельная запись по не пересекающимся (в абсолютном большинстве случаев) наборам данных, также часто идет чтение с помощью отчетов и контроля остатков при проведении документов. Чтение возможно с отборами как по всем измерениям, так и по некоторым. В основном читаются итоги регистра, но в отдельных тяжелых отчетах, которые формируются не чаще нескольких раз в месяц - читается и физическая таблица, также с отборами по ну например 4 измерениям. Скорость записи в регистр является более приоритетна, чем чтение. Объем новых данных ежедневно - 5-7 тыс строк.

Как настроим индексы? Мне интересно, как будем рассуждать.

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

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

4. Регистр сведений, непериодический. Несколько измерений (2-3), один ресурс. Частая запись и частое чтение. Объем новых данных ежедневно - 100-200 строк. Чтение приоритетнее записи. На период чтения пересекающихся наборов данных из одного потока, все остальные потоки должны курить в сторонке. На запись тоже самое.

5. То же самое, что п. 4, только никто курить не должен, все читают и не мешают друг другу. На запись также.

Может несколько сумбурно, но просьба прокомментировать ход мыслей
72. Sergey Andreev (starik-2005) 992 07.02.16 13:47 Сейчас в теме
(71) Dach, да, все любят рассуждать про индексы, кто-то даже любит рассуждать про оптимизацию. Но никто особо не касается проблемы проектирования на примерах из математики вычислений, которые делает программа СУБД, чтобы возвратить результат. А это и есть самый важный момент.

Собственно, программа СУБД пытается оптимизировать запрос с целью совершить минимальное количество чтений из файла данных. ОТ этого и надо отталкиваться. Если у поля есть индекс, то поиск первой записи, удовлетворяющей условиям отбора по данной колонке, происходит в среднем за log2(N)/2 чтений индекса, если индекс представляет из B-TREE (двоичное дерево) и его подвиды (+/*). Это как найти нужную страницу в книге, перелистывая ее вперед/назад, или как угадывание возраста по больше/меньше. Также существуют индексы на основе хеш-функций, но с ними отдельный момент:
[quote]Важное свойство хеш-таблиц состоит в том, что, при некоторых разумных допущениях, все три операции (поиск, вставка, удаление элементов) в среднем выполняются за время O(1). Но при этом не гарантируется, что время выполнения отдельной операции мало́. Это связано с тем, что при достижении некоторого значения коэффициента заполнения необходимо осуществлять перестройку индекса хеш-таблицы: увеличить значение размера массива H и заново добавить в пустую хеш-таблицу все пары.[/quote] - wiki.

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

Таким образом могу сказать, что все должно идти из архитектуры решения целиком. Грохаете индекс по договору - соединяйтесь по контрагенту и договору всегда вместе. Нужны данные только по договору - делайте индекс на договоры. Отбираете по четырем полям - проиндексируйте одно основное, остальные найдутся рядом. Если скорость отбора приоритетна перед записью и уникальность данных всех полей достаточно высокая - проиндексируйте все. Но если для двух первых полей третье и четвертое - это два-три варианта, то смысла добавлять их в индекс особого нет.
73. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 08.02.16 11:59 Сейчас в теме
(72) starik-2005, мы пошли другим путем - оцениваем эффективность созданного индекса http://www.gilev.ru/sqlsize/
74. Роман С (Dach) 93 08.02.16 15:05 Сейчас в теме
(73) Вячеслав, а среди Ваших сервисов есть нагрузочное тестирование - массовая параллельная запись в таблицы и чтение из них же?

До сих пор я сам пишу себе такие тесты. Есть мысль сделать универсальную обработку, но может уже есть что-то подобное?
75. Андрей М (_Z1) 38 08.02.16 21:23 Сейчас в теме
(72) Почему только вставка меняет индекс.
Индекс меняется (точнее может ) меняться и при изменении записей
и точно меняется при удалении записей.




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

Вот это точно неправильный совет для любой таблицы - потому что это не всегда поможет
и потому что увеличивается время на построение плана запроса.
76. Вячеслав Гилёв (Gilev.Vyacheslav) 1732 11.02.16 10:59 Сейчас в теме
(74) Dach, да, 2й шаг теста tpc (G1C) тест на массовую запись
77. Sergey Andreev (starik-2005) 992 11.02.16 21:47 Сейчас в теме
(75) _Z1, он строится не каждый раз, потом хранится в процедурном кеше.
78. Андрей М (_Z1) 38 12.02.16 13:38 Сейчас в теме
(77) Как часто будет компилироваться план запроса Вы можете только предполагать
но никак не влиять на это ( исключение из этого можно задать опцию всегда перекомпилировать план )

В любом случая Ваш совет на каждое поле таблицы создавать свой индекс - неправильный.
79. Sergey Andreev (starik-2005) 992 12.02.16 17:51 Сейчас в теме
(78) _Z1, это был не совет, а один из вариантов. Внимательно прочитайте написанное мной.
80. Яков Коган (Yashazz) 2092 25.02.16 17:41 Сейчас в теме
Перечитал публикацию ещё раз, внимательно. Ничего нового. В значительной степени это компиляция давно известных статей (например, с sql.ru) и упомянутых мной методических материалов. Единственная польза - инициирован довольно профессиональный срач, в комментах накиданы полезные сведения. А в самой статье всё "по верхам" и много неточностей.
81. Олег Филиппов (comol) 2964 29.02.16 13:05 Сейчас в теме
(80) Yashazz,
это компиляция давно известных статей (например, с sql.ru)
Ну ладно теперь уже хоть не с книжки Филиппова плагиат у меня :)))) Ещё пару раз перечитаешь и глядишь поймёшь что первоисточники более фундаментальны :).

Ничего нового

На научные изыскания в области баз данных или разработку новых решений СУБД я не претендую :)))

всё "по верхам" и много неточностей

Не думаю что дальше "вглубь" имеет смысл..Если мне на собеседовании хотя бы каждый второй разработчик 1С без запинки расскажет чем отличается кластерный индекс от некластерного то можно будет копать и глубже.
Что касается неточностей - я не думаю что косяк с регистрами рассчета настолько принципиален...
82. Яков Коган (Yashazz) 2092 29.02.16 13:32 Сейчас в теме
(81) comol, ну вредничаю я. Мне примерно полгода назад долго объясняли старшие товарищи, что писать такие статьи на ИС значит жёстко баянить, я и не стал... А теперь вредничаю)
83. Олег Филиппов (comol) 2964 29.02.16 14:30 Сейчас в теме
(82) Yashazz, я тоже иногда так делаю тссс ;)
84. Sergey Andreev (starik-2005) 992 29.02.16 17:37 Сейчас в теме
(81) comol, что, обычные 1С-ники действительно этого не знают? Чъорд! Но я у Вам на собеседование не пойду. Чувствую, скоро меня собеседовать заставят.
85. Павел Алексеенко (qwinter) 505 03.03.16 09:30 Сейчас в теме
(84) starik-2005, обычный 1С-ник = бывший консультант = бывший продавец))) Откуда им это знать?
86. Сергей Беликов (HAMMER_59) 28 27.09.16 08:43 Сейчас в теме
"Как вы будете его угадывать? Перебором: "Это 1? Это 2? Это 3?". Скорее всего, вы будете задавать вопросы вида: "Оно больше 25?". И только когда вариантов останется около 2-3, вы будете перебирать возможные. "
У такого метода есть название - метод дихотомии.

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


87. Danil Potapov (Danil.Potapov) 288 02.02.17 23:54 Сейчас в теме
"Все, что Вы всегда хотели знать об индексах, но боялись спросить"
ссылки выше ведут на видео минимального качества, на youtube его выложили в отличном качестве
часть 1
https://www.youtube.com/watch?v=cW-2D2YiBjY
часть 2
https://www.youtube.com/watch?v=L1nweCOFZdk
часть 3
https://www.youtube.com/watch?v=Hcjqp2RHZRc
Fragster; +1 Ответить
88. Danil Potapov (Danil.Potapov) 288 02.02.17 23:55 Сейчас в теме
на самом канале много SQL классики, вчера даже Вячеслава Гилева выложили в 720p.
https://www.youtube.com/channel/UCE0_rcbKAtw51y0b6K6tgGg/videos
Fragster; +1 Ответить
89. Марат Хафизов (Painted) 16 10.02.17 16:11 Сейчас в теме
(29)
У регистра расчета нет кластерного индекса

В таком случае, логично создать его вручную. Чем это может быть чревато? Ну, кроме нарушения соглашения 1С, конечно.
90. Sergey Andreev (starik-2005) 992 11.02.17 21:02 Сейчас в теме
(89) "Кластерный индекс" - это абстракция, описывающая положение элементов таблицы при вставке. Создание кластерного индекса для таблицы расчетов по всей видимости бессмысленная затея. Как таковой "кластерный индекс" нигде не хранится - хранится только его описание.
91. Марат Хафизов (Painted) 16 12.02.17 12:29 Сейчас в теме
(90) "Кластерный индекс" - это физическое сортировка записей регистра. Поэтому работа с ним быстрее, чем с некластерным индексом. Я так это понял.
Если у регистра есть индексы, почему бы не выяснить, какой индекс используется чаще и отсортировать таблицу в соответствии с этим индексом, то есть сделать его "кластерным"?
Оставьте свое сообщение