Escrever consultas eficientes
Objetivos de aprendizagem
Depois de concluir esta unidade, você entenderá:
- Como o Otimizador de consultas do Force.com otimiza o desempenho das consultas.
- O impacto do uso de consultas seletivas no desempenho das consultas.
- Como usar a ferramenta Plano de consulta (Query Plan) para avaliar as consultas de pesquisa.
Limites
Consultas eficientes não só têm um desempenho melhor, como também ajudam a garantir que você não tem problemas com os limites de administrador. Lembre-se: é uma plataforma multilocatário cujo espaço precisa ser dividido por todos. E o motivo nº 1 para o sistema travar num piscar de olhos são as consultas de mau desempenho. É aí que entram os limites de administrador.
Pense que os limites de administrador funcionam como um árbitro dos recursos. Eles garantem que todos seguem as regras e recebem a mesma quantidade de recursos.
Nesta unidade, você aprenderá a otimizar suas consultas de pesquisa para jamais ter de ser limitado pelos limites.
O Otimizador de consultas do Force.com
O banco de dados de back-end do Salesforce usa Oracle, mas o Force.com usa sua própria versão de um Otimizador de consultas (Query Optimizer) para avaliar as consultas com base nos custos. Assim como a maioria dos otimizadores de consultas baseados nos custos, o do Salesforce usa estatísticas coletadas sobre os dados. A maioria das estatísticas é coletada semanalmente, mas o sistema também gera pré-consultas que são armazenadas em cache a cada hora.
O Otimizador de consultas avalia consultas SOQL e pesquisas SOSL. Ele atua como se fosse um guarda de trânsito, encaminhando as consultas aos índices certos. Ele observa cada consulta que chega e atribui um valor de custo para cada possível caminho de consulta identificado. Depois, usa esses custos para determinar qual plano de execução usar.
Mas não vamos mentir para você. A forma como o Otimizador de consultas seleciona os planos de execução e trabalha com limites pode ficar um pouco complicada. Porém, sabemos que um desenvolvedor .NET como você está à altura do desafio. Você pode se aprofundar o quanto quiser nesse assunto conferindo os links da seção Resources quando terminarmos.
Melhores práticas
Sabemos que os desenvolvedores .NET adoram pensar em melhores práticas. É que você ama se desafiar e está sempre procurando o melhor jeito de fazer as coisas. Já entendemos. Então, achamos que você adoraria conhecer as melhores práticas para criar consultas de pesquisa rápidas e eficientes.
Criando consultas seletivas
Na primeira unidade, abordamos os demonstrativos SOQL e como você pode aplicar filtros usando a cláusula WHERE. É possível até combinar vários campos usando as cláusulas AND e OR.
Com certeza você não vai se surpreender ao ouvir isso, mas é bem útil ter mais campos na cláusula WHERE. Quanto menos dados a consulta retornar, melhor – isso é óbvio. Mas talvez você não saiba que nem todos os campos são iguais. Alguns campos são o que chamaríamos de campos “potentes”. Quando você usa esses campos potentes na cláusula WHERE, as consultas ficam super-hiper-rápidas.
E o que torna esses campos potentes tão poderosos? Índices, é claro.
Em todas as tabelas padrão e personalizadas, alguns campos são automaticamente sinalizados para indexação. Alguns desses campos são:
Campo indexado | Descrição |
---|---|
Id | Campo exclusivo com 18 caracteres que é gerado pelo sistema. É a chave primária do objeto. |
Nome | Campo baseado em texto. |
OwnerId | Referência ao proprietário do objeto. |
CreatedDate | Data e hora em que o registro foi criado. |
SystemModStamp | Campo somente leitura que contém a data da última atualização do registro. Esse campo é indexado, enquanto o campo similar LastModifiedDate não é; então, considere usá-lo nas consultas. |
RecordType | ID do RecordType. RecordTypes são usados para oferecer resultados diferentes de UI para determinados usuários. |
Campos de mestre e detalhes (Master-Detail Fields) | Campos de chave estrangeira usada para indicar um relacionamento entre mestre e detalhes |
Campos de pesquisa (Lookup Fields) | Campos de chave estrangeira usada para indicar um relacionamento de pesquisa |
Campos exclusivos (Unique Fields) | Os campos personalizados podem ser marcados como exclusivos quando são criados, e isso faz com que eles sejam automaticamente indexados. |
Campos de ID externa | Assim como os campos exclusivos, esses campos personalizados podem ser marcados como ID externa e são usados principalmente para fins de integração. |
Sempre que você usa um desses campos indexados na cláusula WHERE da consulta, está aumentando as chances de a consulta ser considerada seletiva e de um índice ser usado em vez da análise da tabela inteira. Nunca é de mais dizer o quanto isso é importante ao lidar com bancos de dados grandes.
Nota: Os clientes do Salesforce podem solicitar um índice personalizado ao suporte do Salesforce, criando um caso de suporte e incluindo a consulta SOQL com o campo indexado.
Exceções de seletividade do índice
Usar um campo indexado na consulta nem sempre significa sucesso. É possível fazer algumas coisas para que as consultas sejam não seletivas e, portanto, propensas à temida análise de tabela inteira. Ao criar suas consultas, sempre tente evitar essas coisas.
- Consultar linhas nulas – Consultas que procuram registros nos quais o campo está vazio ou é nulo. Por exemplo:
SELECT Id, Name FROM Account WHERE Custom_Field__c = null
- Operadores de filtro negativos – Usar operadores como !=, NOT LIKE ou EXCLUDES nas consultas. Por exemplo:
SELECT CaseNumber FROM Case WHERE Status != ‘New’
- Começar com caracteres curinga – Consultas começadas com um caractere curinga, como:
SELECT Id, LastName, FirstName FROM Contact WHERE LastName LIKE ‘%smi%’
- Campos de texto com operadores de comparação: usar operadores de comparação, como >, <, >=, ou <=, com campos baseados em texto. Por exemplo:
SELECT AccountId, Amount FROM Opportunity WHERE Order_Number__c > 10
Ferramenta Plano de consulta
Nosso amigo Console do desenvolvedor tem uma ferramenta fantástica para acelerar as consultas. Ela permite que você dê uma olhada nos bastidores do funcionamento do Otimizador de consultas. A ferramenta Plano de consulta (Query Plan) não fica ativada por padrão. Para ativá-la, faça o seguinte.
- No menu Configuração, selecione Developer Console para abrir o Developer Console.
- No Developer Console, selecione Help (Ajuda) > Preferences (Preferências).
- Selecione Ativar plano de consulta e verifique se ele está configurado como true.
- Clique em Save (Salvar).
- Na guia Query Editor, confirme que o botão Query Plan está agora próximo do botão Execute.
Agora que a ferramenta Plano de consulta (Query Plan) está ativada, é possível usá-la para avaliar as consultas. Vamos começar avaliando uma consulta com desempenho ruim.
- No Console do desenvolvedor, clique na guia Editor de consulta no painel inferior.
- Exclua o código existente e insira o seguinte trecho:
SELECT Id, CaseNumber FROM Case WHERE Status != 'New'
- Clique em Plano de consulta.
A caixa de diálogo do Plano de consulta mostra uma tabela que apresenta o custo da consulta e informa que fará um TableScan. Isso não é nada bom. Confira as notas no painel inferior que explicam melhor os resultados.
Agora, veremos outra consulta que gera resultados idênticos aos da primeira.
- Clique na guia Editor de consulta no painel inferior.
- Exclua o código existente e insira o seguinte trecho:
SELECT Id, CaseNumber FROM Case WHERE IsClosed = true
- Clique em Plano de consulta.
A caixa de diálogo do Plano de consulta mostra uma tabela que apresenta o custo das consultas, mas dessa vez há outra linha que indica a possibilidade de usar um índice.
As duas consultas que executamos pelo Plano de consulta retornaram o mesmo número de linhas, mas os planos de execução variaram bastante por causa dos campos e operadores escolhidos. Essas diferenças parecem pequenas porque a sua organização de desenvolvimento tem poucos dados; porém, quando você começa a comparar consultas em organizações com milhões de registros, essas diferenças podem ser dramáticas.
Para entender melhor o que cada coluna do Plano de consulta revela, confira o link sobre essa ferramenta em Resources.
Quero saber mais
Sempre evite criar consultas com campos de fórmula não deterministas. Os campos de fórmula são campos personalizados que permitem calcular dinamicamente o valor de um campo durante o tempo de execução. Esse tipo de campo tende a ser popular na maioria das organizações e é fácil usá-lo em excesso. Um campo de fórmula é considerado não determinista quando seu valor varia com o passar do tempo. Para saber mais, confira o link SOQL Best Practices: Nulls and Formula Fields, em Resources, sobre as melhores práticas de SOQL: campos nulos e de fórmula.
Infelizmente, não é possível usar a ferramenta Plano de consulta para avaliar as consultas SOSL, mas isso não significa que o desempenho é ignorado nesses tipos de consulta. Descubra o que evitar ao escrever consultas SOSL nos links Best Practices e Performance Tips, em Resources.