Использование Union вместо OR

Публикация № 1111939

Администрирование - Производительность и оптимизация (HighLoad)

sql server query planning

5
Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

Иногда медленные запросы можно исправить, немного изменив запрос. Один из таких примеров может быть проиллюстрирован, когда несколько значений сравниваются в предложении WHERE с помощью оператора OR или IN. Часто OR может вызывать сканирование индекса или таблицы, которая может не быть предпочтительным планом выполнения с точки зрения потребления ввода-вывода или общей скорости запросов.

Многие переменные вступают в игру, когда оптимизатор запросов создает план выполнения. Эти переменные включают в себя множество характеристик оборудования, настроек экземпляра, настроек базы данных, статистики (таблица, индекс, auto-generated), а также способ написания запроса. Здесь мы меняем способ написания запроса. Каким бы неожиданным это ни казалось, даже если два разных запроса могут возвращать одни и те же результаты, путь, по которому они идут, может быть совершенно разным в зависимости от формата запроса.
 

UNION vs OR


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

Вот наш оператор OR:
 

SELECT SalesOrderID, *
FROM sales.SalesOrderDetail
WHERE ProductID = 750 OR ProductID = 953




Из этого плана выполнения мы видим, что мы выполняем сканирование 121 000 строк. (Вы не можете видеть количество строк, но это так).

Теперь выполним тот же запрос, но написанный с использованием UNION вместо OR:
 

SELECT [SalesOrderID], *
FROM sales.SalesOrderDetail
WHERE ProductID = 750
UNION
SELECT [SalesOrderID], *
FROM sales.SalesOrderDetail
WHERE ProductID = 953




Здесь мы видим две ветви операций. Одна ветвь затрагивает 358 строк, а другая — 346 строк. Обе ветви встречаются для выполнения операции конкатенации, объединяющей оба набора результатов. У нас есть два отдельных поиска, но у нас также есть поиск ключей для получения необходимого списка SELECT. Это не было необходимо для операции сканирования, потому что мы все равно затрагивали все строки в операции сканирования, таким образом, данные были получены во время сканирования, а не после. Это связано с индексом и нужными нам строками, а не с UNION или OR. Однако я скажу, что выборка (select) также является фактором выбора поиска против сканирования (seek vs scan), но мы проигнорируем это в этой статье.
 

Объяснение


Почему UNION вызывает больше поисков вместо сканирований, потому что каждая операция должна удовлетворять определенному требованию селективности, чтобы претендовать на поиск. (Селективность — это уникальность конкретного фильтруемого столбца). OR происходит в одной операции, так что, когда селективность для каждого столбца объединяется и она превышает определенный процент, то сканирование считается более эффективным.

Поскольку UNION по умолчанию выполняет отдельную операцию для каждого оператора, селективность каждого столбца не объединяется, давая ему больше шансов на выполнение поиска. Теперь, поскольку UNION выполняет две операции, они должны сопоставить свои результирующие наборы, используя вышеописанную операцию конкатенации. Как правило, это не дорогостоящая операция.

Следует также отметить, что предложение OR работает так же, как оператор IN.

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

Источник Хабр

5

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. DJDUH 17 22.08.19 13:42 Сейчас в теме
OR происходит в одной операции, так что, когда селективность для каждого столбца объединяется и она превышает определенный процент, то сканирование считается более эффективным.


То я так и не понял "OR" - плохо или нет?
3. w.r. 468 22.08.19 13:48 Сейчас в теме
(1) вообще, по своему опыту могу сказать, что почти без разницы. С OR - один запрос, UNION - 2 запроса с объединением выборок. Поэтому в целом быстрее будет именно OR. Нужны специфические условия, чтобы с UNION юбыл план с index seek, а с OR - index scan и при том выборка была достаточно большой, чтобы UNION был значительно быстрее. Но, в любом случае, нужно смотреть планы конкретных запросов и их анализировать
9. Diversus 2016 22.08.19 14:40 Сейчас в теме
(3)
С OR - один запрос, UNION - 2 запроса с объединением выборок. Поэтому в целом быстрее будет именно OR.

В статье написано, что с OR один скан 121000 строк, а с UNION "Одна ветвь затрагивает 358 строк, а другая — 346 строк".
Так что надо использовать UNION, так будет быстрее в случае автора. Да и 1С дает точно такую же рекомендацию в системе стандартов и методик разработки (см скриншот).

Источник: Глава "Использование логического ИЛИ в условиях"
Прикрепленные файлы:
12. w.r. 468 22.08.19 16:39 Сейчас в теме
(9) так получилось, потому что в плане в первом случае index scan, во второму index seek
13. Diversus 2016 22.08.19 16:41 Сейчас в теме
(12) Я про то, что в (3) вы пишите:
вообще, по своему опыту могу сказать, что почти без разницы. С OR - один запрос, UNION - 2 запроса с объединением выборок. Поэтому в целом быстрее будет именно OR.

А это не верное утверждение. OR в целом будет не быстрее.
15. w.r. 468 22.08.19 17:01 Сейчас в теме
(13) не быстрее будет только в одном случае - если при OR план будет использовать index scan, а при Union - index seek во всех ветках. Если хотя бы в одной ветке Union будет использоваться index scan, то OR будет даже немного быстрее. Кстати, если записей в целом выбирается немного план выполнения OR тоже использует поиск по индексу. Тем более clustered index scan сам по себе довольно быстрый
16. Diversus 2016 22.08.19 17:06 Сейчас в теме
(15)
не быстрее будет только в одном случае - если при OR план будет использовать index scan, а при Union - index seek во всех ветках. Если хотя бы в одной ветке Union будет использоваться index scan, то OR будет даже немного быстрее. Кстати, если записей в целом выбирается немного план выполнения OR тоже использует поиск по индексу. Тем более clustered index scan сам по себе довольно быстрый


А как так может получиться, что при OR будет index scan, а при Union - index seek? Если учитывать, что условия по одним и тем же полям?
Мне кажется, то о чем вы говорите быть даже теоретически не может.
На сайте 1С классный пример на эту тему:
Через ИЛИ
ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

Через ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
 |ОБЪЕДИНИТЬ ВСЕ
 |ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"


Обратите внимание, речь идет в данном случае о том, что есть ОДИНАКОВОЕ поле для отбора.
22. w.r. 468 22.08.19 17:28 Сейчас в теме
(16) вы невнимательно читали статью. Селективность при OR объединяется, и когда она достигает большого значения, сервер вместо поиска по индексу (index seek) выбирает полное сканирование индекса (index scan). При Union селекивность не объединяется, так как по сути это несколько выборок, объединённых в общий набор записей
23. Diversus 2016 22.08.19 17:32 Сейчас в теме
(22)
вы невнимательно читали статью. Селективность при OR объединяется, и когда она достигает большого значения, сервер вместо поиска по индексу (index seek) выбирает полное сканирование индекса (index scan). При Union селекивность не объединяется, так как по сути это несколько выборок, объединённых в общий набор записей

Вы написали, что OR в целом будет быстрее чем UNION в подобных запросах. Я ответил, что нет и привел ссылку на сайт 1С и на систему стандартов и методик.
Так какой ответ верный по вашему мнению?
24. w.r. 468 22.08.19 17:36 Сейчас в теме
(23) проблема в том, что и при Union может быть большая селективность или в OR очень маленькая. И так чаще всего и происходит. Проверял это на реальных данных - анализировал планы запроса
25. Diversus 2016 22.08.19 17:38 Сейчас в теме
(24)
Проверял это на реальных данных - анализировал планы запроса

Вы так и не ответили на вопрос.
Рекомендации 1С использовать всегда UNION в подобных запросах ошибочна или нет?
27. w.r. 468 22.08.19 17:44 Сейчас в теме
(25) вы опять невнимательно читали свою же ссылку. Там написано, что ИЛИ не рекомендуется использовать в условиях соединения запросов, то есть при СОЕДИНЕНИЕ...ПО (JOIN...ON), а не в ГДЕ (WHERE)
28. Diversus 2016 22.08.19 17:50 Сейчас в теме
(27)
вы опять невнимательно читали свою же ссылку. Там написано, что ИЛИ не рекомендуется использовать в условиях соединения запросов, то есть при СОЕДИНЕНИЕ...ПО (JOIN...ON), а не в ГДЕ (WHERE)

В смысле не внимательно? Это вы не внимательны.
Цитата из статьи 1С:
Не следует использовать ИЛИ в секции ГДЕ запроса.

И статья про это же самое, даже примеры совпадающие на сайте 1С и в переводе.
29. w.r. 468 22.08.19 18:02 Сейчас в теме
(28) извиняюсь сейчас не с компьютера и статья открылась не полностью ваша. По поводу этой выдержки из вашей ссылки

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.


Во первых, переведённая статья совсем не о том. Посмотрите в планы запроса на скриншотах. Индексы там везде используются, только идёт или поиск по индексу или сканирование индекса. Во вторых, рекомендации возможно устарели. И так было лет 20 назад чтобы индексы не использовались при условии OR в запросах SQL Server
32. triviumfan 10 26.08.19 16:53 Сейчас в теме
(25) Не всегда, а лишь рекомендация. В большинстве случаев OR работает быстрее.
34. Ndochp 101 27.08.19 11:05 Сейчас в теме
(32) Аще-то или работает медленнее, но оно понятнее человекам. Так как большинство запросов для людей, то нужно писать ИЛИ, а в нагруженных местах ставить Объединить.
35. triviumfan 10 27.08.19 14:05 Сейчас в теме
(34) Спасибо за глупый комментарий "человеков-архитекторов".
18. herfis 283 22.08.19 17:11 Сейчас в теме
(15)
Тем более clustered index scan сам по себе довольно быстрый

Смотря с чем сравнивать. Если есть покрывающий обычный индекс, или объем извлекаемых данных не из индекса невелик, то по обычному индексу будет быстрее чем по кластерному.
6. user-z99999 21 22.08.19 14:11 Сейчас в теме
(1)
То я так и не понял "OR" - плохо или нет?

"OR" - плохо для индексов.
Поэтому лучше писать через UNION запросы.
11. herfis 283 22.08.19 14:52 Сейчас в теме
(1) OR - хорошо. Но UNION зачастую лучше, если нужна оптимизация.
14. w.r. 468 22.08.19 16:45 Сейчас в теме
(11) не всегда. Например реальный случай, если выборка одного из условий очень большая. Тогда план запроса одной из веток при Union все-равно будет построен с использованием index scan, то есть будет просканирован весь индекс. А это нивелирует вторую ветку с поиском по индексу (index seek). Можете проверить, если хотите
17. herfis 283 22.08.19 17:08 Сейчас в теме
(14)
не всегда.

Дык "зачастую" <> "всегда". "Зачастую" = "часто"
А еще чаще UNION рулит, когда избавляешься от OR в условии соединения.
26. w.r. 468 22.08.19 17:38 Сейчас в теме
(17) не согласен. По моим наблюдениям все наоборот. В условиях соединений - может быть, нужно смотреть опять же план запроса
2. Cерый 14 22.08.19 13:42 Сейчас в теме
Благодарю за статью, тем не менее, читабельность упала вдвое (вам ехать или шашечки?)
5. w.r. 468 22.08.19 13:53 Сейчас в теме
(2) в данном случае да. Но когда человек пишет 10 условий OR, тогда читабельность выше наверно у UNION. В таких случаях лучше использовать IN. Так как IN работает эквивалентно OR, при этом воспринимается намного удобнее
4. acanta 67 22.08.19 13:49 Сейчас в теме
В любом случае, если 1сник в запросе напишет
ИЛИ, то платформа 1с не превратит этот запрос в UNION.
33. w.r. 468 26.08.19 17:20 Сейчас в теме
(25) поэтому и говорю, что каждый конкретный случай нужно рассматривать и анализировать план запроса
7. Cерый 14 22.08.19 14:12 Сейчас в теме
До сих пор полагал, что СУБД для каждой записи вычислит WHERE, причем за один проход?
Судя по оригиналу, речь о Microsoft SQL Server ...
8. acanta 67 22.08.19 14:14 Сейчас в теме
А то, что любое СКД основано на условиях в отборах компоновки в списке, в иерархии или не в списке, не в иерархии, это тоже плохо для индексов или там используется какой-то другой механизм ?
10. herfis 283 22.08.19 14:51 Сейчас в теме
Спасибо за перевод (если свой). Хорошее объяснение, почему конкретно UNION как правило эффективней.
Так-то это давно известный способ оптимизации тяжелых запросов.
Yashazz; w.r.; Fox-trot; +3 Ответить
19. skv_79 165 22.08.19 17:14 Сейчас в теме
Как показывает практика использование OR лучше отказываться в пользу UNION. Даже если на первый взгляд разницы нет, если количество выборки будет увеличиваться, а со временем обычно так и происходит, то UNION начнет в скорости превосходить.
20. herfis 283 22.08.19 17:20 Сейчас в теме
(19) Такое... Я бы назвал это преждевременной оптимизацией. Читабельность и простоту кода уже ухудшили, а пригодится ли эта оптимизация - неизвестно. Ессно, когда известно заранее - тогда стоит сразу заложиться. Тут без вопросов.
21. w.r. 468 22.08.19 17:24 Сейчас в теме
(19) проверял на таблице в несколько миллионов строк OR vs Union. OR немного быстрее, так как в плане, из-за большого количества записей по отборам, и там и там использовалось полное сканирование индекса (index scan)
30. Yashazz 2859 22.08.19 18:22 Сейчас в теме
Методика давно известна, холивар давно наскучил, а вот за труды по переводу, если сами переводили, плюсую.
skv_79; w.r.; +2 Ответить
31. w.r. 468 22.08.19 18:31 Сейчас в теме
(30) тут и не может быть в принципе холивара. Холивары разводят как раз любители разных методик. Каждый отдельный запрос должен анализироваться, исходя из конкретной ситуации, и выдаваться рекомендации
Оставьте свое сообщение

См. также

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С 6

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

вчера в 09:48    302    EugeneSemyonov    3       

Набор скриптов для знакомства с SQL Server 205

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

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

30.09.2019    9192    YPermitin    10       

Мониторинг высоконагруженной системы 37

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    3526    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 72

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    7003    Sloth    11       

Руководство по SQL: Как лучше писать запросы (Часть 2) 33

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    3415    w.r.    1       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    2683    93    YPermitin    7       

Руководство по SQL: Как лучше писать запросы (Часть 1) 59

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    4703    w.r.    0       

Тюнинг производительности запросов в PostgreSQL 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    3157    w.r.    5       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    4205    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 38

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    3588    fhqhelp    0       

Настройка параметров PostgreSQL для оптимизации производительности 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    3220    w.r.    13       

Сравнительное тестирование работы PostgreSQL с большими страницами Linux 6

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    1682    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL 34

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    2290    w.r.    1       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 57

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

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

02.07.2019    6053    igordynets    119       

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE 7

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья является переводом оригинальной статьи Martin Kov&#225;&#269;ik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    3399    w.r.    2       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 66

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4152    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    4150    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 82

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    7390    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

13.06.2019    2662    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    7245    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4404    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    3784    zhichkin    15       

Как работают управляемые блокировки 121

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

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

29.04.2019    13187    comol    198       

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10628    kuzyara    12       

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) 37

Статья Системный администратор Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    7077    Aleksey.Bochkov    7       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 50

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8219    Elf1k    27       

Мониторим тяжелые запросы 28

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Мониторинг тяжелых запросов с сохранением результатов для истории.

22.04.2019    3958    ImHunter    8       

Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью 105

Статья Системный администратор Нет файла Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

22.04.2019    8127    YPermitin    47       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

18.04.2019    17912    ivanov660    40       

Самый быстрый шринк на Диком Западе 67

Статья Системный администратор Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Шринк (shrink) базы данных. Наглядное объяснение что это, зачем, когда применять и как это можно ускорить.

17.04.2019    7222    YPermitin    44       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8710    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    9850    w.r.    23       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    9869    YPermitin    38       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5881    dmitrydemenew    38       

Другой взгляд на APDEX и подсистему "Оценка производительности" 81

Статья Системный администратор Программист Нет файла 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание принципа работы подсистемы "Оценка производительности" из БСП, примеров использования, недостатках подсистемы, а также рассуждение о путях улучшения мониторинга производительности в системах 1С.

20.02.2019    9103    YPermitin    30       

Секционирование таблиц и индексов в мире 1С 158

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Говорим о секционировании таблиц и индексов для баз 1С. Способы применения, подводные камни и прочее.

10.02.2019    11032    YPermitin    53       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10789    user715208    38       

Инструкция: ускоряем tempdb переносом в RAM диск 90

Статья Системный администратор Нет файла Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.

29.01.2019    12914    MrWonder    79       

Управляемые блокировки по полям из свойства "Поля блокировки данных" 5

Статья Программист Нет файла v8::blocking Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

Добрый день, коллеги! Хотелось бы поделиться обнаруженной особенностью работы механизма управляемых блокировок, а именно блокировке по полям, указанным в свойстве «Поля блокировки данных».

24.01.2019    3930    mshumakov    1       

Элементарный способ ускорить вашу 1С в два-три раза 72

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Как ни странно, для меня оказалось открытием, что скорость работы 1С (всех процессорных задач) можно ускорить более чем в два раза элементарной настройкой Windows.

14.12.2018    28044    Aleksey81    43       

Создаем свои индексы для баз 1С. Со своей структурой и настройками! 124

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Поговорим о неплатформенных индексах для информационных баз 1С. Об особенностях их использования, целесообразности и подводных камнях.

05.11.2018    12100    YPermitin    31       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.

31.10.2018    18467    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10861    gallam99    31