这是我的查询:
SELECT a.z_companyid_pk "z_companyid_pk" ,
a.company_name "Client" ,
a.display_name "Display_Name" ,
a.z_parentcompanyid_fk "Parent_Company",
a.z_resellerid_fk "Reseller" ,
(SELECT company_name
FROM company_mst
WHERE z_companyid_pk= a.z_resellerid_fk
)
"Reseller_name",
(SELECT IF(COUNT(*)>=1,"YES","NO")
FROM webprofile
WHERE z_boxid_fk IN
(SELECT z_boxid_pk
FROM box_mst
WHERE z_companyid_fk=a.z_companyid_pk
)
)
"V1_Website",
(SELECT IF(COUNT(*)>=1,"YES","NO")
FROM webapp_mst
WHERE z_companyid_fk=a.z_companyid_pk
)
"V2_Website",
(SELECT IF(COUNT(*)>0,"YES","NO")
FROM widget_mst
WHERE widget_status=1
AND type IN("templated-menu",
"menus")
AND z_companyid_fk=a.z_companyid_pk
)
"Widgets_with_my_menu",
(SELECT IF(COUNT(imagehtml)>0,"YES","NO")
FROM image_mst
WHERE LENGTH(imagehtml)>0
AND z_companyid_fk =a.z_companyid_pk
)
"HTML_menus",
(SELECT MAX(login_datetime)
FROM loginlog_mst a
LEFT …Run Code Online (Sandbox Code Playgroud) 当存储过程在任何时候从管理工作室运行良好时,我正在对这种情况进行故障排除,但即使对于相同的参数,相同的存储过程在其中一个网络服务器中运行得非常糟糕。可能有一些原因导致这种情况,包括阻塞等。
我想排除使用不同 SET 选项创建 2 个不同计划的可能性,并且这些计划中至少有一个使用产生错误计划的参数组合进行了优化。
引用本杰明·内瓦雷斯:
“一般来说,查询优化是一个代价高昂的操作,为了避免这种优化成本,计划缓存会尽量将生成的执行计划保存在内存中,以便它们可以被重用。但是,如果一个新的连接运行相同的存储过程有不同的SET选项,它可能会生成一个新的计划……”
为了解决这个问题,我想要一个 T-SQL 查询,它会显示为会话设置的所有值。
这可能吗?
以下 SET 选项将影响执行计划的重用:
(他们中的一些)
DATEFORMAT
LANGUAGE
NUMERIC_ROUNDABORT
FORCEPLAN
performance sql-server optimization plan-cache sql-server-2014 query-performance
我在数据库中有两张表,一张是Orders,另一张是customers
订单表包含:订单 ID、客户 ID 和订单日期
客户表包含:CustomerID、CustomerName、ContactName 和 country
实际上,“Orders”表中的“CustomerID”列指的是“Customers”表中的“CustomerID”。上面两个表之间的关系是“CustomerID”列。
加入查询
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers
ON Orders.CustomerID=Customers.CustomerID;
Run Code Online (Sandbox Code Playgroud)
简单查询
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders,Customers
WHERE Orders.CustomerID=Customers.CustomerID;
Run Code Online (Sandbox Code Playgroud)
两个查询的结果是: OrderID 、 CustomerName 和 OrderDate
在上面的两个查询中,我得到了相同的结果。我想知道这些查询之间的区别,如果我们可以通过 SIMPLE 查询来实现,为什么要使用 JOIN?
我有一个 8GB 大的表,有 20M 条记录。有一个名为 mth 的 int 字段。第 m 个字段以 YYYYMM 的形式存储日期信息,我想将第 m 个字段转换为连续整数。所以我使用一个公式从字段mth中获取年份和月份并计算月份顺序,具体来说,我使用以下代码:
create function mth_to_num(@month int)
returns int
as
begin
return(round(@month/100,0)*12+@month-100*round(@month/100,0))
end
Run Code Online (Sandbox Code Playgroud)
然后我用下面的代码来更新大表中的值
update full_orig_month_Q1_1999
set mth_order = dbo.mth_to_num(period)
Go
Run Code Online (Sandbox Code Playgroud)
但是,代码执行时间很长,大约 2-3 分钟。我的系统是带有 SQL Server 2016 的 Windows 10 64 位。有什么办法可以加快速度吗?
另一个问题是,执行上述查询后,我发现SQL server 在数据库中占用了多达8GB 的空间。需要那么多内存吗?我怎样才能释放它们?
提前感谢您的帮助!
杰森
我想更新一个有 83,423,460 行并且还在增长的大表。
以下查询需要 8 分钟才能成功执行:
UPDATE FPP_Invoice_Revenue
SET Till_Prev_Inv_Amt = Till_Prev_Inv_Amt_In_USD / 0.0285714286,
Cur_Inv_Amt = Cur_Inv_Amt_In_USD / 0.0285714286,
YTD_Inv_Amt = YTD_Inv_Amt_In_USD / 0.0285714286
WHERE SOW_Number = '20014378'
Run Code Online (Sandbox Code Playgroud)
存在一个clustered index。我想在更新之前禁用该索引,并在更新后再次重建,但这也不起作用,因为重建需要很多时间。
我在某处读过这可以通过分成小部分来实现,但是如何划分上述查询?
DDL:
CREATE TABLE [dbo].[FPP_Invoice_Revenue](
[Project_Code] [varchar](10) NOT NULL,
[Project_Desc] [varchar](50) NULL,
[SOW_Number] [varchar](10) NOT NULL,
[SOW_Desc] [varchar](50) NULL,
[Invoice_No] [varchar](50) NOT NULL,
[Inv_Month] [int] NOT NULL,
[Inv_Year] [int] NOT NULL,
[Billing_Date] [smalldatetime] NULL,
[Doc_Currency] [varchar](10) NULL,
[Vertical] [varchar](255) NULL,
[Till_Prev_Inv_Amt] [numeric](24, 10) NULL,
[Cur_Inv_Amt] [numeric](24, 10) NULL, …Run Code Online (Sandbox Code Playgroud) 我有一个现有的ASSET_SUMMARY_VW观点:
+-----------------------+---------------+
| ASSET_TYPE | COST |
+-----------------------+---------------+
| TRANSPORTATION | 1,000,000,000 |
| TRANSPORTATION | 500,000,000 |
| TRANSPORTATION | 500,000,000 |
| ACTIVE TRANSPORTATION | 100,000,000 |
| ACTIVE TRANSPORTATION | 50,000,000 |
| STORMWATER MANAGEMENT | 500,000,000 |
+-----------------------+---------------+
Run Code Online (Sandbox Code Playgroud)
我想 GROUP BY 并计算每个ASSET_TYPE与总成本相比的百分比:
+-----------------------+---------------+------------------+
| ASSET_TYPE | COST | PERCENT_OF_TOTAL |
+-----------------------+---------------+------------------+
| TRANSPORTATION | 2,000,000,000 | 75.4 |
| ACTIVE TRANSPORTATION | 150,000,000 | 5.6 |
| STORMWATER MANAGEMENT | 500,000,000 | …Run Code Online (Sandbox Code Playgroud) performance oracle aggregate computed-column query-performance
我们有一个第三方分析平台,允许最终用户从选择的预定义视图中创建自己的表格和图表。这将查询 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)
在我给这个分析解决方案的开发人员写一封措辞强硬的电子邮件之前,我只是想要第二个意见,以防万一我误解了引擎将如何处理这样的查询。
提前致谢。
我试图确定用户所描述的应用程序性能缓慢。我有一种预感,它可能与应用程序本身有关,而不是 SQL 服务器的问题。我已经检查了许多常见的疑点,以确定常见的瓶颈。
MS SQL 服务器 (11.0.5058) 在 Hyper-V, 2012r2 上运行,并为来宾分配了以下内容:72GB 内存、16 个处理器、4 个带有 tempDB、OS、DB、程序文件的磁盘控制器,它们都在单独的 VHD 上。
在一天中运行 perfmon
% 处理器时间< 40% 最大值
平均磁盘 Q 长度0.003 平均 - 0.41 最大值
% 磁盘时间平均0.0038
平均可用字节数5010
缓冲区高速缓存命中率99.996 平均 98.614 分钟
我没有看到磁盘、内存或处理器有任何问题。我接下来应该看哪里?
我如何说服我的 DBA 存在 SQL Server 的零星问题?
问题:基本上,主要减速......一些查询,生成执行计划,甚至生成现有数据库对象的脚本有时可能需要永远。即使是应该没有性能问题的操作,比如生成创建表脚本,有时也可能需要很长时间。
情况 - 我有一个 SQL Server 数据库,我可以在其中创建表/视图/等。
该数据库托管在由公司 IT 管理的 SQL Server (MS SQL Server 2016) 上。
我已经让他研究一下,我相信他一直在认真检查日志,他说服务器上的负载有时我注意到大量的性能问题没有显示出任何异常。事实上,他说这都在 5% 以下(非常低)。
我在暂存和开发环境中运行完全相同的代码和查询,在那里很好 - 相对于生产环境,它甚至超快。
老实说,我不知道这可能是什么问题。我不知道从哪里开始。
作为一名 DBA,我已经对 SQL 服务器进行性能调优多年。
我正在尝试创建一个快餐版的性能指标,它可以快速(在 5 分钟内)和准确(可证明)回答来自管理层的问题“此服务器需要更多/更快 _ 吗?”
“_”是 IT 堆栈自下而上的这 4 个可能的瓶颈之一(从服务器的角度来看,无需进入应用程序/代码/用户界面):
网络
磁盘
记忆
中央处理器
有数以千计的柜台、文章、产品可以帮助监控这些。但是是否有一个简单、即时和准确的脚本可以确定这 4 个中的任何一个是否需要扩大或缩小?
例如 sys.dm_os_wait_stats - SOS_SCHEDULER_YIELD 具有高信号等待 => 需要更多或更快的 CPU。
PAGEIO_LATCH => 需要更多文件或更快的磁盘
这2个准确吗?Page Life Expectancy 是否准确地“证明”了需要更多内存?您用于诊断性能问题的GO-TO脚本是什么?
我使用过 sp_whoisactive、sp_blitz、Glenn 的 DMV、Spotlight、Idera 等,但我还没有遇到一个脚本可以满足 CIO 关于在哪里花费预算资金的问题,或者将问题正确归咎于错误代码,或者速度缓慢SAN 或 ISP。
每当任何(网络/系统/DBA/应用程序)工程师指责另一个团队时,我们都必须“证明”我们的陈述,而有了虚拟化和云,没有理想的测试环境,没有停机时间,越来越难以证明地精确定位服务器性能问题的根源,可能是任务管理器以外的<请原谅咆哮>
performance ×10
sql-server ×7
optimization ×4
mysql ×2
aggregate ×1
join ×1
oracle ×1
plan-cache ×1
t-sql ×1
update ×1