Meu professor me ensinou esta instrução SQL:
SELECT COUNT(length) FROM product
retornará 2com o seguinte conjunto de dados:
product
|id | length | code |
|-------------------|
| 1 | 11 | X00 |
| 2 | 11 | C02 |
| 3 | 40 | A31 |
Ela justificou dizendo que COUNTnão conta duplicatas. Eu discordei. Depois de tentar muitos DBMS, nunca encontrei um que tenha esse comportamento. Esse SGBD existe?
Enquanto escrevo isso, ainda estou aguardando o lançamento oficial do SQL Server 2016 para que possamos explorar a utilidade de seu recurso "Always Encrypted".
Gostaria apenas de saber quais serão as diferenças específicas entre o Always Encrypted e o Transparent Data Encryption atualmente disponível no SQL Server 2016 para que possamos tomar a decisão correta para projetos futuros.
Eu tenho uma consulta bastante simples
SELECT TOP 1 dc.DOCUMENT_ID,
dc.COPIES,
dc.REQUESTOR,
dc.D_ID,
cj.FILE_NUMBER
FROM DOCUMENT_QUEUE dc
JOIN CORRESPONDENCE_JOURNAL cj
ON dc.DOCUMENT_ID = cj.DOCUMENT_ID
WHERE dc.QUEUE_DATE <= GETDATE()
AND dc.PRINT_LOCATION = 2
ORDER BY cj.FILE_NUMBER
Isso está me dando um desempenho horrível (como nunca se preocupou em esperar que terminasse). O plano de consulta tem esta aparência:
No entanto, se eu removê- TOP 1lo, obtenho um plano parecido com este e é executado em 1 a 2 segundos:
PK correto e indexação abaixo.
O fato de ter TOP 1mudado o plano de consulta não me surpreende, estou apenas um pouco surpreso por torná-lo muito pior.
Observação: li os resultados desta postagem e entendi o conceito de a Row Goaletc. O que estou curioso é como posso alterar a consulta para que ela use o plano melhor. Atualmente, estou despejando os dados em uma tabela temporária e extraindo a primeira linha dela. Eu estou querendo saber se existe um método melhor.
Editar Para as pessoas que estão lendo isso depois do fato, aqui estão algumas informações extras.
Quando comecei não havia outros índices. Acabei com um em Correspondence_Journal (Document_Id, File_Number)
É aceitável ter uma referência circular entre duas tabelas no campo de chave estrangeira?
Se não, como essas situações podem ser evitadas?
Se sim, como os dados podem ser inseridos?
Abaixo está um exemplo de onde (na minha opinião) uma referência circular seria aceitável:
CREATE TABLE Account
(
ID INT PRIMARY KEY IDENTITY,
Name VARCHAR(50)
)
CREATE TABLE Contact
(
ID INT PRIMARY KEY IDENTITY,
Name VARCHAR(50),
AccountID INT FOREIGN KEY REFERENCES Account(ID)
)
ALTER TABLE Account ADD PrimaryContactID INT FOREIGN KEY REFERENCES Contact(ID)
Eu tenho um esquema legado (isenção de responsabilidade!) Que usa um ID gerado com base em hash para a chave primária de todas as tabelas (existem muitas). Um exemplo desse id é:
922475bb-ad93-43ee-9487-d2671b886479
Não há esperança possível de mudar essa abordagem, no entanto, o desempenho com acesso ao índice é ruim. Deixando de lado a miríade de razões que isso pode ser, há uma coisa que notei que parecia menos do que ideal - apesar de todos os valores de id em todas as tabelas terem exatamente 36 caracteres de comprimento, o tipo de coluna é varchar(36), não char(36) .
A alteração dos tipos de coluna para comprimento fixo char(36)ofereceria algum benefício significativo de desempenho de índice, além do aumento muito pequeno no número de entradas por página de índice, etc.?
Ou seja, o postgres executa muito mais rápido ao lidar com tipos de comprimento fixo do que com tipos de comprimento variável?
Por favor, não mencione a minúscula economia de armazenamento - isso não será importante em comparação com a cirurgia necessária para fazer a alteração nas colunas.
Antigamente, era considerado um grande não-não a fazer select * from tableou select count(*) from tablepor causa do desempenho atingido.
Esse ainda é o caso em versões posteriores do SQL Server (estou usando 2012, mas acho que a pergunta se aplica a 2008 - 2014)?
Edit: Como as pessoas parecem estar me criticando um pouco aqui, estou olhando para isso de um ponto de vista acadêmico/referente, não se é a coisa "certa" a fazer (o que obviamente não é)
Quero entender por que haveria uma diferença tão grande na execução da mesma consulta no UAT (executado em 3 segundos) versus PROD (executado em 23 segundos).
Ambos UAT e PROD estão tendo exatamente dados e índices.
CONSULTA:
set statistics io on;
set statistics time on;
SELECT CONF_NO,
'DE',
'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
CONF_TARGET_NO
FROM CONF_TARGET ct
WHERE CONF_NO = 161
AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
AND ( ( REGISTRATION_TYPE = 'I'
AND (SELECT COUNT(1)
FROM PORTFOLIO
WHERE EMAIL_ADDRESS = ct.EMAIL_ADDRESS
AND DEACTIVATED_YN = 'N') > 1 )
OR ( REGISTRATION_TYPE = 'K'
AND (SELECT COUNT(1)
FROM CAPITAL_MARKET
WHERE EMAIL_ADDRESS = ct.EMAIL_ADDRESS
AND DEACTIVATED_YN = 'N') > 1 ) )
NO UAT:
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 11 ms, elapsed time = 11 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
(3 row(s) affected)
Table 'Worktable'. Scan count 256, logical reads 1304616, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PORTFOLIO'. Scan count 1, logical reads 84761, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 2418 ms, elapsed time = 2442 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
No PRO:
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
(3 row(s) affected)
Table 'PORTFOLIO'. Scan count 256, logical reads 21698816, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 23937 ms, elapsed time = 23935 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Observe que no PROD a consulta sugere um índice ausente e isso é benéfico como testei, mas esse não é o ponto de discussão.
Eu só quero entender que: ON UAT - por que o sql server cria uma tabela de trabalho e no PROD não? Ele cria um spool de tabela no UAT e não no PROD. Além disso, por que os tempos de execução são tão diferentes no UAT vs PROD?
Observação :
Estou executando o sql server 2008 R2 RTM em ambos os servidores (em breve irei corrigir com o SP mais recente).
UAT: Memória máxima de 8 GB. MaxDop, afinidade do processador e threads de trabalho máximo é 0.
Logical to Physical Processor Map:
*------- Physical Processor 0
-*------ Physical Processor 1
--*----- Physical Processor 2
---*---- Physical Processor 3
----*--- Physical Processor 4
-----*-- Physical Processor 5
------*- Physical Processor 6
-------* Physical Processor 7
Logical Processor to Socket Map:
****---- Socket 0
----**** Socket 1
Logical Processor to NUMA Node Map:
******** NUMA Node 0
PROD: memória máxima de 60 GB. MaxDop, afinidade do processador e threads de trabalho máximo é 0.
Logical to Physical Processor Map:
**-------------- Physical Processor 0 (Hyperthreaded)
--**------------ Physical Processor 1 (Hyperthreaded)
----**---------- Physical Processor 2 (Hyperthreaded)
------**-------- Physical Processor 3 (Hyperthreaded)
--------**------ Physical Processor 4 (Hyperthreaded)
----------**---- Physical Processor 5 (Hyperthreaded)
------------**-- Physical Processor 6 (Hyperthreaded)
--------------** Physical Processor 7 (Hyperthreaded)
Logical Processor to Socket Map:
********-------- Socket 0
--------******** Socket 1
Logical Processor to NUMA Node Map:
********-------- NUMA Node 0
--------******** NUMA Node 1
ATUALIZAR :
XML do Plano de Execução UAT:
XML do Plano de Execução do PROD:
UAT Execution Plan XML - com plano gerado para PROD:
Configuração do servidor:
PROD: PowerEdge R720xd - CPU Intel(R) Xeon(R) E5-2637 v2 @ 3,50 GHz.
UAT: PowerEdge 2950 - CPU Intel(R) Xeon(R) X5460 @ 3,16 GHz
Eu postei em answers.sqlperformance.com
Obrigado a @swasheck pela sugestão
Alterando a memória máxima no PROD de 60GB para 7680 MB, consigo gerar o mesmo plano no PROD. A consulta é concluída ao mesmo tempo que o UAT.
Agora eu preciso entender - POR QUÊ? Além disso, com isso, não poderei justificar este servidor monstro para substituir o servidor antigo!
Preciso consultar um banco de dados SQL para encontrar todos os valores distintos de uma coluna e preciso de um valor arbitrário de outra coluna. Por exemplo, considere a seguinte tabela com duas colunas, chave e valor:
key value
=== =====
one test
one another
one value
two goes
two here
two also
three example
Desejo recuperar uma linha de amostra, escolhida arbitrariamente, de cada chave distinta, talvez obtendo essas três linhas:
key value
=== =====
one test
two goes
three example
Como posso formular essa consulta em SQL?
(Isto foi sugerido para ser repost aqui do StackOverflow)
Atualmente tem uma tabela .. e precisa começar a adicionar novas colunas de dados a ela. Nem todo registro (mesmo avançando com novos dados após adicionar as novas colunas de dados) terá dados. Portanto, estou me perguntando se isso é mais adequado para uma nova tabela, pois é realmente uma extensão de algumas das linhas de dados e não se aplica a todas as linhas.
Em outras palavras, como haverá muitas colunas não utilizadas para esses novos elementos de dados, parece que isso seria mais adequado para uma nova tabela?
A primeira tabela é um registro de visualizações de página (atualmente 2 milhões de registros)
- Eu iria - Endereço de IP - vezes visto - created_at carimbo de data/hora - encontro
para cada endereço IP, um registro é feito por dia - e visualizações de página consecutivas são adicionadas às visualizações por dia
campo(s) adicional(is) seria(ão) para rastreamento de ponto de origem (ou seja, origem/mídia/campanha do Google Analytics)
Nem toda visita terá essa informação. Presumo que cerca de 10% das linhas terão os dados (já que geralmente são atribuídos apenas na primeira visita)
O principal uso dos dados seria atribuir de onde as pessoas vieram. Isso pode acabar sendo usado com mais frequência (o que parece se prestar à tabela única)
Agradeço o feedback - pode adicionar mais, se necessário
É possível que o parâmetro Table-Valued seja usado como parâmetro de saída para o procedimento armazenado?
Aqui está, o que eu quero fazer no código
/*First I create MY type */
CREATE TYPE typ_test AS TABLE
(
id int not null
,name varchar(50) not null
,value varchar(50) not null
PRIMARY KEY (id)
)
GO
--Now I want to create stored procedu whic is going to send output type I created,
--But it looks like it is inpossible, at least in SQL2008
create PROCEDURE [dbo].sp_test
@od datetime
,@do datetime
,@poruka varchar(Max) output
,@iznos money output
,@racun_stavke dbo.typ_test READONLY --Can I Change READONLY with OUTPUT ?
AS
BEGIN
SET NOCOUNT ON;
/*FILL MY OUTPUT PARAMS AS I LIKE */
end