EXEC sys.sp_configure N'max server memory (MB)', N'2147483646'
GO
RECONFIGURE WITH OVERRIDE
GO

为服务器内存指定什么值并不重要，只要它与当前值不同即可。

顺便说一下，导致加速的不是查询缓存，而是数据缓存。

这里有一些很好的解释。看看吧。

http://www.mssqltips.com/tip.asp?tip=1360

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO

从链接的文章:

If all of the performance testing is conducted in SQL Server the best approach may be to issue a CHECKPOINT and then issue the DBCC DROPCLEANBUFFERS command. Although the CHECKPOINT process is an automatic internal system process in SQL Server and occurs on a regular basis, it is important to issue this command to write all of the dirty pages for the current database to disk and clean the buffers. Then the DBCC DROPCLEANBUFFERS command can be executed to remove all buffers from the buffer pool.

虽然这个问题有点老了，但这可能还是有帮助的。我遇到了类似的问题，使用下面的选项帮助了我。不确定这是否是一个永久的解决方案，但它现在正在修复它。

OPTION (OPTIMIZE FOR UNKNOWN)

那么你的问题将是这样的

select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)

注意DBCC DROPCLEANBUFFERS;或DBCC FREEPROCCACHE;在SQL Azure / SQL数据仓库中支持。

然而，如果你需要在SQL Azure中重置计划缓存，你可以修改查询中的一个表(例如，只添加然后删除一个列)，这将有从缓存中删除计划的副作用。

我个人这样做是为了测试查询性能，而不必处理缓存的计划。

更多关于SQL Azure过程缓存的详细信息请点击这里

八种不同的方法来清除计划缓存

1. 从整个实例的计划缓存中删除所有元素

DBCC FREEPROCCACHE;

使用此选项可仔细清除计划缓存。例如，释放计划缓存会导致重新编译存储过程，而不是从缓存中重用存储过程。这可能会导致查询性能突然、暂时下降。

2. 刷新整个实例的计划缓存并删除常规完成消息

"DBCC执行完成。如果DBCC打印错误消息，请与系统管理员联系。”

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

3.刷新整个实例的临时和准备好的计划缓存

DBCC FREESYSTEMCACHE ('SQL Plans');

4. 为一个资源池刷新临时和准备好的计划缓存

DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');

5. 刷新一个资源池的整个计划缓存

DBCC FREEPROCCACHE ('LimitedIOPool');

6. 从一个数据库的计划缓存中删除所有元素(在SQL Azure中无效)

-- Get DBID from one database name first
DECLARE @intDBID INT;
SET @intDBID = (SELECT [dbid] 
                FROM master.dbo.sysdatabases 
                WHERE name = N'AdventureWorks2014');

DBCC FLUSHPROCINDB (@intDBID);

7. 清除当前数据库的计划缓存

USE AdventureWorks2014;
GO
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

8. 从缓存中删除一个查询计划

USE AdventureWorks2014;
GO

-- Run a stored procedure or query
EXEC dbo.uspGetEmployeeManagers 9;

-- Find the plan handle for that query 
-- OPTION (RECOMPILE) keeps this query from going into the plan cache
SELECT cp.plan_handle, cp.objtype, cp.usecounts, 
DB_NAME(st.dbid) AS [DatabaseName]
FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st 
WHERE OBJECT_NAME (st.objectid)
LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE); 

-- Remove the specific query plan from the cache using the plan handle from the above query 
DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);
 

来源1 2 3