Длительность кеша для ad-ho c оператора в SQL Server? - PullRequest
0 голосов
/ 10 апреля 2020

Я пытаюсь изучить оптимизацию по adho c запросам на множественном освещении, базу данных можно найти по этой ссылке

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

select m.* from member as m where m.member_no=1
select m.* from member as m where m.member_no=3
select m.* from member as m where m.member_no=5

И затем проверьте кэш плана с помощью:

exec  dbo.QuickCheckOnCache '%member_no%' 

Я получаю этот результат:

enter image description here

После этого, когда я выполняю, например, этот запрос:

select m.* from member as m where m.member_no=34567

, я получаю новый кэш плана:

enter image description here

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

Так это вопрос версии SQL Server? Или что я делаю не так?

Примечание : это определение хранимой процедуры QuickCheckOnCache :

 SET ANSI_NULLS ON
 GO
 SET QUOTED_IDENTIFIER ON
 GO
 ALTER PROCEDURE [dbo].[QuickCheckOnCache]
 (
    @StringToFind   NVARCHAR (4000)
  )
 AS
 SET NOCOUNT ON;

 SELECT [st].[text]
  , [qs].[execution_count]
  , [qs].*
  , [p].* 
 FROM [sys].[dm_exec_query_stats] AS [qs] 
  CROSS APPLY [sys].[dm_exec_sql_text] 
      ([qs].[sql_handle]) AS [st]
  CROSS APPLY [sys].[dm_exec_query_plan] 
      ([qs].[plan_handle]) AS [p]
  WHERE [st].[text] LIKE @StringToFind
  ORDER BY 1, [qs].[execution_count] DESC;

Ответы [ 2 ]

1 голос
/ 10 апреля 2020

SQL Сервер выбирает тип параметра на основе литерального значения с автоматическими параметризованными запросами.

Как видно из первого кэшированного текста плана, для трех запросов был выбран тип параметра tinyint из-за небольших целочисленных значений (1,2,3). Для большего значения требовался больший int тип данных (34567). Это привело к созданию другого кэшированного плана.

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

0 голосов
/ 10 апреля 2020

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

75% видимой целевой памяти от 0 до 4 ГБ + 10% видимой целевой памяти от 4 ГБ до 64 ГБ + 25% видимой целевой памяти> 64 ГБ
plan cache size limit

По умолчанию SQL Сервер может динамически изменять свои требования к памяти, основываясь на доступных системных ресурсах, мы можем установить его минимальное значение и максимальное значение вручную, но для устройства с плохими ресурсами оперативной памяти, как у меня (4 ГБ), которое может вызвать проблемы:

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

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