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

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

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

sql query execution plan tuning antipatterns

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


Вот почему это руководство по SQL предоставит вам небольшой обзор некоторых шагов, которые вы можете пройти, чтобы оценить ваш запрос:
 

  • Во-первых, вы начнете с краткого обзора важности обучения SQL для работы в области науки о данных;
  • Далее вы сначала узнаете о том, как выполняется обработка и выполнение запросов SQL, чтобы понять важность создания качественных запросов. Конкретнее, вы увидите, что запрос анализируется, переписывается, оптимизируется и окончательно оценивается.
  • С учетом этого, вы не только перейдете к некоторым антипаттернам запросов, которые начинающие делают при написании запросов, но и узнаете больше об альтернативах и решениях этих возможных ошибок; Кроме того, вы узнаете больше о методическом подходе к запросам на основе набора.
  • Вы также увидите, что эти антипаттерны вытекают из проблем производительности и что, помимо «ручного» подхода к улучшению SQL-запросов, вы можете анализировать свои запросы также более структурированным, углубленным способом, используя некоторые другие инструменты, которые помогают увидеть план запроса; И,
  • Вы вкратце узнаете о time complexity и big O notation, для получения представления о сложности плана выполнения во времени перед выполнением запроса;
  • Вы кратко узнаете о том, как оптимизировать запрос.

 

Почему следует изучать SQL для работы с данными?


SQL далеко не мертв: это один из самых востребованных навыков, который вы находите в описаниях должностей из индустрии обработки и анализа данных, независимо от того, претендуете ли вы на аналитику данных, инженера данных, специалиста по данным или на любые другие роли. Это подтверждают 70% респондентов опроса О 'Рейли (O' Reilly Data Science Salary Survey) за 2016 год, которые указывают, что используют SQL в своем профессиональном контексте. Более того, в этом опросе SQL выделяется выше языков программирования R (57%) и Python (54%).

Вы получаете картину: SQL — это необходимый навык, когда вы работаете над получением работы в индустрии информатики.

Неплохо для языка, который был разработан в начале 1970-х, верно?

Но почему именно так часто используется? И почему он не умер, несмотря на то, что он существует так долго?

Есть несколько причин: одной из первых причин могло бы стать то, что компании в основном хранят данные в реляционных системах управления базами данных (RDBMS) или в реляционных системах управления потоками данных (RDSMS), и для доступа к этим данным нужен SQL. SQL — это lingua franca данных: он дает возможность взаимодействовать практически с любой базой данных или даже строить свою собственную локально!

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

Кроме того, можно с уверенностью сказать, что к SQL также присоединились более новые технологии, такие как Hive, интерфейс языка запросов, похожий на SQL, для запросов и управления большими наборами данных, или Spark SQL, который можно использовать для выполнения запросов SQL. Опять же, SQL, который вы там найдете, будет отличаться от стандарта, который вы могли бы узнать, но кривая обучения будет значительно проще.

Если вы хотите провести сравнение, рассматривайте его как обучение линейной алгебре: приложив все эти усилия в этот один предмет, вы знаете, что вы сможете использовать его, чтобы также освоить машинное обучение!

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

  • Его довольно легко освоить, даже для новичков. Кривая обучения довольно проста и постепенна, поэтому вы будете писать запросы в кратчайшие сроки.
  • Он следует принципу «учись один раз, используй везде», так что это отличное вложение твоего времени!
  • Это отличное дополнение к языкам программирования; В некоторых случаях написание запроса даже предпочтительнее написания кода, потому что он более производительный!
  • ...


Чего вы все еще ждете? :)
 

Обработка SQL и выполнение запросов


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

Сначала запрос разбирается в «дерево разбора» (parse tree); Запрос анализируется на предмет соответствия синтаксическим и семантическим требованиям. Синтаксический анализатор создает внутреннее представление входного запроса. Затем эти выходные данные передаются в механизм перезаписи.

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

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

Теперь вы, вероятно, задаетесь вопросом, что считается «хорошим планом запроса».

Как вы уже читали, качество стоимости плана играет немаловажную роль. Более конкретно, такие вещи, как количество дисковых операций ввода-вывода (disk I/Os), которые требуются для оценки плана, стоимость CPU плана и общее время отклика, которое может наблюдать клиент базы данных, и общее время выполнения, имеют важное значение. Вот тут-то и возникнет понятие сложности времени (time complexity). Подробнее об этом вы узнаете позже.

Затем выбранный план запроса выполняется, оценивается механизмом выполнения системы и возвращаются результаты запроса.
 


 

Написание SQL-запросов


Из предыдущего раздела, возможно, не стало ясно, что принцип Garbage In, Garbage Out (GIGO) естественным образом проявляется в процессе обработки и выполнения запроса: тот, кто формулирует запрос, также имеет ключи к производительности ваших запросов SQL. Если оптимизатор получит плохо сформулированный запрос, он сможет сделать только столько же…

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

Идеальная отправная точка — подумать о «местах» в ваших запросах, где могут возникнуть проблемы. И, в общем, есть четыре ключевых слова, в которых новички могут ожидать возникновения проблем с производительностью:
 

  • Условие WHERE;
  • Любые ключевые слова INNER JOIN или LEFT JOIN; А также,
  • Условие HAVING;


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

Тем не менее, вы также должны понимать, что производительность — это нечто, что должно стать значимым. Однако просто сказать, что эти предложения и ключевые слова плохи — это не то, что нужно, когда вы думаете о производительности SQL. Наличие предложения WHERE или HAVING в запросе не обязательно означает, что это плохой запрос…

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

1. Извлекате только необходимые данные


Умозаключение «чем больше данных, тем лучше» — не обязательно должна соблюдаться при написании SQL: вы рискуете не только запутаться, получив больше данных, чем вам действительно нужно, но и производительность может пострадать от того, что ваш запрос получает слишком много данных.

Вот почему, как правило, стоит обратить внимание на оператор SELECT, предложение DISTINCT и оператор LIKE.

 

Оператор SELECT


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

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

Помните, что коррелированный подзапрос является подзапросом, использующим значения из внешнего запроса. И обратите внимание, что, несмотря на то, что NULL может работать в этом контексте как «константа», это очень запутанно!

Рассмотрим следующий пример, чтобы понять, что подразумевается под использованием константы:

SELECT driverslicensenr, name                                   
 FROM Drivers                                             
 WHERE EXISTS                                             
        (SELECT '1'                                              
        FROM Fines                                               
        WHERE fines.driverslicensenr = drivers.driverslicensenr); 

Совет: полезно знать, что наличие коррелированного подзапроса не всегда является хорошей идеей. Вы всегда можете рассмотреть возможность избавиться от них, например, переписав их с помощью INNER JOIN:

SELECT driverslicensenr, name                                   
 FROM drivers                                             
 INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr; 

 

Операция DISTINCT


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

Оператор LIKE


При использовании оператора LIKE в запросе индекс не используется, если шаблон начинается с % или _. Это не позволит базе данных использовать индекс (если он существует). Конечно, с другой точки зрения, можно также утверждать, что этот тип запроса потенциально оставляет возможность для получения слишком большого количества записей, которые не обязательно удовлетворяют цели запроса.

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

 

2. Ограничьте свои результаты


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

Операторы TOP, LIMIT и ROWNUM


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

  SELECT TOP 3 * 
  FROM Drivers;


Обратите внимание, что вы можете дополнительно указать PERCENT, например, если вы измените первую строку запроса с помощью SELECT TOP 50 PERCENT *.

SELECT driverslicensenr, name                                   
 FROM Drivers 
 LIMIT 2;

Кроме того, можно добавить предложение ROWNUM, эквивалентное использованию LIMIT в запросе:

SELECT *
FROM Drivers
WHERE driverslicensenr = 123456 AND ROWNUM <= 3;

 

Преобразования типов данных


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

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

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

3. Не делайте запросы более сложными, чем они должны быть


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

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

Оператор OR


Когда вы используете оператор OR в своем запросе, скорее всего, вы не используете индекс.

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

Если вы не используете индексы, включенные в базу данных, выполнение вашего запроса неизбежно займет больше времени. Вот почему лучше всего искать альтернативы использованию оператора OR в вашем запросе;

Рассмотрим следующий запрос:

SELECT driverslicensenr, name
FROM Drivers
WHERE driverslicensenr = 123456
OR driverslicensenr = 678910
OR driverslicensenr = 345678;

Оператор можно заменить на:

Условие с IN; или

SELECT driverslicensenr, name
FROM Drivers
WHERE driverslicensenr IN (123456, 678910, 345678);

Две инструкции SELECT с UNION.

Совет: здесь вы должны быть осторожны, чтобы не использовать ненужную операцию UNION, потому что вы просматриваете одну и ту же таблицу несколько раз. В то же время вы должны понимать, что когда вы используете UNIONв своем запросе, время выполнения увеличивается. Альтернативы операции UNION: переформулировка запроса таким образом, чтобы все условия были помещены в одну инструкцию SELECT, или использование OUTER JOIN вместо UNION.

Совет: имейте также в виду, что, хотя OR — и другие операторы, которые будут упомянуты в следующих разделах — скорее всего, не используют индекс, поиск по индексу не всегда предпочтителен!

 

Оператор NOT


Когда ваш запрос содержит оператор NOT, вполне вероятно, что индекс не используется, как и с оператором OR. Это неизбежно замедлит ваш запрос. Если вы не знаете, что здесь подразумевается, рассмотрите следующий запрос:

SELECT driverslicensenr, name
FROM Drivers
WHERE NOT (year > 1980);

Этот запрос, безусловно, будет выполняться медленнее, чем вы, возможно, ожидаете, в основном потому, что он сформулирован гораздо сложнее, чем может быть: в таких случаях, как этот, лучше всего искать альтернативу. Рассмотрите возможность замены NOT операторами сравнения, такими как >, <> или !>; Приведенный выше пример действительно может быть переписан и выглядеть примерно так:

SELECT driverslicensenr, name
FROM Drivers
WHERE year <= 1980;


Это уже выглядит лучше, не так ли?
 

Оператор AND


Оператор AND — это другой оператор, который не использует индекс и который может замедлить запрос, если он используется чрезмерно сложным и неэффективным образом, как в следующем примере:

SELECT driverslicensenr, name
FROM Drivers
WHERE year >= 1960 AND year <= 1980;


Лучше переписать этот запрос, используя оператор BETWEEN:

SELECT driverslicensenr, name
FROM Drivers
WHERE year BETWEEN 1960 AND 1980;

 

Операторы ANY и ALL


Кроме того, операторы ANY и ALL — это те операторы, с которыми вам следует быть осторожным, поскольку, если включить их в свои запросы, индекс не будет использоваться. Здесь пригодятся альтернативные функции агрегирования, такие как MIN или MAX.

Совет: в тех случаях, когда вы используете предлагаемые альтернативы, вы должны знать о том, что все функции агрегации, такие как SUM, AVG, MIN, MAX над многими строками, могут привести к длительному запросу. В таких случаях можно попытаться минимизировать количество строк для обработки или предварительно вычислить эти значения. Вы еще раз видите, что важно знать о своей среде, своей цели запроса,… Когда вы принимаете решение о том, какой запрос использовать!
 

Изолируйте столбцы в условиях


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

SELECT driverslicensenr, name
FROM Drivers
WHERE year + 10 = 1980;


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

SELECT driverslicensenr, name
FROM Drivers
WHERE year = 1970;

 

4. Отсутствие грубой силы

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

Порядок таблиц в соединениях


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

Избыточные условия при соединениях


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

Условие HAVING


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

Если вы ищете альтернативу, попробуйте использовать условие WHERE.

Рассмотрим следующие запросы:

SELECT state, COUNT(*)
  FROM Drivers
 WHERE state IN ('GA', 'TX')
 GROUP BY state
 ORDER BY state
SELECT state, COUNT(*)
  FROM Drivers
 GROUP BY state
HAVING state IN ('GA', 'TX')
 ORDER BY state


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

Видно, что речь идет не об ограничении результирующего набора, а об ограничении промежуточного числа записей в запросе.

Следует отметить, что различие между этими двумя условиями заключается в том, что предложение WHERE вводит условие для отдельных строк, в то время как предложение HAVING вводит условие для агрегаций или результатов выбора, где один результат, такой как MIN, MAX, SUM,… был создан из нескольких строк.

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

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

Set-based против процедурных подходов к написанию запросов

 

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

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

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

Неудивительно, что этот подход часто называют «пошаговым» или «построчным» запросом.

Другой подход — подход, основанный на наборе, где вы просто указываете, что делать. Ваша роль состоит в указании условий или требований для результирующего набора, который вы хотите получить из запроса. То, как ваши данные извлекаются, вы оставляете внутренним механизмам, которые определяют реализацию запроса: вы позволяете ядру базы данных определять лучшие алгоритмы или логику обработки для выполнения вашего запроса.

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

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

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

В следующей части будут расмотрены план и оптимизация запросов (Часть 2)

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. chg 24.03.20 09:08 Сейчас в теме
Подпишусь пожалуй, полезно, благодарю)
2. MishaD 14 24.03.20 11:28 Сейчас в теме
В 1с те же рекомендации. Хотя не помню, чтобы не рекомендовалось использовать "И". Вместо "Объединить" использовать полное соединение ? Всегда считал, что полное соединение медленнее, хотя в основном пользуюсь "Объединить ВСЕ". Ну и рекомендация про "HAVING state IN ('GA', 'TX')" - это нечто. Как бы Having всё-таки используют с агрегатными функциями. То есть "Имеющие Сумма(Сумма) >1000".
Fox-trot; +1 Ответить
3. w.r. 586 24.03.20 20:26 Сейчас в теме
(2)
В 1с те же рекомендации. Хотя не помню, чтобы не рекомендовалось использовать "И". Вместо "Объединить" использовать полное соединение ? Всегда считал, что полное соединение медленнее, хотя в основном пользуюсь "Объединить ВСЕ".

Объединить Все(UNION ALL) не ищет дубликаты в результирующей выборке. А просто Объединить(UNION) - ищет, даже если их там нет. И на это тратятся ресурсы
Ну и рекомендация про "HAVING state IN ('GA', 'TX')" - это нечто. Как бы Having всё-таки используют с агрегатными функциями. То есть "Имеющие Сумма(Сумма) >1000".

Агрегатная функция там Count(*), то есть Количество(*)

Не обязательно агрегатная функция должна быть в условии запроса

p.s. "Имеющие Сумма(Сумма) >1000" - функция в условиях запроса - это дичь, которая кладет на лопатки sql сервер, никогда так не делайте
13. buganov 156 27.03.20 08:00 Сейчас в теме
(3)p.s. "Имеющие Сумма(Сумма) >1000" - функция в условиях запроса - это дичь, которая кладет на лопатки sql сервер, никогда так не делайте"

А можно пруфы? Или хотя бы грамотное описание что делает тот же MSSQL когда видит оператор HAVING?
4. buganov 156 25.03.20 07:49 Сейчас в теме
Автор, а Вы сами проверяли "проблемные места"? Вот, например, я, как человек недоверчивый, проверил.

Оператор OR

Когда вы используете оператор OR в своем запросе, скорее всего, вы не используете индекс.


Запрос


Запрос SQL


План запроса


Как видно, что ИЛИ Хорошо попадает в индекс. Миф разрушен.


При использовании оператора LIKE в запросе индекс не используется, если шаблон начинается с % или _. Это не позволит базе данных использовать индекс (если он существует).


Запрос 1С


Запрос SQL и План


Миф разрушен.

Оператор AND

Оператор AND — это другой оператор, который не использует индекс и который может замедлить запрос, если он используется чрезмерно сложным и неэффективным образом, как в следующем примере


Запрос 1С


Запрос SQL


План в присоединенном файле.
Миф разрушен.
Прикрепленные файлы:
6. ai1804@mail.ru 25.03.20 08:20 Сейчас в теме
(4)
Clustered Index Seek


не все так просто..

..Оператор OR.. - оптимизатор ms sql становится все умнее, но сложные случаи по-прежнему может и не осилить.. пользую ms sql 2017, и по-прежнему попадаются примеры, когда приходится что-то делать с or (и даже менять на union)

..использовании оператора LIKE.. ГДЕ Измерение1 ПОДОБНО "_А%" - ваш Clustered Index Seek сильно напоминает частичный скан, правда? а если поменять на ГДЕ Измерение1 ПОДОБНО "%А%", то может оказаться, что количество чтений со сканом осталось примерно тем же, что и с поиском - и какая тогда разница? like с % и _ плохая идея, и это увы не миф..

а вот на "не использующий индекс" WHERE year >= 1960 AND year <= 1980 и правда смотрю с удивлением.. может речь про составные индексы, на первом месте в которых дата?


подытожил бы так: "не верь слепо шаблонам и правилам, в них есть зерно, но стоит проверять реальные запросы планами исполнения и статистикой"
7. buganov 156 25.03.20 09:27 Сейчас в теме
(6) возможно, автор имел ввиду случай, когда интервальный поиск по первому полю ключа. Но и в таком случае
ГДЕ Измерение1 Между &Дата1 И &Дата2 И Измерение2 = &П приведет к тому, что по Измерению1 будет поиск в индексе, а &П уйдет в предикаты сканирования того, что выдаст поиск.

по поводу частичного сканирования да, тут есть нюанс и бездумно лайкать не хорошо.
5. buganov 156 25.03.20 07:57 Сейчас в теме
Осмелюсь дать совет всем, особенно тем, кто только начал осваивать оптимизацию и СУБД. Статьи на инфостарте ложь, если в них нет пруфов, планов запроса или комментариев по нюансам. Сухие факты без доказательств чаще всего являются признаком того, что автор сам не проверил то, что написал, бумага то все стерпит. В данном случае автор трижды создал тему для того, чтобы молодой боец начитавшись его с пеной у рта доказывал, как плохо лайкать в запросе, использовать или и т.п. Такие же темы рождают пищу холиварам по tempdb.

И самый главный совет: ПРОВЕРЯЙТЕ ВСЕ, ЧТО ПИШУТ В ИНТЕРНЕТЕ
8. w.r. 586 25.03.20 18:17 Сейчас в теме
(5)
ются признаком того, что автор сам не проверил то, что написал, бумага то все стерпит. В данном случае автор трижды создал тему для того, чтобы молодой боец начитавшись его с пеной у рта доказывал, как плохо лайкать в запросе, использовать или и т.п. Такие же темы рождают пищу холиварам по tempdb.

Не понимаешь разницы между частными случаями и общими рекомендациями
9. buganov 156 25.03.20 18:44 Сейчас в теме
(8)случаи, которые я написал работают в 99% случаев. Проверь ,) И не пость больше ересь, джуны могут подхватить и эту дурь потом не выбить, начитаются всякого в этих ваших интырнетах
10. w.r. 586 26.03.20 20:20 Сейчас в теме
(9) то есть ты от меня требуешь всеохватывающих тестов, а тебе я должен верить и твоим придуманным 99% ) Очень логично

Не проще ли начать себя?

Вот тебе субд и версии для тестирования, поддерживаемые 1с. Хотя бы для Архитектура x86-64

https://v8.1c.ru/tekhnologii/sistemnye-trebovaniya-1s-predpriyatiya-8/
12. buganov 156 27.03.20 07:50 Сейчас в теме
(10) Это не придуманные 99%, а выявленные опытным путем. К тому же, я в своем комментарии указал на текст запроса, текст запроса в MSSQL, план запроса. Любой специалист, который понимает в этом увидит, насколько ты сейчас не прав. Включил истерику из-за того, что твою копипасту решили покритиковать, что намекает на то, что ты только в начале своей карьеры. Не переживай, с опытом это пройдет.
14. w.r. 586 28.03.20 02:40 Сейчас в теме
(12) тесты проводились на какой версии платформы 1С и какой версии MS SQL. Давай начнём с этого. Тебе уже выше писали, что поведение зависит от версии СУБД. А ещё сами СУБД разные и у каждой свой движок с собственным анализатором запросов. Но как-то до тебя не дошло

p.s. Бомбит у тебя сильно и это хорошо, может чему-то научишься )
15. buganov 156 28.03.20 16:38 Сейчас в теме
(14) мда, ты, конечно, молодец, что перепечатываешь сюда разные статейки. Но без проверки это всего лишь бездумная копипаста.
П.С. Мне у тебя учиться нечему, разве что плохому тону, невежеству и хамству ,)
16. buganov 156 28.03.20 16:45 Сейчас в теме
(14)и да, в твоей "статье" не указаны версии СУБД, даже вендора. Я тебе показал на платформах 8.2, 8.3 и СУБД MSSQL 2017 и 2019.
Твоя очередь. Спорим, ты не тестировал свою копипасту?
18. w.r. 586 29.03.20 22:18 Сейчас в теме
(16) 8.2 и 8.3 вообще ни о чем не говорит. Огромная разница между 8.3.3 и 8.3.16. Версии MS SQL примерно туда же. Еще распространены достаточно широко версии MS SQL 2012 и 2008. Я не говорю уже про Postgres
19. buganov 156 30.03.20 07:20 Сейчас в теме
(18) Но ты не проверил ни одну из версий. Ни 8.3.3, ни 8.3.16. Наш разговор зашел в тупик, и из твоих статей я вижу, что от себя ты добавляешь только "Предлагаю вашему вниманию перевод статьи" + Имя автора. При этом, не удосуживаешься даже проверить, что там написано.
П.С. Читай взрослых авторов, изучай поведение платформы при highload, запишись на курсы
На этом и закончим. Если у тебя хватит мозгов, ты мне не ответишь
11. user1371486 26.03.20 23:07 Сейчас в теме
Статья уровня "блондинко".
Но всегда найдется куча экспердов, защищающих любого автора, даже самое днище.
Если же знать, что на страничке первоисточника англицкими по белому написано:
Karlijn Willems on Medium. Data Science Journalist

то все становится понятно
17. Fox-trot 118 28.03.20 17:20 Сейчас в теме
предлагаю не париться и поверить, что анализатор все сделает как ему надо
Оставьте свое сообщение

См. также

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

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

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

26.04.2019    11721    Aleksey.Bochkov    7    

Контекст всегда важен. История проблем производительности

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

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

сегодня в 12:40    698    YPermitin    8    

Анализ проблем производительности по динамике мониторинга RAS 1C

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

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

07.10.2020    3050    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3699    Nykyanen    16    

Опыт миграции из собственного датацентра в облако AWS Промо

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

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11629    Aleksey.Bochkov    9    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    8283    YPermitin    30    

SQL для 1С: пишем правильно, красиво, сложно

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

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    9991    dmurk    30    

Нестандартные блокировки при работе с OLAP-нагрузкой

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

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2000    Филин    7    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

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

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    30075    MrWonder    42    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    2873    ivanov660    12    

Выбор процессора для 1С: конец споров или начало?

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

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    12474    starik-2005    232    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    7731    DataReducer    22    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

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

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    61651    Sergey.Noskov    119    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

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

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    5848    SergeyN    2    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

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

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    4244    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2998    vasilev2015    7    

Долго открывается конфигуратор Промо

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

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    41256    Gilev.Vyacheslav    1    

Фреймворк "Мониторинг производительности". Руководство пользователя

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

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    3637    ivanov660    3    

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    12181    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13419    informa1555    31    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

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

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

15.03.2015    40738    gallam99    17    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    3202    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    5332    vasilev2015    26    

Многопоточность

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

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7407    kaliuzhnyi    43    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

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

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67605    yuraos    112    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

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

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    5577    ildarovich    7    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    55322    Антон Ширяев    117    

Делаем быстрее POSTGRESQL COUNT (*)

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

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2892    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    4594    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    10148    Evil Beaver    13    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

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

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54906    Gilev.Vyacheslav    46    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

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

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    11681    a.doroshkevich    20    

Оптимизатор запросов. Вторая часть

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

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

23.01.2020    6546    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

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

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    8123    Kaval88    26    

Параллельные вычисления в 1С 8 Промо

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

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30171    gallam99    19    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    6103    nixel    22    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    12059    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

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

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7780    user826155    11    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

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

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42800    madmpro    32    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    18227    YPermitin    28    

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

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

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

30.09.2019    22556    YPermitin    15    

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

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

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

13.09.2019    9196    Repich    5    

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

Администрирование данных 1С Zabbix v8 Бесплатно (free)

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

10.09.2019    18967    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

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

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    8721    2tvad    17    

Подбор оборудования для информационных систем на платформе 1С

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

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    9264    jf2000    8    

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

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

Предлагаю вашему вниманию продолжение перевода статьи 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    7668    w.r.    2    

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

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

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

22.08.2019    4092    w.r.    35    

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

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

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

31.07.2019    8378    w.r.    5    

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

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

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

19.07.2019    9079    Филин    12