标签: performance

将较大的 varchar 变量放入小列是否存在任何性能问题？我在执行计划中没有看到任何性能差异。只想验证。

例子，

create table dbo.Product
(
    ProductId int identity(1,1),
    ProductName varchar(25),
    ProductDescription varchar(255),

    constraint pk_ProductId Primary Key (ProductId)
)

案例 1 大 varchar(4000)

declare @ProductNameVar varchar(4000),@ProductDescriptionVar varchar(4000)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)

案例 2 小型 Varchars

declare @ProductNameVar varchar(25),@ProductDescriptionVar varchar(255)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)

我们目前在固态驱动器上有 tempdb（8 个文件）。

我们知道建议主 mdf 和事务日志 ndf 位于不同的驱动器上，以减少争用。tempdb 文件应该在不同的驱动器上以保持一致的原则，还是可以都在同一个驱动器上？

以下文章指出它们都在同一个驱动器上，但正在寻找背景技术解释。 对多个 tempdb 文件的建议

ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev2', FILENAME = N'G:\tempdb2.ndf' , SIZE = 12288000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 0 )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev3', FILENAME = N'G:\tempdb3.ndf' , SIZE = 12288000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 0 )
....

我有一个 After Update 触发器，其中触发器在同一个表中插入一个值以查找持续时间列。我的目标是每当插入 end_time 值时，触发器将找到hh:mm:ss格式的持续时间并插入到持续时间列中。

问题-触发器导致如此多的死锁，从而阻塞了另一个进程。

列数据类型信息..

Start_time datetime, End_time datetime, Duration time(3)

ALTER TRIGGER [dbo].[GET_DURATION] ON [dbo].[INBOUND_CALL_xxx]
AFTER UPDATE AS
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Begin Transaction

               UPDATE INBOUND_CALL_xxx
               SET DURATION = convert(time(0),(END_TIME- START_TIME))                                                     
               FROM INBOUND_CALL_xxx with (nolock)
Commit;

如果我理解正确，索引一列会提高 SELECT 速度，但会降低 INSERT 速度。

假设您的应用程序是新的，并且您已经确定了适合编制索引的列（基于您查看视图的方式，例如 WHERE / JOINS）。

您是否必须在发现性能问题之前立即索引这些列？或者稍后再做这些操作而不影响 INSERT 是否有意义？

我的代码使用将 SQL Server SPID 与 CompanyID 链接起来的表。例如

Spid|CompanyID
1   | 123
2   | 412

每次请求到达数据库时，请求首先检查此表以获取当前用户的公司 ID，如果没有，则将其插入。

自然，这是一个非常高的流量表。我当前的实现是在内存 OLTP 中使用 SQL Server 2016 使用非持久内存表。但是，我们发现了一个与内存压力有关的错误（msft 目前正在研究它），需要远离此实现。

该表在任何给定时间仅包含约 300 条记录，并且用户很少写入该表。但每秒可能有数百次读取。

我们现在将不得不移回磁盘表，并且我不想将任何内容记录到事务日志中以读取该表。有没有办法不将任何内容记录到事务日志或最少记录到事务日志？

我查看了全局临时表，还使用了 TABLOCK 和 Minimally Logging 关键字，但这些似乎都只与高流量写入有关。

有没有办法在这里完成我想要的？

我正在尝试查询 125GB Postgres 数据库中的几个表。我发现很难快速返回结果！

即使找到一列的唯一行也需要 10 多分钟。我使用命令行或 PHPMyAdmin 之类的工具来触发查询，等待时间保持不变。

例如：

SELECT COUNT (DISTINCT column_name) FROM table_name;

我担心如果在这些表上使用连接操作，这个等待时间会显着增加并且会更加痛苦。

任何人都可以提出什么可能是快速恢复统计数据的可能解决方案？

我有一个带有 100Gb MDF 和 4Gb LDF 的 SQL2016 DB 的客户端。数据库设置为简单。我无法将 LDF 缩小到最低限度。如何将 LDF 缩小到正常水平？

此设置和文件大小是否会影响性能？

我正在 SQL Server 上开发一个数据库项目，我在考虑使用列存储索引是否是一个好主意。

该项目由一个表 (A) 组成，该表将包含大量行，一列具有许多重复值。每天，一包新行将添加到表中，每个包都有一个“DateId”。

之后，我需要更新一个不同的表 (B) 加入 A 并过滤 A 以获取“DateId”和其他列。

SQL 中的示例：

CREATE TABLE A (
  [Id] [BIGINT] IDENTITY(1,1) NOT NULL,
  [DateId] [INT] NOT NULL,
  [B_Id] [BIGINT] NOT NULL,
  -- other columns...
  INDEX cci_A CLUSTERED COLUMNSTORE
)

CREATE TABLE B (
  [Id] [BIGINT] IDENTITY(1,1) NOT NULL,
  -- other columns...
  INDEX cci_B CLUSTERED COLUMNSTORE
)

UPDATE B
SET ...
FROM A
INNER JOIN B ON A.B_Id = B.Id
WHERE A.DateId = @myDateId

在这种情况下，列存储是一个不错的选择吗？

我一直在对新的（虚拟）服务器进行一些测试，以替换现有的生产服务器。我们怀疑当前的生产服务器规格过高，因此正在从低水平调整新服务器的虚拟组件（RAM、CPU 等），直到性能适合处理当前的工作负载。

虽然认识到新服务器处理现有服务器工作负载的能力的真正测试是针对新服务器测试该工作负载，但出于兴趣，我对现有服务器和新服务器进行了一些简单的、任意的测试：

• 恢复数据库-读取速度
• 备份数据库-写入速度
• 大型数据库上的 DBCC CHECKDB - 花费的时间

（两台服务器上使用相同的数据库备份，以使上述所有测试保持一致）

以上所有内容都支持新服务器（更快的读写速度、更快的 CHECKDB）

我做的最后一个基本测试是测试执行一个简单的操作所需的时间SELECT *在冷缓存和热缓存上最大的表之一上执行简单操作所需的时间，以进一步了解读取速度。

测试代码如下，我在两台服务器上运行

USE StackOverflow

SET STATISTICS IO, TIME ON

CHECKPOINT

DBCC DROPCLEANBUFFERS

SELECT * FROM Users  /* cold cache run */
SELECT * FROM Users  /* warm cache run */

统计IO如下：

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 12 ms.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

 SQL Server Execution Times:
   CPU time = …

我最近注意到 SQL Server 错误日志中的一条错误消息显示“查询处理器耗尽了内部资源，无法生成查询计划”。我怀疑我的服务器可能内存或 CPU 资源不足。但是，我不确定如何确认这一点。

我知道 sysprocesses 和 sp_whoisactive 命令，但我不确定它们是否可以告诉我我的服务器目前是否耗尽了资源。

有人可以为我提供一些关于如何检查我的 SQL Server 当前是否内存或 CPU 资源不足的指导吗？任何帮助，将不胜感激。