Microsoft SQL Server

Microsoft SQL Server — система управления реляционными базами данных (СУРБД).

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

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

Сам MS SQL рождался также постепенно. Сначала при активнейшем участии компаний Sybase, Ashton-Tate и IBM . В 1988 году появилась первая версия этого продукта под операционной системой OS/2.

источник slideplayer.com/slide/17535738/

Простой, но впечатляющий слайд с просторов интернета

В 1993 году согласно опубликованным результатам тестирования по показателям стоимость/производительность SQL Server оказался самым эффективным сервером из присутствовавших на том момент. Т.е., конечно, были серверы более производительные, но ПО+аппаратное обеспечение обходились заказчикам непропорционально дороже. Этот факт внес напряжение в совместную разработку Microsoft & Sybase, которое логично завершилось объявлением о прекращении совместной разработки SQL Server в 1994 году к неудовольствию клиентов этого продукта.

Чтобы не потерять клиентов Microsoft совершила подвиг, мотивировав работать свою группу разработчиков чуть ли не круглосуточно. MS SQL Server 6.5 был успешно выпущен в 1995 году.

На текущий момент (конец 2018 года) наибольшее количество наработок сделано мной на – MS SQL 2012.

Напишу здесь, какие техники оптимизации запросов БД я применял для решения бизнес задач.

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

Способы оптимизации запросов к БД

  • Построение правильной структуры данных: структура должна соответствовать бизнес задачам приложения, с точки зрения реляционной парадигмы, быть близко к 3НФ, связка таблиц по суррогатным ключам и т.д.
  • Семантическая оптимизация запросов.
    • раскрытие представлений (отказ от view и возврат к таблицам, если в этом есть смысл),
    • преобразование подзапросов в соединения,
    • спуск предикатов (селекция по возможности должна выполняться до соединения)
    • и т.д.
  • Правильное индексирование полей в таблицах.
  • Кластеризация взаимосвязанных таблиц
  • Партиционирование/секционирование/фрагментация/сегментирование таблиц и индексов
  • Сегментирование таблиц
  • Кластеризация серверов БД (когда запись делается на мастере, а чтение на репликах)
  • А был еще такой случай. Пользователи стали жаловаться, что отчеты (причем все, в их департаменте) резко начали тормозить. Поскольку организация большая, жалобы пользователей выстояли в очереди несколько дней. Вторая линия поддержки сделать ничего не смогла. Что интересно, и третья линия поддержки сделать ничего не смогла. Пришлось использовать организацонно-аналитический подход. Выяснилось, что поддержка инфраструктуры, как-то не особенно афишируя, перенесла СХД на более производительную твердотельную платформу. Казалось бы, отчеты должны работать еще быстрее. Но факты говорили об обратном. Пришлось заставить ребят протестировать все оборудование, это было, надо сказать не просто, во первых, они этого делать не хотели, а во-вторых, для тестирования им пришлось обратиться к вендору, который тоже как-то реагировал не быстро. И выяснилось, что коннектор к СХД – с брачком, таким брачком, который удалось заметить только после проведения комплексного тестирования оборудования. В итоге, после месяца мучений, ругани и эскалаций, поменяли, грубо говоря, шнурок, и все взлетело с реактивной скоростью.

Из наиболее ярких успехов в оптимизации запросов: в одной компании, только прибегая к семантической оптимизации, удавалось сократить время генерации отчета с 14 часов до 30 минут.

Фактически я только менял текст хранимых процедур. Не могу сказать, что все было написано плохо. В процессе оптимизации наткнулся на фрагмент кода, рассчитывавшего себестоимость по FIFO. Сначала не понял, как это работает. Разбирался с относительно небольшим скриптом не меньше часа. А когда понял, был чрезвычайно восхищен остроумием этого алгоритма. Притом, что в целом код формирования отчета был изначально не оптимален, расчет FIFO был написан талантливым программистом.