Tenho a puncturestabela com o extentatributo do tsrangetipo e preciso inserir um registro com final aberto extentcom limite inferior como a hora atual ( now()). tentei
INSERT INTO punctures(extent)
VALUES(tsrange(now(), ));
e variações disso, mas todas geram um erro.
Como posso definir o tsrange?
Portanto, temos usado um servidor de banco de dados robusto há pouco mais de 7 anos. No ano passado, começamos a mudar para um novo servidor que é essencialmente melhor em todos os aspectos, fazendo a transição de um banco de dados por vez. Há um banco de dados em particular que mudamos para o novo servidor e as coisas ficaram ruins...
Mesmo sob carga baixa a moderada, as consultas começaram a atingir o tempo limite, o desempenho neste banco de dados e em outros que já haviam sido transferidos era visivelmente mais lento em quase todos os aspectos até fazermos a transição de volta para o servidor original. Depois disso, o desempenho no novo servidor se estabilizou e o banco de dados com problemas ficou bom no servidor original.
Alguns detalhes seriam úteis!
A configuração do servidor é quase idêntica, exceto onde faz sentido devido a variações de hardware (Max RAM). Aqui estão as capturas de tela:
*Ativar bancos de dados independentes não está habilitado no novo servidor, no entanto, não utilizamos esse recurso.
**Antes de começarem os comentários, percebi que o CTFP é ultrajante, isso é outra bola de cera.
Em particular, ao revisar nossas ferramentas de monitoramento, notamos valores desproporcionais ao comparar as seguintes métricas obtidas em sys.dm_os_performance_counters:
Fico feliz em fornecer detalhes/gráficos adicionais se isso ajudar.
O banco de dados em questão tem um tamanho decente, mas é grande para nós (120 GB), mas possui muitos gravadores ativos em uma aplicação OLTP. Existem muitas divisões de páginas envolvidas neste banco de dados em particular.
Academicamente, tudo sobre o novo servidor deve ser capaz de lidar com a carga do servidor antigo e muito mais.
Todas essas informações para fazer estas perguntas:
Agradecemos antecipadamente por se juntar a mim na loucura!
ATUALIZAÇÃO 1
Executamos o incrível script SQL Server Index and Statistics Maintentnce de Ola Hallengren todas as noites, reorganizando cada tabela com 5% de fragmentação e reconstruindo com 30% de fragmentação E atualizando as estatísticas INDEX. Isso é executado pelo SQL Agent em cada servidor sem erros.
ATUALIZAÇÃO 2
Depois de dedicar algum tempo para desenvolver maneiras de replicar a carga que estávamos definindo sem impactar o cliente, começamos a testar várias teorias. O vencedor foi @StrayCatDBA que deu o call com as configurações de energia. As opções de energia balanceadas acabaram estacionando muitos de nossos núcleos, o servidor nunca estava sob carga suficiente para superar esse afogamento, mas foi o suficiente para fazer com que o servidor lutasse o suficiente para impactar as cargas de trabalho.
Agradeço a todos que dedicaram algum tempo e colaboraram. Alguns dos comentários foram úteis no curto prazo e alguns deles ajudaram a iniciar o processo de refatoração de algumas de nossas consultas mais "agressivas" (e as práticas necessárias para compensar) .
Existe uma maneira de monitorar índices no Oracle 19c?
Ativei o monitoramento de índice
ALTER INDEX my_index_i MONITORING USAGE;
Usando as consultas abaixo para ter uma ideia aproximada de quando um índice foi usado:
SELECT index_name,
table_name,
monitoring,
used,
start_monitoring,
end_monitoring
FROM dba_object_usage
WHERE index_name = 'name'
AND owner = 'name'
ORDER BY index_name;
SELECT name, owner, TO_CHAR(last_used, 'YYYY-MM-DD HH24:MI:SS') AS "Last Used"
FROM dba_index_usage
WHERE name = 'name';
O problema é que ainda não consigo dizer quantas vezes um índice foi usado em um dia e também a que horas ele estava sendo usado.
Existe uma forma/consulta de monitorar tal cenário?
PS: Eu sei sobre gatilhos, mas estou procurando uma alternativa - se eu não conseguir uma alternativa, então é Triggers!
Desde já, obrigado!
dr: Quando usar array_agguma junção lateral com subconsulta de array?
Contexto:
create table t_zipcode ( zipcode text primary key, location geography );
create table t_user ( id text primary key, zipcode text references t_zipcode);
Quero criar uma consulta que obtenha todos os CEPs 'próximos' de cada usuário, digamos, em um intervalo de 20 km. Minha primeira tentativa foi assim:
select u.id, z.zipcode, z.location, array_agg(zz.zipcode order by zz.zipcode) as nearby_zipcodes
from t_user u
join t_zipcode z on u.zipcode = z.zipcode
left join t_zipcode zz on st_dwithin(z.location, zz.location, 20000)
group by u.id, z.zipcode, z.location
order by u.id;
que retorna resultados como este:
+------------------------------------+-------+--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|id |zipcode|location |nearby_zipcodes |
+------------------------------------+-------+--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|0233684d-d2d8-4fdc-863f-08c6aac79d92|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|0e59fd58-00a5-442e-a21e-16ab1f4d2f65|85226 |0101000020E6100000506EDBF7A8005CC016A243E048A04040|{85034,85040,85041,85042,85044,85045,85048,85121,85202,85224,85225,85226,85248,85282,85283,85284,85286,85339} |
|13f26eca-bda0-4b8f-bcff-c95cceee3421|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|2d69e6bd-e0f0-40aa-ba3a-0e157fff46ff|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|4bd8e913-7a75-4028-8254-faebf043f629|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|627897e0-595c-4d21-b1b1-8dd43f21dee7|85033 |0101000020E6100000DAC69FA86C0D5CC08E78B29B19BF4040|{85003,85004,85006,85007,85009,85012,85013,85014,85015,85016,85017,85019,85020,85021,85023,85029,85031,85033,85034,85035,85037,85040,85041,85043,85051,85053,85064,85301,85302,85303,85304,85305,85306,85307,85308,85309,85323,85335,85340,85345,85351,85353,85363,85378,85379,85381,85382,85392,85395} |
|6353efe7-b0e0-42a2-b5fd-f38b7c8e27ad|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|6efad24b-10a7-4ac7-b91a-8842bca70c06|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|7f1fe1d1-e2cd-44b9-85f0-b3b888823a20|85305 |0101000020E6100000BF7D1D3867105CC0D2C6116BF1C34040|{85003,85004,85007,85009,85012,85013,85014,85015,85017,85019,85020,85021,85023,85029,85031,85033,85035,85037,85043,85051,85053,85080,85301,85302,85303,85304,85305,85306,85307,85308,85309,85323,85335,85340,85345,85351,85353,85355,85363,85373,85374,85375,85378,85379,85381,85382,85388,85392,85395} |
|9c238c4a-712b-4b10-a91d-6c3548ae59bc|86001 |0101000020E6100000054F2157EAE85BC0D6AA5D13D2A44140|{86001,86011,86015} |
|ace88100-9ecd-4931-a617-b8d8b091470e|85007 |0101000020E6100000CB30EE06D1055CC0AA9D616A4BB94040|{85003,85004,85006,85007,85008,85009,85012,85013,85014,85015,85016,85017,85018,85019,85020,85021,85028,85029,85031,85033,85034,85035,85037,85040,85041,85042,85043,85044,85045,85048,85051,85064,85251,85253,85257,85281,85282,85283,85284,85301,85302,85303,85304,85305,85353} |
|bf96321b-be2e-4ef9-801e-9ee82ce693f4|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|d787537e-a3fa-4267-b313-71b2c07027fe|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|ea8d074d-adb1-4c45-bd02-b6b57f5a6604|41091 |0101000020E61000005B0A48FB1F2F55C063D009A183744340|{41005,41018,41030,41042,41051,41080,41091,41092,41094,41095,47020,47038,47040} |
|f925949e-6a5e-4e2c-9591-60f05f42ccb1|81001 |0101000020E6100000C4245CC823225AC025E7C41EDA254340|{81001,81003,81006,81008,81025} |
|fc47120d-d3da-4847-8134-0eca87708467|98102 |0101000020E61000001C78B5DC99945EC09A7CB3CD8DD14740|{98004,98005,98006,98007,98008,98011,98020,98021,98028,98033,98034,98036,98039,98040,98043,98052,98056,98057,98072,98101,98102,98103,98104,98105,98106,98107,98108,98109,98110,98112,98115,98116,98117,98118,98119,98121,98122,98125,98126,98133,98134,98136,98144,98146,98154,98155,98164,98168,98174,98177,98178,98195,98199,98342,98353}|
+------------------------------------+-------+--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Este é o plano analisado com apenas 16 usuários E usando um índice na coluna de localização do CEP:
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
|GroupAggregate (cost=85365.87..86252.54 rows=35467 width=112) (actual time=1.932..2.474 rows=16 loops=1) |
| Output: u.id, z.zipcode, z.location, array_agg(zz.zipcode ORDER BY zz.zipcode) |
| Group Key: u.id, z.zipcode, z.location |
| -> Sort (cost=85365.87..85454.53 rows=35467 width=112) (actual time=1.887..1.913 rows=277 loops=1) |
| Output: u.id, z.zipcode, z.location, zz.zipcode |
| Sort Key: u.id, z.zipcode, z.location |
| Sort Method: quicksort Memory: 53kB |
| -> Nested Loop Left Join (cost=0.69..81507.59 rows=35467 width=112) (actual time=0.197..1.641 rows=277 loops=1) |
| Output: u.id, z.zipcode, z.location, zz.zipcode |
| -> Nested Loop (cost=0.29..719.73 rows=1070 width=80) (actual time=0.043..0.136 rows=16 loops=1) |
| Output: u.id, z.zipcode, z.location |
| Inner Unique: true |
| -> Seq Scan on pg_temp.t_user u (cost=0.00..20.70 rows=1070 width=48) (actual time=0.017..0.021 rows=16 loops=1) |
| Output: u.id, u.zipcode |
| -> Index Scan using test_idx_user_zip on pg_temp.t_zipcode z (cost=0.29..0.65 rows=1 width=64) (actual time=0.006..0.006 rows=1 loops=16)|
| Output: z.zipcode, z.location |
| Index Cond: (z.zipcode = u.zipcode) |
| -> Index Scan using test_idx_zip_geo on pg_temp.t_zipcode zz (cost=0.40..75.47 rows=3 width=64) (actual time=0.040..0.089 rows=17 loops=16) |
| Output: zz.zipcode, zz.location |
| Index Cond: (zz.location && _st_expand(z.location, '20000'::double precision)) |
| Filter: st_dwithin(z.location, zz.location, '20000'::double precision, true) |
| Rows Removed by Filter: 8 |
|Query Identifier: -2358650375080684395 |
|Planning Time: 0.421 ms |
|Execution Time: 2.649 ms |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
Em seguida, tentei uma solução semelhante usando uma junção lateral, que produz exatamente os mesmos resultados:
select u.id, z.zipcode, z.location, t.nearby_zipcodes
from t_user u
join t_zipcode z on u.zipcode = z.zipcode
cross join lateral (select array(select zz.zipcode
from t_zipcode zz
where st_dwithin(z.location, zz.location, 20000)
order by zz.zipcode) as nearby_zipcodes
) t
order by u.id;
que para minha surpresa, tem desempenho um pouco melhor:
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
|Sort (cost=85823.88..85826.55 rows=1070 width=112) (actual time=1.828..1.830 rows=16 loops=1) |
| Output: u.id, z.zipcode, z.location, ((SubPlan 1)) |
| Sort Key: u.id |
| Sort Method: quicksort Memory: 30kB |
| -> Nested Loop (cost=0.29..85770.04 rows=1070 width=112) (actual time=0.319..1.809 rows=16 loops=1) |
| Output: u.id, z.zipcode, z.location, (SubPlan 1) |
| Inner Unique: true |
| -> Seq Scan on pg_temp.t_user u (cost=0.00..20.70 rows=1070 width=48) (actual time=0.012..0.016 rows=16 loops=1) |
| Output: u.id, u.zipcode |
| -> Index Scan using test_idx_user_zip on pg_temp.t_zipcode z (cost=0.29..0.65 rows=1 width=64) (actual time=0.006..0.006 rows=1 loops=16) |
| Output: z.zipcode, z.location |
| Index Cond: (z.zipcode = u.zipcode) |
| SubPlan 1 |
| -> Sort (cost=79.48..79.49 rows=3 width=32) (actual time=0.101..0.102 rows=17 loops=16) |
| Output: zz.zipcode |
| Sort Key: zz.zipcode |
| Sort Method: quicksort Memory: 25kB |
| -> Index Scan using test_idx_zip_geo on pg_temp.t_zipcode zz (cost=0.40..79.45 rows=3 width=32) (actual time=0.032..0.080 rows=17 loops=16)|
| Output: zz.zipcode |
| Index Cond: (zz.location && _st_expand(z.location, '20000'::double precision)) |
| Filter: st_dwithin(z.location, zz.location, '20000'::double precision, true) |
| Rows Removed by Filter: 8 |
|Query Identifier: 8776498431209157273 |
|Planning Time: 0.257 ms |
|Execution Time: 1.892 ms |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
Fiquei com a impressão de que as junções laterais deveriam ser evitadas em geral, sempre que possível. Há algum demérito que não estou percebendo?
Eu tenho uma tabela SQL bastante simples (atualmente Azure SQL, pode ficar lá ou acabar na instância local do SQL Server 19, se isso for importante), cerca de 100.000 registros, que são principalmente para leitura, mas serão gravados gradualmente.
CREATE TABLE [dbo].[xCatalog](
[catalogID] [int] IDENTITY(1,1) NOT NULL,
[title] [nvarchar](255) NOT NULL,
[dateA] [datetime] NULL,
[dateB] [datetime] NULL,
[textA] [nvarchar](25) NULL,
[textB] [nvarchar](255) NULL,
[textC] [nvarchar](255) NULL,
CONSTRAINT [PK_xCatalog] PRIMARY KEY CLUSTERED
(
[catalogID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
Digno de nota é o campo [title] nvarchar(255) , que será o que os usuários pesquisarão principalmente usando uma consulta formatada como abaixo usando "oceano" como termo de pesquisa de exemplo [title]
SELECT TOP(500) [catalogID],[title],[dateA],[dateB],[textA],[textB],[textC]
FROM [dbo].[xCatalog]
WHERE ([title] LIKE '%ocean%')
ORDER BY [catalogID] ASC
Ele funciona razoavelmente bem, de 1 a 3 segundos, mas estou realmente interessado em mergulhar em como/se melhorá-lo, pois, francamente, tenho mais do que apenas uma compreensão superficial de coisas como índices e outras otimizações.
A consulta está sendo gerada por um programa front-end que não acredito que possa alterar, por isso está selecionando uma quantidade limitada classificada pela chave para retornar à rolagem virtual e por que não estou explorando a substituição de LIKE por Contém ou qualquer coisa assim.
Então, estou realmente tentando chegar a isso do lado do banco de dados e apenas entender quais seriam as melhores práticas e quais são as opiniões das pessoas sobre esse tipo de caso, no que diz respeito a que tipo de índice usar ou se mudar para ColumnStore seria aplicável (provavelmente muito pequeno?), etc. Também estamos usando um banco de dados SQL do Azure de nível básico, então talvez para esse tipo de operação nos beneficiássemos de aumentar um pouco isso.
Qualquer coisa assim para que eu possa saber daqui para frente e poder explicar com segurança que fiz x ou y para ajudá-lo, mas também talvez a pesquisa de caracteres curinga em texto grande às vezes seja cara, então quais deveriam ser minhas expectativas.
Apresentarei o plano de execução simples, caso seja útil:
Obrigado a todos pela contribuição! Eu sei que há muitas perguntas semelhantes que continuarei pesquisando, mas às vezes parece que são um pouco diferentes e imagino qual é o mal em perguntar também.
Estou tendo um problema ao revogar privilégios que me impede de descartar usuários
select usename, acl.*
from pg_default_acl as acl join pg_user on usesysid = defacluser
where usename = 'user1';
me dá:
|usename|defacluser|defaclnamespace|defaclobjtype|defaclacl |
|-------|----------|---------------|-------------|----------------------|
|user1 |143 |0 |r |{user1=awdRxt/user1}|
Com uma view fornecida pela amazon( v_get_obj_priv_by_user) eu executo isso para obter os esquemas/bancos de dados com permissões para este usuário:
select 'alter table '+schemaname+'.'+tablename+' owner to y;' from pg_tables where tableowner like 'user1';
select distinct 'revoke all on schema '+schemaname+' from user1;' from admin.v_get_obj_priv_by_user where usename like 'user1';
select distinct 'revoke all on all tables in schema '+schemaname+' from user1;' from admin.v_get_obj_priv_by_user where usename like 'user1'
Recebi estas 2 respostas de consultas anteriores
revoke all on schema xxx from user1;
revoke all on all tables in schema xxx from user1;
Executei-os, não tenho erros, mas as permissões ainda estão lá e as consultas usando v_get_obj_priv_by_usercontinuam retornando os mesmos resultados.
Obviamente, quando mais tarde tento descartar o usuário, recebo este erro:
Erro SQL [2BP01]: ERRO: o usuário "usuário1" não pode ser eliminado porque alguns objetos dependem dele Detalhe: proprietário de privilégios padrão em novas relações pertencentes ao usuário usuário1
Alguma ideia do que eu poderia estar fazendo de errado? Obrigado!
Não sou um grande especialista em SQL, então preciso da ajuda da comunidade.
Eu tenho as seguintes tabelas simplificadas.
CREATE TABLE "Keyspace" (
"id" SERIAL NOT NULL,
"tenantId" INTEGER NOT NULL,
"name" TEXT NOT NULL,
CONSTRAINT "Keyspace_pkey" PRIMARY KEY ("id")
);
CREATE TABLE "Project" (
"id" SERIAL NOT NULL,
"tenantId" INTEGER NOT NULL,
"name" TEXT NOT NULL,
"keyspaceId" INTEGER NOT NULL,
CONSTRAINT "Project_pkey" PRIMARY KEY ("id")
);
CREATE TABLE "Entry" (
"id" SERIAL NOT NULL,
"tenantId" INTEGER NOT NULL,
"projectId" INTEGER NOT NULL,
CONSTRAINT "Entry_pkey" PRIMARY KEY ("id")
);
CREATE TABLE "KeyspaceEntry" (
"keyspaceId" INTEGER NOT NULL,
"entryId" INTEGER NOT NULL,
"number" INTEGER NOT NULL
);
Só se Entrypode estar em um Keyspace. Isso é aplicado por Entry-> Project-> Keyspacereferência.
Um Keyspaceterá muitos Entries.
O campo importante é KeyspaceEntry.number. Este é o número incrementado automaticamente para cada entrada no mesmo Keyspace.
Exemplo:
1, 2,31,2number=4.Preciso implementar a inserção atômica para Entry e KeyspaceEntry com incremento numberna mesma transação.
Nota: Pode parecer desnecessário ter a tabela KeyspaceEntry porque você pode simplesmente adicionar numberpropriedades à Entrada, mas este é um modelo simplificado. Quero ter um histórico de todos os relacionamentos Keyspace-Entry para o caso em que uma entrada é movida para um projeto diferente em um keyspace diferente.
Outra opção pode ser criar uma tabela histórica mas mantendo a Entry.numberpropriedade real. Pode ser melhor para consultar entradas (será usado para selecionar entradas individuais por KeyspaceID + EntryNumber). Posso considerar isso mais tarde também. Por favor, compartilhe se você tem opinião sobre esta mudança de design.
Estou usando PostgreSQL 16
Temos um servidor de banco de dados onde o banco de dados de teste é “atualizado” com o backup do banco de dados prod todos os dias às 22h.
O primeiro backup após a restauração é um backup diferencial, pois estamos usando o ChangeBackupType = Yswitch.
Nosso CleanupTimeparâmetro está definido para 48 horas, o que funciona bem para backups completos e TLog.
No entanto, o CleanupTimeparâmetro não funciona para os backups Diff criados porque está ChangeBackupTypedefinido como Y.
Alguma idéia de onde está o problema? Não usamos explicitamente a tarefa de backups Diff, portanto não há nada que CleanupTimeeu possa definir.
Definição Backup Completo
sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d aspMaintenance -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'ALL_DATABASES', @BackupType = 'FULL', @NumberOfFiles = 1, @Verify = 'N', @CleanupTime = 42, @CheckSum = 'Y', @DirectoryStructure = '{DatabaseName}{DirectorySeparator}{BackupType}_{Partial}_{CopyOnly}', @LogToTable = 'Y'" -b
Backup de log de definição
sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d aspMaintenance -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'ALL_DATABASES', @ChangeBackupType = 'Y', @BackupType = 'LOG', @Verify = 'N', @CleanupTime = 48, @CheckSum = 'Y', @DirectoryStructure = '{DatabaseName}{DirectorySeparator}{BackupType}_{Partial}_{CopyOnly}', @LogToTable = 'Y'" -b
Sempre pensei que a função CONCAT fosse na verdade um wrapper sobre o + (Concatenação de Strings) com algumas verificações adicionais para facilitar nossa vida.
Não encontrei nenhum detalhe interno sobre como as funções são implementadas. Quanto ao desempenho, parece que há sobrecarga para chamar CONCATquando os dados estão concatenando em um loop (o que parece normal, pois há identificadores adicionais para NULLs).
Há poucos dias, um desenvolvedor modificou algum código de concatenação de strings (de +para CONCAT)porque não gostou da sintaxe e me disse que ficou mais rápido.
Para verificar o caso, usei o seguinte código:
DECLARE @V1 NVARCHAR(MAX)
,@V2 NVARCHAR(MAX)
,@V3 NVARCHAR(MAX);
DECLARE @R NVARCHAR(MAX);
SELECT @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);
onde esta é a variante um:
SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}');
SELECT LEN(@R); -- 1200000017
e esta é a variante dois:
SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}'))
SELECT LEN(@R); -- 1200000017
Para strings menores, não há diferenças. Em algum momento, a CONCATvariante se torna mais rápida:
Eu me pergunto se alguém pode compartilhar alguns detalhes internos ou explicar o comportamento, pois parece que pode haver uma regra de que é melhor concatenar strings grandes usando CONCAT.
Versão:
Microsoft SQL Server 2022 (RTM-CU8) (KB5029666) - 16.0.4075.1 (X64) 23 de agosto de 2023 14:04:50 Copyright (C) 2022 Microsoft Corporation Standard Edition (64 bits) no Windows Server 2019 Standard 10.0 (Build 17763 : ) (Hipervisor)
O script exato é semelhante ao seguinte:
DECLARE @V1 NVARCHAR(MAX)
,@V2 NVARCHAR(MAX)
,@V3 NVARCHAR(MAX);
DECLARE @R NVARCHAR(MAX);
SELECT @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);
--SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}'); -- 00:00:45 -- 00:01:22 -- 00:01:20
--SELECT LEN(@R); -- 300000017
SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}')) -- 00:00:11 -- 00:00:16 -- 00:00:10
SELECT LEN(@R); -- 300000017
onde estou alterando o último argumento das funções REPLICATE para gerar strings maiores para a concatenação. Então, estou executando cada variante três vezes.
Dadas as seguintes tabelas:
CREATE TABLE #a
(
MyInt INT
)
INSERT INTO #a VALUES(1),(2),(3),(4),(5),(6),(7),(8),(9),(10)
CREATE TABLE #b
(
MyVarchar VARCHAR(10)
)
INSERT INTO #b VALUES('1'),('2'),('3'),('4'),('5'),('6'),('7'),('8'),('9'),('ten')
Se eu executar a seguinte consulta;
SELECT *
FROM #a
LEFT JOIN #b
ON #a.MyInt = #b.MyVarchar
O SQL Server precisa executar uma conversão implícita, pois #a.MyIntsão #b.MyVarchartipos de dados incompatíveis. Devido à precedência do tipo de dados, a coluna com a precedência de tipo mais baixa (#b.MyVarchar) é convertida para o tipo de precedência mais alta (INT)
Isso significa que a consulta acima se torna equivalente a
SELECT *
FROM #a
LEFT JOIN #b
ON #a.MyInt = CONVERT(INT,#b.MyVarchar)
e ambos falham porque há um valor #b.MyVarcharinválido para uma INTcoluna.
Minha pergunta é por que VARCHARtem uma precedência menor que INT? se fosse o contrário, a conversão implícita seria bem-sucedida, mas em vez disso obteríamos uma consulta com erros. Por que um erro seria preferido a uma execução bem-sucedida? Meu palpite seria algo como este ser mais um mecanismo "defensivo" por parte do SQL Server - ele prefere um erro e, portanto, precisa que o usuário decida explicitamente o que deseja fazer, em vez de fornecer resultados de consulta talvez inesperados, sem que o usuário seja Cientes?