Configuração atual:
Temos uma tabela muito grande que possui um campo bigint pk e um campo nvarchar(1025). O único índice é o PK. Temos outra tabela que é bigint_fk para a primeira tabela com uma soma de verificação do campo string.
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
)
);
Então você pode consultar algo como:
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>'
A mesa émuitogrande.
Temos um servidor muito caro com 1,9 TB de RAM na Amazon rodando tudo isso. Versão:
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)
No entanto, se adicionarmos mais de 900 GB de RAM, o desempenho cai repentinamente. E a consulta acima começa a ler grandes quantidades de dados. Eu sei que ao alterar a memória máxima, o cache será limpo, mas ele nunca se recuperará até que diminuamos a memória RAM máxima e reinicializemos.
Não há mais nada neste servidor.
Pelo que posso dizer, os planos de consulta são os mesmos, mas é difícil confirmar porque não podemos colocá-lo nesse estado de inatividade com muita frequência, criando interrupções no cliente.
O que não entendo é como adicionar RAM prejudica o desempenho.
Responder1
Talvez tente não executar uma função nas coisas e talvez considere particionar por uma chave útil, se ainda não o fez.
O que uma explicação diz?
Espero que ajude ou desperte ideias. Aliás: Caramba. isso deve ser caro com a AWS. Essa é uma quantidade absurda de RAM.