我们有一个第三方分析平台,允许最终用户从选择的预定义视图中创建自己的表格和图表。这将查询 MS SQL 数据库。
不幸的是,根据我的知识和理解,该软件注入数据库以查询数据的 SQL 语法似乎非常低效,或者看起来如此。
例如,以下是将两个表连接在一起的查询的样子:
SELECT tblOne.ColumnOne, tblOne.ColumnTwo, tblTwo.ColumnThree
FROM (SELECT * FROM tblOne) AS tblOne
JOIN (SELECT * FROM tblTwo) AS tblTwo ON tblOne.id = tblTwo.id
Run Code Online (Sandbox Code Playgroud)
现在想象这些表每个都有很多列,或者有更多连接到附加表,每个表都遵循相同的模式 - 我假设这将在子查询中执行全表扫描,有效地读取比实际需要的更多的数据是否正确?我是否也正确地假设以下内容实际上会更有效?
SELECT tblOne.ColumnOne, tblOne.ColumnTwo, tblTwo.ColumnThree
FROM tblOne
JOIN tblTwo ON tblOne.id = tblTwo.id
Run Code Online (Sandbox Code Playgroud)
在我给这个分析解决方案的开发人员写一封措辞强硬的电子邮件之前,我只是想要第二个意见,以防万一我误解了引擎将如何处理这样的查询。
提前致谢。
在我现在的环境中,我有很多存储过程的实例,就像下图所示的那样,将一堆参数传递给过程,然后在过程select exists中运行a ,并根据结果运行不同的逻辑路径在存储过程中。
我对以下程序有几个问题:
1)它是参数嗅探的好选择吗?
2)我怎么能option(recompile)在代码中添加?
在代码中添加选项(重新编译)与使用重新编译创建存储过程之间存在差异。
option(recompile)如果可能的话,我会更热衷于。
ALTER PROCEDURE [dbo].[usp_upd_activity]
@activityId INT,
@title VARCHAR(100),
@description VARCHAR(MAX),
@inclusions VARCHAR(MAX),
@locationId INT,
@imageUriMain VARCHAR(255),
@uploadToBucket VARCHAR(200),
@path VARCHAR(200)
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRAN
BEGIN TRY
DECLARE @documentId INT
IF NOT EXISTS (SELECT 1
FROM document
WHERE activityId = @activityId)
BEGIN
INSERT INTO document
( [uploadToBucket], [path], [activityId])
VALUES (@uploadToBucket, @path, @activityId)
SET @documentId = SCOPE_IDENTITY();
END
ELSE
BEGIN
UPDATE document
SET uploadToBucket = @uploadToBucket, …Run Code Online (Sandbox Code Playgroud) sql-server stored-procedures optimization sql-server-2016 parameter-sniffing
TL;DR:你为什么要创建一个没有任何类型的键(甚至不是主键),也没有索引的数据库?
我加入了一个非盈利组织,该组织在 14 个月后迁移到定制的前端以进行财务处理。该组织有大约 60 名员工。
我有 6 年的软件开发经验,所以他们足够信任我,可以让我访问他们的数据库。
瞧,前端 SQL Server 生产数据库绝对没有任何类型的键,也没有索引。但是,该界面实际上运行良好。创建该系统的外部公司在创建新功能方面反应相对较快,并且该系统确实有效。
我已经在那里工作了大约 6 个月。大多数问题相对较小。我还没有看到由于公司方面的错误而导致的任何灾难性错误。再说一次,根本没有 UAT(用户验收测试),我也不知道这家外部公司的 QA 是如何工作的。我只与销售/技术联络员联系。
我高度怀疑这家公司只是为了将来的维护费而从非营利组织中掠夺。我厌倦了缓慢的数据库,以至于我根据最常用的报告添加了一堆多列、非聚集、非唯一索引,并将数据库速度提高了大约 100 倍(我没有打扰基准)。
我以前从未见过这种类型的设置,而且解决方案非常简单,以至于我很难理解为什么没有完成。我尝试询问销售联系人,但他只是不知道我在说什么。
我的评估是正确的还是有合法的理由这样做?
说明:
“DB关系是本质的吗?”
我相信是这样。他们每周和每月运行 DR/CR 报告。它在很大程度上是一个会计数据库。即使没有设置主键,它们也已在应用程序级别强制执行唯一性。
“数据库有多大”
它应该是一个全新的、定制的系统,在 SQL Server 2014 上运行。但是,我还发现他们将 DB 置于 2008 兼容模式(兼容代码 100)。我已经问过这个问题,但我的联系人没有回复我。
如果我理解正确,索引一列会提高 SELECT 速度,但会降低 INSERT 速度。
假设您的应用程序是新的,并且您已经确定了适合编制索引的列(基于您查看视图的方式,例如 WHERE / JOINS)。
您是否必须在发现性能问题之前立即索引这些列?或者稍后再做这些操作而不影响 INSERT 是否有意义?
mysql performance optimization query-performance performance-tuning
UPDATE MARK M SET ARCHIVE_FLAG = 'N' WHERE EXISTS
(SELECT /*+ cardinality(S1, 10) parallel(S1,8)*/ 1 FROM SHFASG S, SHIFT S1
WHERE S.ID = S1.ID AND M.ID = S.MARKID AND ARCHIVE_FLAG <> 'Y');
Run Code Online (Sandbox Code Playgroud)
这是我拥有的 oracle 查询,我想为我的 MS SQL DB 创建类似的查询,请提供任何帮助
sql-server optimization parallelism cardinality-estimates query-performance
我在网上读过,它将with recompile重新编译整个过程,而Option(recompile)只会重新编译它所使用的特定语句。如果重新编译过程中的某个语句,是否会影响过程的其他部分,因为现在优化器具有更好的统计信息,以便稍后做出更好的决策(假设选项(重新编译)产生更好的统计信息),从而导致完全重新编译的程序?到底有何with recompile不同option(recompile)?
我有一个视图,它有一个聚集索引和其他非聚集索引。
SELECT即使我选择了一个索引列,一个简单的查询也不使用任何索引。
这可能是什么原因?
我在 Windows NT 6.1 (Build 7600) 上使用 Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 企业版
sql-server optimization sql-server-2008-r2 materialized-view
我被检查的性能OPTION(RECOMPILE)和OPTION(FAST n)及其行为有着惊人的不同。OPTION(FAST n)那么快得多OPTION(RECOMPILE)。难道OPTION(FAST n)?每次都创建新的执行计划?
给定 2 个 SQL Server 实例,其中第二个实例配置有用于 tempdb 的 RAMDisk 和以下测试用例。
-- Create source data
select top(1000000) * /* ~10 cols */ into #t1 from SomeData;
Run Code Online (Sandbox Code Playgroud)
然后测量这些级联选择的总运行时间;
-- Benchmark
select * into #t4 from #t1;
select * into #t5 from #t4;
select * into #t6 from #t5;
Run Code Online (Sandbox Code Playgroud)
我的运行时间是一样的~(15s vs ~15s)。一个 CPU 在整个测试期间都达到最大值。
有没有办法加快跨 CPU 的查询(是 tempdb 文件分区)吗?
通过评论请求数据:
The 1 CPU is the SQL Server 2012 process on a 12 CPU server circa 2012.
Machine: 24GMb RAM, HardDrives: 10kRpm x 2 …Run Code Online (Sandbox Code Playgroud) optimization ×9
sql-server ×8
performance ×2
mysql ×1
parallelism ×1
recompile ×1
t-sql ×1
tempdb ×1