Comments 12
Спасибо, однозначно в закладки!
Рад, что Вам понравилось. Если народу будет интересно, потом планировал написать пост как можно с помощью запросов к системным представлениям определять узкие места в конфигурации сервера и автоматизировать проверку с помощью tSQLt.
Спасибо за пост! Тоже сохраню в закладки!
Пост безумно интересный, спасибо.
Но уж очень режет глаз
Но уж очень режет глаз
SQL Serverвместо MS SQL Server. Задевает этот нелепый (и непроизвольный) снобизм, как будто бы других серверов, кроме MS, на свете нет!
Спасибо за статью. Нашел у себя пару проблем. Статью однозначно в закладки.
Спасибо и Вам что прочитали. Можно вопрос… а в чем нашли проблемы? Не во всех ситуациях запросы будут возвращать 100% адекватную информацию. Например, MissingIndexGroup секция строится на основе предположений оптимизатора и не всегда предлагает самый оптимальный индекс. Очень рекомендую взглянуть на DEFAULT TRACE.
Индексы неиспользуемые, занимающие значительное место. Кто и зачем их добавил — загадка.
П. С. Вы в Днепре докладов не будете делать? Майский в Киеве про XML был очень полезным.
П. С. Вы в Днепре докладов не будете делать? Майский в Киеве про XML был очень полезным.
С индексами… там не все так просто. Информация о том нужны они или нет строится на основании sys.dm_db_index_usage_stats. Если индексу делают REBUILD (это пофиксили в последних SP для 2014 + уже изначально в 2016 версии) или на базе включено AUTO_CLOSE, то значения сбрасываются в ноль и может казаться что индекс не используются. Поэтому аккуратнее тут нужно себя вести.
Например, можно заглянуть в кеш планов и оттуда узнать какие индексы используются:
Относительно Днепра… да, буду. Два доклада планирую на SQL Saturday Dnepr. Приезжайте 26 ноября — мероприятие обещает быть очень интересным.
Например, можно заглянуть в кеш планов и оттуда узнать какие индексы используются:
SELECT *
FROM (
SELECT DISTINCT Sch = t.c.value('@Schema', 'SYSNAME')
, Obj = t.c.value('@Table', 'SYSNAME')
, Ind = t.c.value('@Index', 'SYSNAME')
FROM sys.dm_exec_query_stats q
CROSS APPLY sys.dm_exec_query_plan(q.plan_handle) p
CROSS APPLY p.query_plan.nodes('//*:Object') t(c)
WHERE t.c.exist('@Index') = 1
AND p.dbid = DB_ID()
) t
WHERE t.Sch != '[sys]'
Sch Obj Ind
--------------------- -------------------- -------------------------------------
[HumanResources] [JobCandidate] [PK_JobCandidate_JobCandidateID]
[Person] [Address] [PK_Address_AddressID]
[Production] [Document] [PK_Document_DocumentNode]
[Production] [ProductReview] [PK_ProductReview_ProductReviewID]
Относительно Днепра… да, буду. Два доклада планирую на SQL Saturday Dnepr. Приезжайте 26 ноября — мероприятие обещает быть очень интересным.
Хм, но многие не то что процедуры вручную не пишут, но и запросы не пишут и не следят за индексами.
Они надеются на фреймворки :)
Аргументируют это тем, что бизнесу дешевле оплатить сервера, чем работу программиста. :)
П.С.
А по mysql можете написать? :)
Они надеются на фреймворки :)
Аргументируют это тем, что бизнесу дешевле оплатить сервера, чем работу программиста. :)
П.С.
А по mysql можете написать? :)
Что сказать… полностью поддерживаю Вашу точку зрения. На текущем проекте использовался Entity Framework, который в отдельных случаях такую ересь пытался выполнить на сервере. Неявное преобразование типов, Index Scan вместо Index Seek при выборе единичного значения, и прочие радости жизни… Вычистили все проблемные места, но осадок от использования подхода Code First остался при использовании на больших объемах данных.
Про MySQL не планировал, потому что мало с ним работал. Однако, в планах сделать еще большой пост про типичные ошибки при написании запросов на T-SQL.
Про MySQL не планировал, потому что мало с ним работал. Однако, в планах сделать еще большой пост про типичные ошибки при написании запросов на T-SQL.
Sign up to leave a comment.
Тестирование производительности баз данных при помощи tSQLt и SQLQueryStress