SQL Server 内存优化表 - 与临时表相比性能较差
Posted
技术标签:
【中文标题】SQL Server 内存优化表 - 与临时表相比性能较差【英文标题】:SQL Server Memory Optimized Table - poor performance compared to temporary table 【发布时间】:2019-11-14 13:59:48 【问题描述】:我正在尝试使用经典临时表对 Microsoft SQL Server 2016 中的内存优化表进行基准测试。
SQL Server 版本:
Microsoft SQL Server 2016 (SP2) (KB4052908) - 13.0.5026.0 (X64) Mar 18 2018 09:11:49
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows 10 Enterprise 10.0 <X64> (Build 17134: ) (Hypervisor)
我正在执行此处描述的步骤:https://docs.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/faster-temp-table-and-table-variable-by-using-memory-optimization?view=sql-server-ver15。
CrudTest_TempTable 1000, 100, 100
go 1000
对
CrudTest_memopt_hash 1000, 100, 100
go 1000
这个测试做什么?
1000 次插入 100 次随机更新 100 次随机删除这会重复 1000 次。
第一个使用经典临时表的存储过程大约需要 6 秒才能运行。
第二个存储过程至少需要 15 秒并且通常会出错:
开始执行循环
消息 3998,第 16 层,状态 1,第 3 行 在批处理结束时检测到不可提交的事务。事务被回滚。
消息 701,级别 17,状态 103,过程 CrudTest_memopt_hash,第 16 行 [批处理开始第 2 行] 资源池“默认”中的系统内存不足,无法运行此查询。
我做了以下优化(在更糟之前):
哈希索引同时包含 Col1 和 SpidFilter
在单个事务中执行所有操作使其运行速度更快(但如果没有它运行会很好)
我正在生成随机 id - 没有它,每次迭代的记录最终都在同一个桶中
我还没有创建本地编译的 SP,因为我的结果很糟糕。
我的机器上有大量可用 RAM,SQL Server 可以使用它 - 在不同的情况下它会分配很多内存,但在这个测试用例中它只是出错。
对我来说,这些结果意味着内存优化表不能替代临时表。你有类似的结果还是我做错了什么?
使用临时表的代码是:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
DROP PROCEDURE IF EXISTS CrudTest_TempTable;
GO
CREATE PROCEDURE CrudTest_TempTable
@InsertsCount INT, @UpdatesCount INT, @DeletesCount INT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRAN;
CREATE TABLE #tempTable
(
Col1 INT NOT NULL PRIMARY KEY CLUSTERED,
Col2 NVARCHAR(4000),
Col3 NVARCHAR(4000),
Col4 DATETIME2,
Col5 INT NOT NULL
);
DECLARE @cnt INT = 0;
DECLARE @currDate DATETIME2 = GETDATE();
WHILE @cnt < @InsertsCount
BEGIN
INSERT INTO #tempTable (Col1, Col2, Col3, Col4, Col5)
VALUES (@cnt,
'sdkfjsdjfksjvnvsanlknc kcsmksmk ms mvskldamvks mv kv al kvmsdklmsdkl mal mklasdmf kamfksam kfmasdk mfksamdfksafeowa fpmsad lak',
'msfkjweojfijm skmcksamepi eisjfi ojsona npsejfeji a piejfijsidjfai spfdjsidjfkjskdja kfjsdp fiejfisjd pfjsdiafjisdjfipjsdi s dfipjaiesjfijeasifjdskjksjdja sidjf pajfiaj pfsdj pidfe',
@currDate, 100);
SET @cnt = @cnt + 1;
END
SET @cnt = 0;
WHILE @cnt < @UpdatesCount
BEGIN
UPDATE #tempTable SET Col5 = 101 WHERE Col1 = cast ((rand() * @InsertsCount) as int);
SET @cnt = @cnt + 1;
END
SET @cnt = 0;
WHILE @cnt < @DeletesCount
BEGIN
DELETE FROM #tempTable WHERE Col1 = cast ((rand() * @InsertsCount) as int);
SET @cnt = @cnt + 1;
END
COMMIT;
END
GO
内存测试中使用的对象是:
DROP PROCEDURE IF EXISTS CrudTest_memopt_hash;
GO
DROP SECURITY POLICY IF EXISTS tempTable_memopt_hash_SpidFilter_Policy;
GO
DROP TABLE IF EXISTS tempTable_memopt_hash;
GO
DROP FUNCTION IF EXISTS fn_SpidFilter;
GO
CREATE FUNCTION fn_SpidFilter(@SpidFilter smallint)
RETURNS TABLE
WITH SCHEMABINDING , NATIVE_COMPILATION
AS
RETURN
SELECT 1 AS fn_SpidFilter
WHERE @SpidFilter = @@spid;
GO
CREATE TABLE tempTable_memopt_hash
(
Col1 INT NOT NULL,
Col2 NVARCHAR(4000),
Col3 NVARCHAR(4000),
Col4 DATETIME2,
Col5 INT NOT NULL,
SpidFilter SMALLINT NOT NULL DEFAULT (@@spid),
INDEX ix_SpidFiler NONCLUSTERED (SpidFilter),
INDEX ix_hash HASH (Col1, SpidFilter) WITH (BUCKET_COUNT=100000),
CONSTRAINT CHK_SpidFilter CHECK ( SpidFilter = @@spid )
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO
CREATE SECURITY POLICY tempTable_memopt_hash_SpidFilter_Policy
ADD FILTER PREDICATE dbo.fn_SpidFilter(SpidFilter)
ON dbo.tempTable_memopt_hash
WITH (STATE = ON);
GO
而使用它们的存储过程是:
CREATE PROCEDURE CrudTest_memopt_hash
@InsertsCount INT, @UpdatesCount INT, @DeletesCount int
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRAN;
DECLARE @cnt INT = 0;
DECLARE @currDate DATETIME2 = GETDATE();
DECLARE @IdxStart INT = CAST ((rand() * 1000) AS INT);
WHILE @cnt < @InsertsCount
BEGIN
INSERT INTO tempTable_memopt_hash(Col1, Col2, Col3, Col4, Col5)
VALUES (@IdxStart + @cnt,
'sdkfjsdjfksjvnvsanlknc kcsmksmk ms mvskldamvks mv kv al kvmsdklmsdkl mal mklasdmf kamfksam kfmasdk mfksamdfksafeowa fpmsad lak',
'msfkjweojfijm skmcksamepi eisjfi ojsona npsejfeji a piejfijsidjfai spfdjsidjfkjskdja kfjsdp fiejfisjd pfjsdiafjisdjfipjsdi s dfipjaiesjfijeasifjdskjksjdja sidjf pajfiaj pfsdj pidfe',
@currDate, 100);
SET @cnt = @cnt + 1;
END
SET @cnt = 0;
WHILE @cnt < @UpdatesCount
BEGIN
UPDATE tempTable_memopt_hash
SET Col5 = 101
WHERE Col1 = @IdxStart + cast ((rand() * @InsertsCount) as int);
SET @cnt = @cnt + 1;
END
SET @cnt = 0;
WHILE @cnt < @DeletesCount
BEGIN
DELETE FROM tempTable_memopt_hash
WHERE Col1 = @IdxStart + cast ((rand() * @InsertsCount) as int);
SET @cnt = @cnt + 1;
END
DELETE FROM tempTable_memopt_hash;
COMMIT;
END
GO
索引统计:
table index total_bucket_count empty_bucket_count empty_bucket_percent avg_chain_length max_chain_length
[dbo].[tempTable_memopt_hash] PK__tempTabl__3ED0478731BB5AF0 131072 130076 99 1 3
更新
我将包含用于创建过程、表等的最终测试用例和 sql 代码。我已经在空数据库上执行了测试。
SQL 代码:https://pastebin.com/9K6SgAqZ
测试用例:https://pastebin.com/ckSTnVqA
我的最后一次运行看起来像这样(临时表是最快的表,但我能够使用内存优化表变量实现最快的时间):
Start CrudTest_TempTable 2019-11-18 10:45:02.983
Beginning execution loop
Batch execution completed 1000 times.
Finish CrudTest_TempTable 2019-11-18 10:45:09.537
Start CrudTest_SpidFilter_memopt_hash 2019-11-18 10:45:09.537
Beginning execution loop
Batch execution completed 1000 times.
Finish CrudTest_SpidFilter_memopt_hash 2019-11-18 10:45:27.747
Start CrudTest_memopt_hash 2019-11-18 10:45:27.747
Beginning execution loop
Batch execution completed 1000 times.
Finish CrudTest_memopt_hash 2019-11-18 10:45:46.100
Start CrudTest_tableVar 2019-11-18 10:45:46.100
Beginning execution loop
Batch execution completed 1000 times.
Finish CrudTest_tableVar 2019-11-18 10:45:47.497
【问题讨论】:
请用选择@@version的结果更新您的问题 使用内存表的代码在哪里?它们是如何创建的?您收到错误的事实非常强烈表明该代码有问题 @sepupic在问题开头添加了sql版本 @PanagiotisKanavos 检查创建表 tempTable_memopt_hash @empi 发布这么多代码意味着大部分代码都被隐藏了。 【参考方案1】:恕我直言,OP 中的测试无法显示memory-optimized
表的优势
因为这些表的最大优点是它们是lock-and-latch free
,这意味着您的update
/insert
/delete
根本不使用locks
,这允许对这些tables
进行并发更改。
但是所做的测试根本不包括并发更改,显示的代码在一个session
中进行了所有更改。
另一个观察结果:在table
上定义的hash index
是错误的,因为您只在one column
上搜索,而哈希索引在two columns
上定义。两列上的哈希索引意味着 hash function
应用于两个参数,但您只搜索一列,因此无法使用 hash index
。
您认为通过使用 mem opt 表可以获得性能吗 对临时表的改进还是只是为了限制 tempdb 上的 IO?
Memory-optimized tables
不应该替代temporary tables
,如前所述,您将在高度并发 OLTP
环境中看到利润,而您猜temporary table
仅可见到您的会话,根本没有并发。
消除闩锁。所有 In-Memory OLTP 内部数据结构都是无闩锁和无锁。内存中 OLTP 使用新的 多版本并发控制(MVCC)提供事务 一致性。从用户的角度来看,它的行为类似于 常规 SNAPSHOT 事务隔离级别;然而,它确实 不要在引擎盖下使用锁定。 此架构允许多个会话 使用相同的数据而不会相互锁定和阻塞 并提高了系统的可扩展性,允许充分利用 现代多 CPU/多核硬件。
被引书籍:Dmitri Korotkevitch 的 Pro SQL Server Internals
你怎么看标题“Faster temp table and table 使用内存优化变量”
我打开了这篇文章,看到了这些例子(按照它们在文章中的顺序)
A.内存优化表变量的基础知识 乙。场景:替换全局 tempdb ##table C.场景:替换会话 tempdb #tableA.我只在它们包含很少行的情况下使用table variables
。为什么我还要关心这几行?
B.替换 global tempdb ##table
。我根本不使用它们。
C.替换session tempdb #table
。如前所述,session tempdb #table
对任何其他会话都不可见,那么有什么好处呢?数据不进入磁盘?如果您真的对tempdb
有问题,您是否应该为tempdb
考虑最快的SSD 磁盘?从 2014 年开始,tempdb 对象不一定会转到 disk
,即使是 bulk inserts
,无论如何我什至在我的数据库上启用了 RCSI
,并且 tempdb
没有问题。
【讨论】:
你觉得标题“使用内存优化更快的临时表和表变量”docs.microsoft.com/en-us/sql/relational-databases/…?它特别指出:“如果您使用临时表、表变量或表值参数,请考虑对其进行转换以利用内存优化表和表变量来提高性能。”你觉得有可能吗? >>>你认为有可能吗 我看到了内存优化表的好处。正如文章所述,我现在只关注用 mem opt 表替换临时表的问题。在我的测试用例中,它们简单得多,而且不值得(或者如果你真的需要在 tempdb 上减少 io)。 @empi >>>但我不认为以“你的问题是你不明白......”开头很酷,你是对的,我会改变它【参考方案2】:可能不会看到性能改进,仅在非常特殊的应用程序中。 SQL 过去曾涉足诸如“pin table”之类的东西,但优化器根据实际活动选择内存中的页面,可能几乎适用于所有情况。几十年来,这一直是性能调整。我认为“在记忆中”更像是一个营销接触点,而不是任何实际用途。请证明我错了。
【讨论】:
以上是关于SQL Server 内存优化表 - 与临时表相比性能较差的主要内容,如果未能解决你的问题,请参考以下文章
在某些情况下,为什么CTE(公用表表达式)与SQL Server中的临时表相比会减慢查询速度