
現在の設定:
bigint pk と nvarchar(1025) フィールドを持つ非常に大きなテーブルがあります。唯一のインデックスは PK です。文字列フィールドのチェックサムを持つ最初のテーブルへの bigint_fk である別のテーブルがあります。
create table BigStringTable (
id bigint identity(1,1) not null,
dataString nvarchar(1025) not null,
primary key clustered (id));
);
create table BigStringTableHashes(
id bigint not null,
dataStringHash int not null,
CONSTRAINT [PK_dataStringHash] PRIMARY KEY NONCLUSTERED
(
[claid] dataStringHash
)
);
したがって、次のようなクエリを実行することになります。
SELECT datastring FROM BigStringTable AS bst
JOIN BigStringTableHashes AS hashes ON bst.id = hashes.id
WHERE hashes.dataStringHash = checksum(<Whatever String>) AND bst.dataString = '<Whatever String>'
テーブルはとても大きい。
私たちは、これらすべてを実行するために、Amazon に 1.9 TB の RAM を搭載した非常に高価なサーバーを設置しています。バージョン:
Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) Nov 30 2018 12:57:58 Copyright (C) 2017 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Datacenter 10.0 <X64> (Build 17763: ) (Hypervisor)
ただし、約 900 GB を超える RAM を追加すると、パフォーマンスが突然低下して停止します。また、上記のクエリは大量のデータを読み取り始めます。最大メモリを変更するとキャッシュがクリアされることはわかっていますが、最大 RAM を下げて再起動するまで回復することはありません。
このサーバーには他には何もありません。
私の知る限り、クエリ プランは同じですが、頻繁にこの非パフォーマンス状態に陥って顧客の停止を引き起こすことはできないため、確認するのは困難です。
私が理解できないのは、RAM を追加するとパフォーマンスが損なわれるということです。
答え1
まだ行っていない場合は、関数を実行しないようにして、便利なキーによるパーティション分割を検討してください。
説明には何と書いてあるのですか?
これが役に立ったり、アイデアが浮かんだりすることを願います。ところで、すごいですね。AWS だと高価になるはずです。これはとんでもない量の RAM です。