{"id":1475,"date":"2018-10-24T15:30:45","date_gmt":"2018-10-24T15:30:45","guid":{"rendered":"https:\/\/www.tiagoneves.net\/blog\/?p=1475"},"modified":"2018-10-24T15:30:45","modified_gmt":"2018-10-24T15:30:45","slug":"voce-sabe-a-diferenca-entre-uma-consulta-sargable-e-non-sargable","status":"publish","type":"post","link":"https:\/\/www.tiagoneves.net\/blog\/voce-sabe-a-diferenca-entre-uma-consulta-sargable-e-non-sargable\/","title":{"rendered":"Voc\u00ea sabe a diferen\u00e7a entre uma consulta Sargable e Non-Sargable?"},"content":{"rendered":"

Ol\u00e1 pessoal tudo certo?<\/p>\n

No post de hoje vou compartilhar com voc\u00eas a respeito de um conceito muito comum no SQL Server, que \u00e9 o conceito de SARG (“S<\/strong>“ search argument<\/em>) e Non-SARGable cuja a tradu\u00e7\u00e3o livre pode ser “Argumento de busca<\/strong>“.<\/p>\n

O termo SARG<\/strong> nada mais \u00e9 que a coluna que voc\u00ea est\u00e1 utilizando como “predicate<\/strong>” na cl\u00e1usula WHERE<\/strong> se ela pode ser utilizada em uma opera\u00e7\u00e3o de “Index Seek<\/strong>“. J\u00e1 quando o nosso “predicate” N\u00c3O<\/strong> permite a opera\u00e7\u00e3o de “Index Seek”, podemos dizer que estamos utilizando um “predicate Non-Sargable<\/em>” e consequentemente teremos um custo maior<\/strong> para execu\u00e7\u00e3o da query.<\/p>\n

Vamos observar na pr\u00e1tica como isso funciona. Eu utilizei os scripts abaixo no banco AdventureWorks<\/strong>.<\/p>\n

--Vamos retornar todos os funcion\u00e1rios com o nome \"Paul\"\r\n\r\nSELECT B.FirstName,B.LastName,A.BirthDate\r\nFROM HumanResources.Employee A\r\nJOIN Person.Person B ON B.BusinessEntityID = A.BusinessEntityID\r\nWHERE B.FirstName = 'Paul'\r\n\r\n--Custo de execu\u00e7\u00e3o\r\nTable 'Employee'. Scan count 0, logical reads 18\r\nTable 'Person'. Scan count 1, logical reads 117\r\nSQL Server Execution Times:\r\n   CPU time = 0 ms,  elapsed time = 36 ms.<\/pre>\n
Observando o plano de execu\u00e7\u00e3o, podemos ver que o pr\u00f3prio SQL, nos sugere a cria\u00e7\u00e3o de um \u00edndice na coluna FirstName<\/strong>.<\/p>\n
\"\"<\/a><\/p>\n
Ent\u00e3o vamos criar o \u00edndice para ver como que a consulta vai ficar.<\/p>\n
CREATE INDEX IX_Person ON Person.Person\r\n(FirstName)\r\nWITH(FILLFACTOR=90)\r\n\r\n--Custo de execu\u00e7\u00e3o\r\nTable 'Person'. Scan count 1, logical reads 11\r\nTable 'Employee'. Scan count 1, logical reads 9\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 0 ms,  elapsed time = 32 ms.<\/pre>\n
Como podemos ver o custo da execu\u00e7\u00e3o reduziu para 32 milissegundos, enquanto o numero de leituras na tabela “Person.Person<\/strong>” reduziu de 117 para apenas 9 reads. Podemos observar tamb\u00e9m que no plano de execu\u00e7\u00e3o o SQL deixou de fazer um “Index Scan<\/strong>” na tabela “Person.Person” para realizar um “Index Seek<\/strong>“. Com isso podemos dizer que a coluna “FirstName<\/strong>” para essa consulta \u00e9 um predicado Sargable<\/strong>.<\/p>\n
\"\"<\/a><\/p>\n
Mas aten\u00e7\u00e3o dependendo da consulta a coluna “FirstName” pode deixar de ser Sargable, principalmente quando utilizamos fun\u00e7\u00f5es ou utilizamos alguns operadores. <\/strong>Vejamos a query abaixo.<\/p>\n
SELECT B.FirstName,B.LastName,A.BirthDate\r\nFROM HumanResources.Employee A\r\nJOIN Person.Person B ON B.BusinessEntityID = A.BusinessEntityID\r\nWHERE LEFT(B.FirstName,5) = 'Paul'\r\n\r\n--Custo de execu\u00e7\u00e3o\r\nTable 'Employee'. Scan count 0, logical reads 18\r\nTable 'Person'. Scan count 1, logical reads 100\r\n SQL Server Execution Times: CPU time = 0 ms, elapsed time = 345 ms.<\/pre>\n
Neste primeiro exemplo “Non-Sargable<\/strong>“, estamos utilizando a fun\u00e7\u00e3o “LEFT<\/strong>“, com isso n\u00f3s impossibilitamos o otimizador de consulta a utilizar o \u00edndice para fazer a opera\u00e7\u00e3o de “Index Seek<\/strong>“.<\/p>\n
\"\"<\/a><\/p>\n
Nessa segunda consulta vamos realizar um SELECT que vai nos retornar todos os funcion\u00e1rios nascidos em 1980, para isso vamos criar um \u00edndice na coluna “BirthDate<\/strong>” da tabela “HumanResources.Employee<\/strong>“.<\/p>\n
CREATE INDEX IX1_Employee ON HumanResources.Employee\r\n(BirthDate)\r\nWITH(FILLFACTOR=90)\r\n\r\nSELECT B.FirstName,B.LastName,A.BirthDate\r\nFROM HumanResources.Employee A\r\nJOIN Person.Person B ON B.BusinessEntityID = A.BusinessEntityID\r\nWHERE A.BirthDate BETWEEN '1980-01-01' AND '1980-12-31'\r\n\r\n--Custo da execu\u00e7\u00e3o\r\nTable 'Person'. Scan count 0, logical reads 21\r\nTable 'Employee'. Scan count 1, logical reads 2\r\n\r\n(1 row affected)\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 0 ms,  elapsed time = 450 ms.\r\n<\/pre>\n
\"\"<\/a><\/p>\n
Como podemos observar, o SQL utilizou o \u00edndice para realizar uma opera\u00e7\u00e3o de “Index Seek<\/strong>“, ent\u00e3o o predicado “BirthDate<\/strong>” nesta consulta \u00e9 Sargable<\/strong>.<\/p>\n
Mas voc\u00ea pode estar pensando “P\u00f4 Tiago” da para deixar esse c\u00f3digo melhor utilizando a fun\u00e7\u00e3o “Year<\/strong>“, Ok…, vamos ver o que acontece se utilizarmos a fun\u00e7\u00e3o Year<\/strong>.<\/p>\n
SELECT B.FirstName,B.LastName,A.BirthDate\r\nFROM HumanResources.Employee A\r\nJOIN Person.Person B ON B.BusinessEntityID = A.BusinessEntityID\r\nWHERE YEAR(A.BirthDate) = '1980'\r\n\r\n--Custo da execu\u00e7\u00e3o:\r\nTable 'Person'. Scan count 0, logical reads 21\r\nTable 'Employee'. Scan count 1, logical reads 88\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 0 ms,  elapsed time = 554 ms.<\/pre>\n
\"\"<\/a><\/p>\n
Novamente com a utiliza\u00e7\u00e3o da fun\u00e7\u00e3o “Year<\/strong>” no predicado “BirthDate<\/strong>“, o SQL N\u00c3O<\/strong> conseguiu realizar um Index Seek.<\/p>\n
Mas uma coisa a se observar \u00e9 que nem sempre \u00e9 ruim voc\u00ea “pagar”, usar uma fun\u00e7\u00e3o vai ter um momento que a diferen\u00e7a no custo ser\u00e1 t\u00e3o irrelevante que n\u00e3o vai justificar o trabalho de modificar toda a query. Outro ponto de aten\u00e7\u00e3o com o predicado Sargable, est\u00e1 relacionado a convers\u00e3o impl\u00edcita<\/strong>. Quando o SQL faz uma convers\u00e3o impl\u00edcita o otimizador de consulta N\u00c3O<\/strong> consegue realizar a opera\u00e7\u00e3o de Index Seek<\/strong>, tornando ele um predicado non-sargable, como podemos observar na consulta a seguir.<\/p>\n
CREATE INDEX IX1_Customer ON sales.Customer\r\n(AccountNumber)\r\nWITH (FILLFACTOR = 90)\r\n\r\nSELECT b.FirstName,\r\n       b.LastName,\r\n       a.AccountNumber\r\nFROM sales.Customer a\r\n    JOIN Person.Person b\r\n        ON b.BusinessEntityID = a.PersonID\r\nWHERE a.AccountNumber = 'AW00029594';\r\n\r\n--Custo execu\u00e7\u00e3o:\r\nTable 'Person'. Scan count 0, logical reads 3\r\nTable 'Customer'. Scan count 1, logical reads 4\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 0 ms,  elapsed time = 301 ms.<\/pre>\n
Na consulta acima criamos um \u00edndice na tabela “Sales.Custome<\/strong>r” utilizando a coluna “AccountNumber<\/strong>” como chave, ao executar a consulta podemos observar que o SQL utilizou o \u00edndice para fazer uma opera\u00e7\u00e3o de Index Seek<\/strong>.<\/p>\n
\"\"<\/a><\/p>\n
Por\u00e9m \u00e9 normal quando o desenvolvedor utiliza algum framework<\/strong> at\u00e9 mesmo por costume colocar o par\u00e2metro “N<\/strong>” no varchar, quando fazemos isso estamos informando ao SQL que vamos trabalhar com\u00a0 o tipo de dados NVarchar<\/strong>, que neste caso vai gerar a convers\u00e3o impl\u00edcita<\/strong>, que vai fazer com que o SQL deixe de realizar o Index Seek no predicado e tamb\u00e9m consuma mais CPU para efetuar a consulta.<\/p>\n
SELECT b.FirstName,\r\n       b.LastName,\r\n       a.AccountNumber\r\nFROM sales.Customer a\r\n    JOIN Person.Person b\r\n        ON b.BusinessEntityID = a.PersonID\r\nWHERE a.AccountNumber = N'AW00029594';\r\n\r\n--Custo de execu\u00e7\u00e3o:\r\nTable 'Person'. Scan count 0, logical reads 3\r\nTable 'Customer'. Scan count 1, logical reads 39\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 63 ms,  elapsed time = 609 ms.<\/pre>\n
\"\"<\/a><\/p>\n
Como podemos observar o SQL gerou um “warning<\/strong>” informando que o otimizador de consulta teve que fazer uma convers\u00e3o impl\u00edcita, e por consequ\u00eancia ele nem utilizou o \u00edndice que criamos na coluna “AccountNumber<\/strong>“, realizou um Index Scan<\/strong> no \u00edndice “IX_Customer_TerritoryID”. Al\u00e9m disso o custo de execu\u00e7\u00e3o na CPU aumentou praticamente 50%, ent\u00e3o quando ocorre uma convers\u00e3o impl\u00edcita<\/strong> no predicado temos um predicado non-sargable.<\/p>\n
Por isso que eu sempre recomendo a observar se no plano de execu\u00e7\u00e3o n\u00e3o tem nenhum warning referente a convers\u00e3o impl\u00edcita.<\/p>\n
Por fim… Existe um mito bastante comum que \u00e9 falar que quando utilizamos a cl\u00e1usula LIKE<\/strong> no predicado ele deixar de ser Sargable. Isso \u00e9 verdade, por\u00e9m somente se voc\u00ea utilizar o coringa “%” no come\u00e7o e no fim da sua string de busca.<\/strong> Vejamos no exemplo a seguir.<\/p>\n
A query abaixo \u00e9 a mesma que utilizamos no primeiro exemplo, por\u00e9m, desta vez queremos que o SQL nos retorne todos os clientes que tenha %Paul% no nome.<\/p>\n
SELECT b.fullname,\r\n       a.AccountNumber\r\nFROM sales.Customer a\r\n    JOIN Person.Person b\r\n        ON b.BusinessEntityID = a.PersonID\r\nWHERE b.FullName LIKE ('%Paul%');\r\n\r\n--Custo:\r\nTable 'Customer'. Scan count 1, logical reads 123\r\nTable 'Person'. Scan count 1, logical reads 111\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 31 ms,  elapsed time = 451 ms.<\/pre>\n
\"\"<\/a><\/p>\n
Como utilizamos o no predicado FullName<\/strong> “%Paul%<\/strong>“, o otimizador de consulta N\u00c3O<\/strong> consegue efetuar um opera\u00e7\u00e3o de Index Seek<\/strong> no \u00edndice “IX02_Person<\/strong>“. Ent\u00e3o nesta consulta o predicado \u00e9 Non-Sargable<\/strong>, e at\u00e9 ai o mito que a cl\u00e1usula “LIKE<\/strong>” \u00e9 Non-Sargable<\/strong> \u00e9 verdade, mas……<\/p>\n
Se voc\u00ea sabe quer somente o clientes que se chamam Paulo, Paul ou Paula, voc\u00ea concorda que podemos deixar essa consulta um pouco diferente, removendo o coringa “%<\/strong>” inicial, deixando apenas\u00a0FullName LIKE “Paul%”<\/strong>. Vamos ver o que o otimizador de consulta vai fazer nessa query.<\/p>\n
SELECT b.fullname,\r\n       a.AccountNumber\r\nFROM sales.Customer a\r\n    JOIN Person.Person b\r\n        ON b.BusinessEntityID = a.PersonID\r\nWHERE b.FullName LIKE ('Paul%');\r\n\r\n--Custo:\r\nTable 'Customer'. Scan count 1, logical reads 123\r\nTable 'Person'. Scan count 1, logical reads 2\r\n\r\n SQL Server Execution Times:\r\n   CPU time = 16 ms,  elapsed time = 225 ms.<\/pre>\n
\"\"<\/a><\/p>\n
Uauuuu agora o SQL conseguiu fazer uma opera\u00e7\u00e3o de Index Seek<\/strong> utilizando o \u00edndice “IX02_Person<\/strong>“, derrubando o mito que o LIKE<\/strong> SEMPRE<\/span> far\u00e1 que o predicado seja Non-Sargable<\/strong>.<\/p>\n
O Fabricio Lima<\/a> tem um v\u00eddeo<\/a> no que mostra dicas de como deixar o seu SELECT<\/strong> utilizando o LIKE<\/strong> mais perform\u00e1tico.<\/p>\n
Bom pessoal, por hoje \u00e9 isso espero ter contribu\u00eddo com algo novo para voc\u00eas.<\/p>\n
Deixe um feedback e nos ajude a melhorar.<\/p>\n
Abra\u00e7os,<\/p>\n
Tiago Neves<\/p>\n","protected":false},"excerpt":{"rendered":"
Ol\u00e1 pessoal tudo certo? No post de hoje vou compartilhar com voc\u00eas a respeito de um conceito muito comum no SQL Server, que \u00e9 o conceito de SARG (“S“ search argument) e Non-SARGable cuja a tradu\u00e7\u00e3o livre pode ser “Argumento de busca“. O termo SARG nada mais \u00e9 que a coluna que voc\u00ea est\u00e1 utilizando […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":{"twitter_91251433_91251433":""},"rop_publish_now_history":[],"rop_publish_now_status":"pending","_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"_wpscppro_dont_share_socialmedia":false,"_wpscppro_custom_social_share_image":0,"_facebook_share_type":"","_twitter_share_type":"","_linkedin_share_type":"","_pinterest_share_type":"","_linkedin_share_type_page":"","_instagram_share_type":"","_medium_share_type":"","_threads_share_type":"","_google_business_share_type":"","_selected_social_profile":[],"_wpsp_enable_custom_social_template":false,"_wpsp_social_scheduling":{"enabled":false,"datetime":null,"platforms":[],"status":"template_only","dateOption":"today","timeOption":"now","customDays":"","customHours":"","customDate":"","customTime":"","schedulingType":"absolute"},"_wpsp_active_default_template":true},"categories":[2,220,16,26,20,239],"tags":[241,207,223,243,54,242,240],"class_list":["post-1475","post","type-post","status-publish","format-standard","hentry","category-casos-do-dia-a-dia","category-sql-server-2017","category-sqlserver-2014","category-sqlserver-2016","category-sqlserver-geral","category-tuning","tag-alwaystuningyourdata","tag-dba-es","tag-dba-remoto","tag-non-sarg","tag-performance","tag-sarg","tag-tuning"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6eIyh-nN","jetpack-related-posts":[{"id":2414,"url":"https:\/\/www.tiagoneves.net\/blog\/sql-server-2016-esta-chegando-ao-fim-do-suporte-o-que-isso-significa-na-pratica\/","url_meta":{"origin":1475,"position":0},"title":"SQL Server 2016 est\u00e1 chegando ao fim do suporte: o que isso significa na pr\u00e1tica?","author":"tiagoneves","date":"27 de abril de 2026","format":false,"excerpt":"O SQL Server 2016 ter\u00e1 seu suporte estendido encerrado em 14 de julho de 2026, o que resultar\u00e1 na falta de atualiza\u00e7\u00f5es de seguran\u00e7a e suporte. Continuar usando essa vers\u00e3o traz riscos como vulnerabilidades e n\u00e3o conformidade regulat\u00f3ria. Planejar a migra\u00e7\u00e3o para vers\u00f5es mais recentes ou cloud deve ser prioridade\u2026","rel":"","context":"Em "Seguran\u00e7a"","block_context":{"text":"Seguran\u00e7a","link":"https:\/\/www.tiagoneves.net\/blog\/category\/seguranca\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.tiagoneves.net\/blog\/wp-content\/uploads\/2026\/04\/sql_server_2016_eos_v3.png?fit=772%2C702&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.tiagoneves.net\/blog\/wp-content\/uploads\/2026\/04\/sql_server_2016_eos_v3.png?fit=772%2C702&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/www.tiagoneves.net\/blog\/wp-content\/uploads\/2026\/04\/sql_server_2016_eos_v3.png?fit=772%2C702&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/www.tiagoneves.net\/blog\/wp-content\/uploads\/2026\/04\/sql_server_2016_eos_v3.png?fit=772%2C702&ssl=1&resize=700%2C400 2x"},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/posts\/1475","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/comments?post=1475"}],"version-history":[{"count":5,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/posts\/1475\/revisions"}],"predecessor-version":[{"id":1493,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/posts\/1475\/revisions\/1493"}],"wp:attachment":[{"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/media?parent=1475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/categories?post=1475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tiagoneves.net\/blog\/wp-json\/wp\/v2\/tags?post=1475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}