我希望你们能在这里帮助我。我们的应用程序每 3 秒轮询一次消息表，寻找要发送的通知。这适用于我们所有的客户（单租户数据库），除了一个。他们将一天 23 小时没有活动，然后一次加载数千条消息（3000+）。在其他情况下，这个卷什么都不是，我们可以轻松处理它，除了在这种情况下，下面的 SQL 查询需要大约 30 秒才能运行，并且随着队列在更新时备份而变得更糟，需要排他锁和因此阻止所有其他查询，因此问题会导致各种破坏。这都是由于糟糕的查询计划造成的。

我们每天早上 5 点进行每日重新索引（重组 < 30%，重建 > 30%，忽略 <5%）以及更新统计信息。这些都来自 Ola Hallengren 维护解决方案。我们也在 SQL Server 2016 上并且完全是最新的 (13.0.5492.2)

我手头没有这 2 个计划，但基本上坏计划会执行 MessagesSent 表（3.5m 行）的全表扫描。

我的理论是，由于查询一整天都没有返回任何内容，因此某些部分没有执行，因此错误查询是最有效的 SQL 查询。

这将在刷新查询计划后继续，因为它只生成相同的计划，但是当我在 MessagesSent 表上更新统计信息时，创建好的计划并且一切正常，查询在大约 10-30 毫秒内执行。

有谁知道我如何微调它以始终使用更好的计划，即使查询返回的数据不存在？作为修补程序，我们向应用程序添加了重新编译选项，但我认为这不是每 3 秒执行一次的查询的理想解决方案。

这是查询：

WITH TopMessage
    AS
    (
        SELECT TOP 1 ID, BatchID FROM MessagesSent 
        JOIN Units ON Unit = idUnit 
        WHERE   MessageDate <= GETDATE() 
          AND         Active = 'True' 
          AND         Status = 'Queued' 
          AND NOT(DialString = 'null') 
          AND           Unit = ('29') …

我们使用 Ola Hallengren 的DatabaseBackup存储过程将 SQL Server 2012 实例上的 SharePoint 数据库负载备份到 Azure blob 存储中。我们已经这样做了很长一段时间，没有任何问题。然而，在过去的 6 周里，我们DIFFs被随机提升FULL，我们无法找出原因。

这是代理步骤的输出

BACKUP DATABASE [Database] TO URL = N'https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak' 
WITH NO_CHECKSUM, COMPRESSION, CREDENTIAL = N'*storeageaccountname*'

Run Code Online (Sandbox Code Playgroud)

如果您查看生成的 URL，您会注意到该过程存储在 DIFF 目录中，但创建了一个完整的备份文件。

https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak
                                                                        --^           --^

DatabaseBackup (Ola proc) 是从 2019-06-14 开始的，所以它需要升级才能公平，但它已经运行了超过 18 个月。

我们不直接调用 Ola 代码，因为我们有一个构建 Azure 虚拟路径名的小包装程序，但本质上这就是我们调用 Ola 代码的方式。

这是一个问题，因为某些未知原因 DIFF 备份被提升为 FULL，这会导致每天 PB 级而不是 GB 级的 Azure blob 备份。

EXECUTE dbo.DatabaseBackup
    @Database = @DatabaseName,
    @URL = @BackupPath,
    @Credential = @StorageAccount,
    @BackupType …

我正在运行查询存储以使数据库性能更好。到目前为止，它一直工作正常。当我尝试加载最后一天的热门持续时间时，我花了 26 分钟来加载屏幕。

我运行的 SQL 版本是： Microsoft SQL Server 2017 (RTM-CU27) (KB5006944) - 14.0.3421.10 (X64) Oct 14 2021 00:47:52 版权所有 (C) 2017 Microsoft Corporation Standard Edition (64-bit) o​​n Windows Server 2019 Datacenter 10.0（内部版本 17763：）（虚拟机管理程序）

QS 中弹出查询：

/*
This query text was retrieved from showplan XML, and may be truncated.
*/

SELECT TOP (@results_row_count)
    p.query_id query_id,
    q.object_id object_id,
    ISNULL(OBJECT_NAME(q.object_id),'') object_name,
    qt.query_sql_text query_sql_text,
    ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration,
    SUM(rs.count_executions) count_executions,
    COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
    JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
    JOIN …

请问这个操作是什么意思？

if @@trancount > 0 commit tran

在那之后

SET IMPLICIT_TRANSACTIONS ON

或者

SET IMPLICIT_TRANSACTIONS OFF

尽管我在网上搜索了很多，但我不明白这一系列命令的含义。

TL; 博士

我偶然发现了 SQL Server Management Studio v17.9 中的一个我不知道的功能。它看起来有点像EXPLAIN在 Oracle、PostgreSQL 和 MySQL 中找到的。此功能在哪里记录？

如何打开该功能

我正在运行以下查询，并启用了包括实际执行计划 (Ctrl + M)和包括实时查询统计信息的选项：

    选择 sdes.session_id
          ,sdes.[状态]
          ,sdes.login_name
          ,sdes.[host_name]
          ,sder.blocking_session_id
          ,sdb.name
          ,sdes.cpu_time
          ,sdes.logical_reads -- 可选：+ sdes.reads + sdes.writes
          ,sdes.last_request_start_time
          ,sdes.program_name
          ,sdes.session_id
          ,sder.request_id
          ,dest.[文本]
    FROM sys.dm_exec_sessions AS sdes
           左连接 sys.dm_exec_connections AS sdec
                ON sdes.session_id = sdec.session_id
           加入 sys.databases AS sdb
                开启 sdes.database_id = sdb.database_id
           左连接 sys.dm_exec_requests AS sder
                ON sdes.session_id = sder.session_id
           交叉应用 sys.dm_exec_sql_text(sdec.most_recent_sql_handle) AS dest
    哪里 1=1
    AND sdb.name = …

我试图让它们超过500 GB几张桌子碎片信息中，我使用...DETAILED的选项sys.dm_db_index_physical_stats。我在我们的预生产服务器上的生产数据库的还原副本上执行此操作，因此我不关心损害服务器上的任何性能。

我运行了它，看起来它正在串行运行，并且需要永远。有没有办法dm_db_index_physical_stats()并行运行？或者是否有任何其他设置干扰它？

我想DBCC TRACEON (8649)并且OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'))在 SQL Server 2014 中不可用。

还试图DBCC SETCPUWEIGHT(1000);从保罗·怀特的博客在这里。该博客提到了并行抑制器，其中之一是系统表。被dm_db_index_physical_stats()认为是系统表吗？

我有一个包含 17,093,139 行的大堆表。该表是数据库中使用最频繁的表。由于这是一个堆表，因此该表中只有非聚集索引。我定期重建/重组这个表上的碎片索引。

现在我们经常面临这个问题：访问此表的大量查询突然开始比平时花费更长的时间。当我检查时，我观察到查询的执行计划已更改。

我创建并删除了一个随机的非聚集索引，这解决了这个问题。

我不明白的是，是什么导致这些突然突然变慢的原因是什么，创建和删除索引在后台对表做了什么来修复它，而索引重建作业没有做？

我需要找出究竟是什么触发了这些减速，以便找到一个永久的解决方案，因为我不能只是每次都继续创建和删除索引来解决这个问题。

这里的任何帮助将不胜感激。

我一直在阅读有关如何优化我的数据库 (MySQL 5.6.51) 设置的文章，我发现了一篇建议尽可能增加key_buffer的文章。

这是我的 my.cnf 文件：

slow_query_log = 1
slow_query_log_file = /var/lib/mysql/slow.log
long_query_time = 1
performance-schema=0
max_allowed_packet=32M
open_files_limit=10000
innodb_buffer_pool_size = 512M
innodb_log_file_size = 128M
innodb_file_per_table=1
key_buffer_size = 32M
default-storage-engine=MyISAM

query_cache_type=2
query_cache_size=128M
query_cache_limit=2M

我应该保持这些设置不变吗？我正在管理我自己的网站数据库，但我不是一个合适的数据库管理员。

谢谢你的帮助。

编辑：对不起，我错误地将我的 MySQL 版本表示为 7.0.33，但那是我的 PHP 版本！（非常愚蠢的错误，我知道）。我在问题中更正了这一点。

我在我的 spool sql 脚本中使用下面列出的 sql 语句，并且我正在从 sqlplus 执行这个脚本。但在终端查询输出仍然存在，我在命令提示符中使用 sqlplus。但是当我尝试直接启动 sqlplus.exe 并使用此脚本时，我没有在终端中获得查询输出。

当我从命令提示符启动 sqlplus 时，有人可以帮助如何停止终端输出吗？

SET ECHO OFF
SET TERMOUT OFF
SET FEEDBACK OFF
SET PAGESIZE 0  
SET LINESIZE 83
SET TRIMSPOOL ON
SET WRAP ON
SET RECSEP OFF

SPOOL '&1'

SELECT 
    DATA_OUT_DATA 
FROM 
    STAGE.DATA_TABLE
ORDER BY 
    DATA_UNIQ_ID,DATA_INV_ID, DATA_SEQ_NO;

SPOOL OFF

SET PAGESIZE 24
SET LINESIZE 80
SET FEEDBACK ON
SET TERMOUT ON

我已经配置了 Ola Hallengren 的备份和完整性检查脚本。

但是，我想了解是否需要设置 SQL Server 索引和统计维护脚本，因为我的 SQL 服务器在 SAN 基础架构上运行，并且我读到将填充因子设置为小于 100% 没有任何好处，或者当数据文件位于 SAN 存储上时执行索引重组或索引重建。任何建议将被认真考虑。

统计信息维护是由 SQL Server 自动完成的，因此我看不出配置 Ola 脚本进行统计信息维护有任何好处。

请注意，SAN存储意味着涉及多个磁盘，数据（无论表是否有索引[堆]或聚集索引或非聚集索引）分散在多个磁盘上。