我知道使用 LIKE '%ABC%' 查询不会使用索引，并且几乎没有什么可以更改查询来改进这一点，但是如何才能更快地执行？在此阶段，我们无法将查询更改为使用全文索引。

一些背景...

我们将 Azure VM（注意：不是 Azure SQL，而是运行在 Windows 2012 上的 SQL Server）中的系统作为第二个位置以提供额外的弹性（离线备份），并使用基本服务器规范“构建”了一个 SQL 服务器。在我们的旧平台上执行 LIKE 查询需要 2 秒，而在这个 Azure 平台上需要 10 秒。

这显然是服务器规范的限制，但是我可以做些什么来改进呢？

我可以在查询运行期间看到 CPU 峰值，因此“更快”的 azure cpu 似乎会有所帮助，但要知道这些数字也可能具有误导性！

所以我的问题是，我需要专注于改进 CPU，还是不止于此？

有问题的数据库在磁盘上只有 300mb，被查询的表有大约 160k 行，所以它无论如何都不大。

请让我知道我是否在这里吠错了树，或者我是否需要先检查其他任何东西？

SQL 服务器是带有 SQL Server 2014 Std 的 Windows 2012 R2，并且是按照 Azure SQL 性能指南（即专用条带驱动器上的数据）构建的。

编辑
根据要求，这是我正在测试的查询：

SELECT Name
FROM Users
WHERE Name like '%ABC%'

就是这样。这里没有什么复杂的，只是从一个小数据库中检索数据！

顺便说一句，此查询需要 10 秒才能运行，而添加子句 'AND Description like '%ABC%' 将时间减少到 6s？

编辑 2

好的，在评论中的反馈之后有更多信息......

我已经关注了这个页面的信息：http : //www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/

我已经运行了显示的查询，这些是显示的结果： …

我有一个 proc，循环遍历数据库（插入在修复数据库中......选择使用循环），进行插入（将隐藏名称以确保安全）：

insert into Main_Database..Table(16 Fields)  
    select ( there are 16 fields here, DateDiff(s, DtTrabalhoInF8, DtTrabalhoFi) as TempoSegundos  
     from  [Database_name].dbo.View as T1 with (nolock)  
     where DtTrabalho >= '2015/06/06' and   
     not exists(select 1 from PainelControle.dbo.tblLogProjetos T2 Where t2.BancoDados collate SQL_Latin1_General_CP1_CI_AS = t1.BancoDados collate SQL_Latin1_General_CP1_CI_AS and t2.codlog = t1.codlog)

问题是：

如果我运行它，它会在 1 秒内运行：

insert into Main_Database..Table(16 Fields)  
        select ( there are 16 fields here, DateDiff(s, DtTrabalhoInF8, DtTrabalhoFi) as TempoSegundos  
         from  [Database_name].dbo.View as T1 with (nolock)  
         where DtTrabalho >= '2015/06/06'

问题在这里：

and   
         not …

我有这个存储过程..当我告诉开发人员不推荐使用 Recompile 选项时，他们回答说“这是因为可以使用许多不同的参数调用这个 SP，我们希望优化器获取一个新计划每次调用（不理想，但与使用旧的缓存计划相比，这是一次尝试让它运行得更可靠、速度更快）”

他们说的对吗？有什么方法可以不用重新编译就可以做到这一点

   create PROCEDURE [dbo].[VERIFIER_QUEUE]
   @cas_name varchar(20) = NULL,
   @instance_name varchar(50) = NULL,
   @verifier_id int = NULL,
   @applicant_type VARCHAR(20) = NULL

    WITH RECOMPILE     
    AS

   BEGIN 
SET NOCOUNT ON

DECLARE @cas_name_x varchar(20)
DECLARE @instance_name_x varchar(50)
DECLARE @verifier_id_x int
DECLARE @InstanceId INT
...............

我有一个 PostgreSQL 数据库（9.3.6 版），其中包含大量orders. 随着订单被处理、scan_events触发和存储，每个订单有多个事件。扫描事件有一个布尔值，指示在该事件之后是否可以将订单标记为已完成，但complete可以发生多次扫描。然而，一般来说，我真正关心的唯一扫描是第一次扫描和第一次completed扫描。

我想知道在创建后x天内收到第一次扫描的给定创建日期的订单百分比的平均值和标准差。

架构

CREATE TABLE orders (
    id character varying(40) NOT NULL,
    date_created timestamp with time zone NOT NULL
);

ALTER TABLE ONLY orders
    ADD CONSTRAINT orders_pkey PRIMARY KEY (id);

CREATE TABLE scan_events (
    id character varying(100) NOT NULL,
    order_id character varying(40) NOT NULL,
    "time" timestamp with time zone NOT NULL
);

CREATE INDEX scan_events_order_id_idx ON scan_events USING btree (order_id);

所需的计算

对于days_elapsed1 到 14 …

我有一个关于查询分解和本地化的问题，如下所示：

加入 3 个表时（这里EMP,ASG和PROJ）有什么特定的顺序，什么时候加入哪个表？
为什么ASG和EMP首先加入，然后“结果”加入PROJ？

是否可以不并行连接所有 3 个表：

将下面也有可能（只是切换的顺序PROJ和EMP）：

在我们不一定能确保预先排序的两个表中找到不同的行时，使用 aFULL OUTER JOIN而不是 a是个好主意UNION吗？这种方法有什么缺点吗？如果它始终更快，为什么查询优化器不为 UNION 选择FULL OUTER JOIN将使用的相同计划？

通过将 a 重写UNION为FULL OUTER JOIN. AUNION似乎是编写逻辑的更直观的方式，但在探索这两个选项时，我发现 A 的FULL OUTER JOIN内存和 CPU 使用率都更高。

如果您想运行我们的生产查询的简化和匿名版本，请参阅以下脚本：

安装脚本

-- Create a 500K row table
SELECT TOP 500000 ROW_NUMBER() OVER (ORDER BY NEWID()) AS id, v1.number % 5 AS val
INTO #t1
FROM master..spt_values v1
CROSS JOIN master..spt_values v2

-- Create a 5MM row table that will match some, but not all, …

如何调整以下查询，因为它大约需要 8 秒：

select constraint_name,table_name
                from  all_constraints 
         where  r_constraint_name in
                               (select  constraint_name
                                  from  all_constraints
                                where table_name='SUPPLIER');

SUPPLIER 是一个示例表名。

我有以下查询向我显示了 sql server 中缓存的内容：

SELECT cp.objtype AS ObjectType,
OBJECT_NAME(st.objectid,st.dbid) AS ObjectName,
cp.usecounts AS ExecutionCount,
st.TEXT AS QueryText,
qp.query_plan AS QueryPlan
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
WHERE 1=1
  --AND OBJECT_NAME(st.objectid,st.dbid) = 'YourObjectName'
  AND query_plan IS NOT NULL
ORDER BY ExecutionCount DESC

有没有办法可以查询 queryPlan 字段以查找丢失的索引？

当 SQLServer Server 2008r2开始处理查询时，我知道它需要解析 SQL 文本并创建计划，以及其他一些步骤。

它是在缓冲池之外的内存中完成所有这些工作的，对吗？

在实际执行查询以检索/操作数据之前，缓冲池不会发挥作用，对吗？

设想：服务器不是我配置的）

SQL Server 2008r2 SP1 - 是的，它需要打补丁，这是在雷达上 96 GB 的 RAM 最大内存设置为 92 GB 缓冲池，位于 80 GB 以下 使用 PLE 超过 4 小时 查看 resource_semaphore WAITS

如果我理解用于处理查询的内存授予不是来自缓冲池，而是来自剩余的可用内存，那么减少 MAX Memory 应该有助于重新调整 WAIT 类型。我的想法是将 MAX Memory 设置为 72 GB。你的意见？

谢谢！

我有一个表dbo.ClaimBilling，有 130,000 行。在该表中，列OperatorID是 avarchar(max)并且严重倾斜。125,000 行是 'user1'，其余 5000 行分为 6 个其他值，'user2' 共有 3 条记录。

上有一个非聚集索引OperatorID，聚集索引是主键，IDClaimBilling。

我目前有以下查询：

SELECT DISTINCT IDClaimBilling
FROM dbo.ClaimBilling cb
INNER JOIN dbo.BillingItem bi
    ON cb.IDClaimBilling = bi.ClaimID
WHERE OperatorID = @operator

不管是什么值@operator，来自行的估计ClaimBilling都是~4000，这与任何值会返回的值都不接近，而且它始终是聚集索引扫描，它不使用operatorID索引。如果我删除加入并做

SELECT DISTINCT IDClaimBilling
FROM dbo.ClaimBilling
WHERE OperatorID = @operator

然后它确实使用了OperatorID索引，但是无论 的值如何，估计都是错误的@operator，这次总是估计 ~18,000 左右。

我UPDATE STATISTICS dbo.ClaimBilling WITH FULLSCAN在运行查询之前做了一个。

即使统计信息确切地知道每个值有多少行，为什么这些估计值如此错误？

我@operator在测试中声明并分配一个值。它最初是程序的一部分，我认为这就是问题所在，但在临时声明中使用时它的行为也是一样的。

该查询仅在用户首次登录时运行，因此每个用户每天可能只运行几次。