这是非常微不足道的，但如果有人手头有答案，我会很感激。
我使用msdb..sp_send_dbmail存储过程作为分发简单报告的轻量级方法。这通常需要生成 CSV。但是，存储过程包括 Unicode little-endian 前缀 FF FE。这会混淆 Excel，导致它不会自动将 CSV 解析为列。
有许多变通方法：使用真正的报告平台（我们有 Crystal，但它从来没有可靠地工作过）；将文件发送到一个小应用程序，该应用程序将文件转换为 ANSI 并继续发送；使用制表符分隔符（我最喜欢的）；或教育收件人如何使用 CSV（开个玩笑，我们都知道这是不可能的）。
但是，我很想在某处拨动一个开关并告诉 SQL Server 停止将附件创建为 Unicode，因为我没有这样的需要。我还没有找到这样的设置；这可能吗？
谢谢！
编辑
根据 Rohan 的回答，SQL 代理作业步骤中的这个脚本几乎可以工作：
$reportQuery = "EXEC Routine..TopTenReviewsReport @DoNotLog = 1"
$filePath = "\\SQLBI001\RawData\TopTenReviewsReport.csv"
$mailQuery = "
EXEC msdb..sp_send_dbmail
@profile_name = 'X',
@recipients = 'X',
@subject = 'X',
@file_attachments = '" + $filePath + "'"
Invoke-Sqlcmd -query $reportQuery | export-csv $filePath
$result = Invoke-Sqlcmd -query $mailQuery
该文件现在有一个“#TYPE System.Data.DataRow”前缀，而不是 0xFF FE，但它现在是 ANSI，所以就是这样。
我编写了一个 Web 应用程序，它聚合并呈现来自 SQL Server 的数据。涉及的数据量很大，涉及的聚合也比较多。目前，在“专家”的建议下，我使用了包括聚合在内的大量嵌套查询，但是我刚刚在这里阅读了有关通过将大型复杂查询分解为临时 (#) 表来优化大型复杂查询的信息。这似乎与许多表明使用临时表不是最佳实践的文献相冲突。
Web 应用程序本身将被相当多的人使用，因此理想情况下，如果他们需要索引，我不希望临时表相互冲突。
查询优化的最佳方法是什么，以及广泛使用的网络应用程序的最佳实践是什么？
提前致谢。
厘米
有没有办法查询 SQL Server 2008 R2 中所有作业的所有者？我发现在编辑维护计划时所有者会发生变化，所以我想确保它们都归sa.
一点背景资料：
我们在装有 Microsoft Windows Server 2003 SP2 的服务器上运行 SQL Server 2005 SP2。
当我运行探查器时，我注意到它EXECUTE msdb.dbo.sp_sqlagent_get_perf_counters每 20 秒运行一次。
这是探查器每 20 秒运行一次：
SELECT N'Testing Connection...'
go
EXECUTE msdb.dbo.sp_sqlagent_get_perf_counters
go
到目前为止我做了什么：
可能的答案：
想象一下以下场景：我有两台服务器，它们位于两个单独的专用网络上。
已创建链接服务器，服务器 A 中有一个表，该表具有服务器 B 上同一表的更新版本。更新范围不大，本质上只是重新分配了一些布尔值。
两台服务器之间的连接可靠但速度较慢，并且两表之间的排序规则不匹配。
是否有推荐或标准的方法来更新具有排序规则不匹配的两台服务器之间的信息？
我正在尝试减少索引的碎片化。
首先，我重建了所有碎片高于 30% 的索引，但我的大多数索引仍然具有高碎片或什至没有改变 1%。
深入观察，当我减少重建语句的填充因子时，也会减少碎片。
现在，最好的选择是什么？
具有高填充因子的更高碎片或降低填充因子然后获得更低的碎片？
暂时谢谢。
我们的一个数据库中有一张表，其结构大致如下：
Field1 int primary key
Field2 int foreign key A
Field3 int foreign key B
Field4 int foreign key C
Field5 ... Field70 diverse data types, for the "payload"
外键列上有索引，尽管只有键列，没有任何包含的列。索引分析例程不断建议具有相同键列的新索引，这些列已经存在索引，但包含许多列 - 在一种情况下甚至是所有 Field5 到 Field70。我有点犹豫是否要创建包含如此多列的索引 - 感觉就像复制表本身。
对于索引中包含的列的数量是否有一些经验法则限制，或者我应该继续将现有索引（仅键列）替换为具有相同键列和如此多包含列的索引？
提前致谢。
我刚刚开始担任 DBA 的新工作。突然间，我们开始收到有关磁盘空间的警报。当我查看时，我发现 tempdb 日志文件在不断增长。有一个针对它的活跃事务正在运行。我检查了查询，它使用的是临时表。从45分钟开始，事情就毫无进展了。我尝试了很多事情，包括这些作为最后的手段。
use tempdb
GO
DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
但这根本没有帮助。我还杀死了卡住的插入件。看来这并没有超出正常流程。最后我不得不紧急中断几分钟并重新启动 SQL 服务。关于我可能错过的内容有什么建议吗？
我遇到了死锁问题，所以我开始使用我在某处读到的这个 CTE 技巧。没有更多的僵局。
但是现在我添加的每个客户端都会减慢（阻止？）存储过程。例如，1 个客户端的 1-2 秒更新变为两个客户端的 2-4 秒。（这个简单的隐喻查询运行时间为 0.001 秒，但在少数客户之后达到 0.03 秒——所以这个问题与我的实际实现无关。）
是锁定问题吗？我需要将它包装在（某种）交易中吗？
WITH UpdateView AS (
SELECT TOP 1 W.*
FROM [WidgetSandbox].[dbo].[Widgets] W
INNER JOIN [WidgetSandbox].[dbo].[Sizes] S ON W.SizeId = S.Id
WHERE W.StatusId = @availableStatusId
AND W.ColorCode = @colorCode
ORDER BY S.DiameterInches
)
UPDATE UpdateView
SET StatusId = @soldOutStatusId
OUTPUT INSERTED.Id INTO @outputIds;
SET @singleUpdatedId = (SELECT TOP 1 Id FROM @outputIds);
SELECT * FROM [WidgetSandbox].[dbo].[Widgets]
WHERE Id = @singleUpdatedId;
我希望我能更好地了解具体问题是什么，但事实上我只是被卡住了......
DDL，如果有帮助：https : //gist.github.com/RobertBaldini/3740c7bb85eea47d7fe63cb8602ac2d6
回购：https : …
我有一个数据库，它有多个表，没有任何聚集索引。我发现的所有内容都很小（< 500 行）。具体来说，PRIMARY KEY NONCLUSTERED根本没有其他索引。
在非常高的层次上，我理解没有聚集索引的性能限制。也许更多，所以我明白这不是最佳实践，但在我积极开始将非聚集主键转换为聚集主键之前，在转换这些索引时有什么注意事项吗？
我能想到的唯一一个是更新大表上的索引所需的时间，但同样这些时间相对较小。也许文件和分区，但我只有一个分区。
作为参考，这是一个运行在 SQL Server 2016 上的兼容 2008 的 SQL Server 数据库。这是在我们的主要 OLTP 系统中（这些表不涉及仓储和 ETL）。