La chair de la question: les procédures stockées réelles sont-elles le seul mécanisme qui implémente la mise en cache de la table temporaire ou les procédures stockées système telles que sp_executeSQL
/ en sp_execute
tirent-elles également avantage?
Je ne suis pas un DBA, veuillez donc utiliser de petits mots. Notre application envoie des instructions préparées que, à partir du profileur, je vois exécuter tout SQL à travers sp_prepexec
lequel est une procédure système pour l'exécution sp_prepare
et sp_execute
. Ce que j'essaie de faire est de savoir si je profite de la mise en cache de la table temporaire.
J'ai utilisé ce guide avec object_id () pour examiner le comportement
https://sqlkiwi.blogspot.com/2012/08/temporary-tables-in-stored-procedures.html
Ensuite, le point # 3 de ce billet de blog suggère qu'EXEC ne peut pas utiliser la mise en cache de la table temporaire, mais ignore si sp_executeSQL peut: http://blogs.msdn.com/b/turgays/archive/2013/09/18/exec-vs- sp-executesql.aspx
Dans ma requête envoyée via le client, j'ai créé une simple table temporaire.
DECLARE @foo int; -- set by JDBC, unused but required to force a prepared statement
SELECT 1 AS id
INTO #tmp
SELECT OBJECT_ID('tempdb..#tmp');
Dans profiler, je peux voir:
declare @p1 int
set @p1=NULL
exec sp_prepexec @p1 output,N'@P1 int',N'declare @foo INT = @P1
SELECT 1 as id
into #tmp
select Object_id(''tempdb..#tmp'');
DROP TABLE #tmp;',1
select @p1
J'obtiens également un cachehit de cela. Cependant, l'id_objet de la table temporaire semble changer sur moi, ce qui n'est pas le comportement que je verrais si cette table temporaire a été créée dans une véritable procédure stockée. Cependant, lorsque j'exécute ce même code sp_executeSQL
, je constate également que l'objet_id de la table temporaire a changé. Cela m'amène à croire que seules les procédures stockées créées par l'utilisateur "réelles" tirent parti de la mise en cache de la table temporaire.