标签: performance

我需要你的帮助，我需要一些指导来提高以下给定视图的性能。

我有一个用以下代码编写的视图：

with timeframes  as
(
select p.SEARCH_NUM, 
case   when p.FROM_DATE is not null then p.FROM_DATE
       when p.FROM_DATE is null and P.SEARCH_DAYS is not null and p.TO_DATE is not null then DATEADD(day,p.SEARCH_DAYS*-1,p.TO_DATE)
       when p.FROM_DATE is null and P.SEARCH_DAYS is not null and p.TO_DATE is null then DATEADD(day,p.SEARCH_DAYS*-1,GetDate()) 
       when p.FROM_DATE is null and P.SEARCH_DAYS is null and p.TO_DATE is not null and p.DURATION = 'Yearly' then DATEADD(year,-1,p.TO_DATE)
       when p.FROM_DATE is null and P.SEARCH_DAYS is null and p.TO_DATE is null and p.DURATION …

我有以下存储过程需要将近一个小时才能完成。结果集大约有 20 万台机器。

我所做的只是从链接服务器中提取一组 id，在本地服务器中删除这些 id，然后从远程服务器中提取这些 id 的所有详细信息并插入它们。INSERT 占 90%，DELETE 表占 9%，SELECT INTO 占 1%。

id 是主键/聚集索引。

    DECLARE @ProcessDate DATETIME
    SET @ProcessDate = CONVERT(VARCHAR(10), DATEADD(DAY, -3,
                                                    GETDATE()), 111)

    SELECT  DISTINCT id
    INTO    #temp_machines
    FROM    remote_server.db.dbo.table1
    WHERE   dt_modify >= @ProcessDate

    DELETE  FROM local_server.db.dbo.table2
    WHERE   id IN ( SELECT id  FROM  #temp_machines )

    INSERT  INTO local_server.db.dbo.table2
    SELECT  *
    FROM    remote_server.db.dbo.table1
    WHERE   id IN ( SELECT id  FROM  #temp_machines )

有什么关于提高性能的建议吗？

据我了解，or应尽可能避免使用查询中的经验法则。

我有两个具有一对多关系的表。

我已经加入了两个如下表。

SELECT A.*, group_concat(B.info separator ','), group_concat(B.info2 separator ',')
FROM A
JOIN B
ON A.id = B.a_id
GROUP BY A.id;

使用是否GROUP_CONCAT会像or在 MySQL 中一样影响性能？如果是这样，连接这些表的有效方法是什么？

任何建议或建议将不胜感激。谢谢你。

如果ID = 01234并且此 ID 在一个月内进行了 3 次交易，如下所示：

***DAY_no              Balance*** 
   1/1/2018              5000
   10/1/2018             10000
   15/1/2018             12000

我想要这样的数据：

***DAY_no              Balance*** 
   1/1/2018              5000
   2/1/2018              5000
   3/1/2018              5000
   4/1/2018              5000
   5/1/2018              5000
   6/1/2018              5000
   7/1/2018              5000
   8/1/2018              5000
   9/1/2018              5000
   10/1/2018             10000
   11/1/2018             10000
   12/1/2018             10000
   13/1/2018             10000
   14/1/2018             10000
   15/1/2018             12000
   16/1/2018             12000
   17/1/2018             12000
   18/1/2018             12000
   19/1/2018             12000
   20/1/2018             12000
   21/1/2018             12000
   22/1/2018             12000
   23/1/2018             12000
   24/1/2018             12000
   25/1/2018             12000
   26/1/2018             12000
   27/1/2018             12000
   28/1/2018             12000
   29/1/2018             12000
   30/1/2018             12000 …

将数据库放在一个服务器实例上的一个常见问题是它们都共享相同的 tempdb。是否可以为单独的数据库分配 tempdb 文件/和文件组。资源调控器允许这样做吗？

数据库 1，只能访问 tempdb 中的一个文件/文件组 1。

数据库 2，只能访问 tempdb 中的一个文件/文件组 2。

你好朋友我正在研究一个从数据库中绘制数据的模块，问题是我必须首先绘制一系列通过数学公式的数据。到目前为止没问题，但我必须从一年中的几个月中获取数据，因此我必须重复这个过程十二次。我的真实问题是这样的：

我怎样才能让每个响应只有一行一行？

如果我尝试这样的事情......

DECLARE @cnt INT = 0;
WHILE @cnt < 12 
BEGIN
select idestatus from order 
SET @cnt = @cnt + 1;
END;

我将执行 12 个查询和 12 个表而我只需要一个。我最终会将其转换为json，因此我希望将所有内容都放在一个响应表中。这是我的查询：

declare
@a decimal(5,2) = 0,
@d decimal(5,2) = 0,
@f1 decimal(5,2) = 0,
@f2 decimal(5,2) = 0

set
@a = (
select 
COUNT(idEstatus) A_D
from t1
where (year(dat)) = 2017 and (month(dat)) = 1
and idEstatus = 2
)
set
@d = (
COUNT(idEstatus) A_D 
from t1
where (year(dat)) …

GI 对 SQL over MPLS 的性能有疑问。

我有一个有 3 个本地化版本的客户。我们希望将服务器环境集中，并将所有 SQL 数据库迁移到总部。我们的客户端使用基于 SQL Server 2017 标准的应用程序。位置之间是 MPLS 连接 100/100，位置和总部之间的延迟 (ping) 为 5-7 毫秒。我们预计一次将有大约 150 个连接到数据库。我们很担心这件事的表现。

当然，我们要构建基于 SQL 2017 Standard 的集群 SQL 和带有用于 SQL DB 的 SSD 磁盘的 Dell 存储阵列。有没有人有类似场景的经验并且可以告诉它？

假设每秒有大约 1k 个请求需要插入。

现在，互联网上对此有很多答案……但在这种特定情况下，它们在技术上是错误的。是的，几乎任何 RDBMS 都可以在标准硬件上每秒处理 1k 次插入，但如果且仅当您放弃 ACID 保证时。令人惊讶的是，互联网上有多少可怕的答案。例如“您可以随时扩展 CPU 和 RAM”，这应该可以每秒提供更多插入次数，但这不是它的工作原理。限制因素是磁盘速度或更精确：您实际上可以将多少事务刷新/同步到磁盘。这是棘手的一点。

在体面的“商品硬件”上（除非您投资于高性能 SSD），这就是您可以期待的：

• SQLite：30 次插入/秒
• MySQL：80 次插入/秒

这是您可以在保持 ACID 保证的同时插入的速率。这实质上意味着，如果您有一个每秒 100 个帖子的论坛……您无法通过这样的设置来处理它。

读取请求不是问题。您每秒可以有数千个读取请求，但写入请求通常小于每秒 100 个。

因此，这个问题专门针对如何在保持 ACID 保证的同时处理每秒 1k 次插入 - 假设单个节点每秒可以处理大约 80 个事务。

我可以看到这种工作的一种方法是，如果您在应用程序逻辑中的某处缓冲插入并将它们作为更大的事务提交到数据库（同时让客户端等待事务结束），如果您只需要单个插入，这应该可以正常工作，尽管它很复杂应用逻辑相当多。

我在另一个论坛上遇到了这个：

PG 对于IN查询中的值的限制为 100，之后不使用所述列上的索引。例如：SELECT ... WHERE IN (...)如果 IN 列表超过 100，则对 PK的典型查询将变成全表扫描。

我无法找到任何关于此的信息。PG 有没有这样的限制（我是这么想的），如果有，这个限制是多少？

我知道有时在临时表中使用大型子选择会更好，但是了解截止位置会很有帮助。

关于 SQLOS 的执行模型（RUNNING 状态、RUNNABLE 队列、WAITER 列表），当当前正在进行 RAM 中页面的逻辑读取时，任务的状态是什么？

如果是 WAITER 列表，最流行的等待类型是什么？

我可以以某种方式测量此类操作所需的时间吗？

我知道很多逻辑读取会减慢您的查询速度，很多表/索引扫描（已经位于缓冲池中）会减慢您的查询速度 - 我只想知道它们如何出现在统计信息/dmv 中或如何将其与其他数据区分开来“经典”等待类型。