Escribir consultas eficientes

Objetivos de aprendizaje

Después de completar esta unidad, comprenderá:

Cómo Query Optimizer de Force.com optimiza el desempeño de las consultas.
La repercusión que tiene el uso de consultas selectivas sobre el desempeño de las consultas.
Cómo utilizar la herramienta Query Plan para evaluar las consultas de búsqueda.

Límites

Las consultas eficientes no solo tienen un mejor desempeño, también ayudan a garantizar que no se presenten problemas con los límites regulados. Recuerde, estamos en una plataforma multiusuario donde todos tienen que compartir espacio. Y el asunto principal que puede hacer que un sistema se bloquee más rápido que cualquier otra cosa es una consulta con un desempeño deficiente. Y aquí es donde entran los límites regulados.

Piense en los límites regulados como una clase de árbitro para los recursos. Garantizan que todo el mundo juega según las reglas y recibe la misma cantidad de la tarta de los recursos.

En esta unidad va a aprender lo que puede hacer para optimizar sus consultas de búsqueda para evitar tener que quedar limitado por dichos límites.

Query Optimizer de Force.com

La base de datos back-end de Salesforce utiliza Oracle, pero Force.com utiliza su propia versión de un optimizador de consultas, llamado Query Optimizer, para evaluar las consultas basadas en costos. Como la mayoría de los optimizadores de consultas basados en costos, el que utiliza Salesforce se fundamenta en los datos estadísticos recopilados sobre los datos. La mayoría de los datos estadísticos se recopilan semanalmente, pero el sistema genera también consultas previas que se colocan en caché cada hora.

Query Optimizer evalúa las consultas SOQL y las búsquedas SOSL. Actúa como un guardia de tráfico enrutando las consultas a los índices apropiados. Mira todas las consultas entrantes y asigna un valor de costo para cada ruta de consulta potencial que identifica. Luego utiliza estos costos para determinar qué plan de ejecución utilizar.

No vamos a mentirle. La forma con la que Query Optimizer selecciona los planes de ejecución funciona con umbrales que pueden volverse algo complicados. Pero sabemos que como desarrollador de .NET estará a la altura de las circunstancias. Puede profundizar todo lo que quiera consultando los vínculos de la sección Recursos cuando acabemos.

Mejores prácticas

Sabemos que a los desarrolladores de .NET les encanta pensar en las mejores prácticas. Les encanta marcarse retos y siempre buscan la mejor forma de hacer las cosas. Entendemos eso. Así que pensamos que le gustaría aprender cuáles son las mejores prácticas que hay que utilizar para construir consultas de búsqueda rápidas y eficientes.

Construcción de consultas selectivas

En la primera unidad tratamos las declaraciones SOQL y cómo puede aplicar filtros utilizando la cláusula WHERE. Incluso puede combinar campos múltiples empleando las cláusulas AND y OR.

Bien, sabemos que no se sorprenderá al leer esto: tener más campos en su cláusula WHERE es una cosa buena. Obviamente, cuantos menos datos devuelva su consulta, tanto mejor. Pero lo que quizá no sepa es que no todos los campos son lo mismo. Algunos campos son lo que podría considerar como campos “potentes”. Si utiliza estos campos potentes en la cláusula WHERE, sus consultas se ejecutan a la velocidad del rayo.

¿Y qué es lo que confiere esa potencia a los campos potentes? Los índices, por supuesto.

Para todas las tablas estándar y personalizadas, ciertos campos se marcan automáticamente para indexarse. Estos campos incluyen los siguientes:

Campo indexado	Descripción
Id (Id.)	Campo exclusivo de 18 caracteres que viene generado por el sistema. Es la clave principal del objeto.
Nombre	Campo basado en texto.
OwnerId	Referencia al propietario del objeto.
CreatedDate	Fecha y hora a las que se creó el objeto.
SystemModStamp	Campo de solo lectura que contiene la fecha más reciente en la que se actualizó el registro. Este campo está indexado mientras que el campo similar LastModifiedDate no lo está, de modo que considere utilizar este en sus consultas.
RecordType	Id. del tipo de registro. RecordType se utiliza para ofrecer resultados diferentes en la interfaz de usuario para ciertos usuarios.
Campos principal-detalle	Campos con clave externa que se utilizan para indicar una relación principal-detalle
Campos de búsqueda	Campos con clave externa que se utilizan para indicar una relación de búsqueda
Campos exclusivos	Los campos personalizados pueden marcarse como exclusivos cuando se crean, lo que los indexará automáticamente.
Campos con Id. externo	Al igual que los campos exclusivos, estos campos personalizados pueden marcarse con un Id. externo y se utilizan principalmente por motivos de integración.

Siempre que utilice uno de estos campos indexados en la cláusula WHERE de su consulta, estará aumentando las posibilidades de que su consulta se considere selectiva y se utilice un índice en contraposición a una exploración completa de tablas. Debemos hacer hincapié en lo importante que es esto cuando se está trabajando con bases de datos de gran tamaño.

Nota: Los clientes de Salesforce tienen la posibilidad de solicitar un índice personalizado al Servicio de atención al cliente de Salesforce creando un caso de asistencia e incluyendo la consulta SOQL con el campo indexado.

Excepciones de selectividad de índices

El uso de un campo indexado en su consulta no siempre la convierte en infalible. Puede hacer cosas en sus consultas que las convertirán en no selectivas y por ello proclives a la temida exploración completa de tablas. Cuando construya sus consultas esfuércese siempre por evitar estas cosas.

Consultas de filas nulas: Las consultas que buscan registros en los que el campo está vacío o es nulo. Por ejemplo:
```
SELECT Id, Name FROM Account WHERE Custom_Field__c = null
```
Operadores de filtro negativos: El uso de operadores como !=, NOT LIKE o EXCLUDES en sus consultas. Por ejemplo:
```
SELECT CaseNumber FROM Case WHERE Status != ‘New’
```
Comodines iniciales: Las consultas que utilizan un comodín inicial, como esta:
```
SELECT Id, LastName, FirstName FROM Contact WHERE LastName LIKE ‘%smi%’
```
Campos de texto con operadores de comparación: El uso de operadores de comparación, como >, <, >= o <=, con campos basados en texto. Por ejemplo:
```
SELECT AccountId, Amount FROM Opportunity WHERE Order_Number__c > 10
```

Herramienta Query Plan

Nuestra amiga Developer Console contiene una bonita herramienta para acelerar sus consultas. Le da una visión de las bambalinas donde funciona Query Optimizer. La herramienta Query Plan no está activada de forma predeterminada. Actívela realizando lo siguiente.

En el menú Configuración, seleccione Developer Console para abrir Developer Console.
En Developer Console, seleccione Help > Preferences (Ayuda | Preferencias).
Seleccione Enable Query Plan (Activar Query Plan) y asegúrese de que está establecida como true.
Haga clic en Guardar.
En la ficha Query Editor, confirme que el botón Query Plan está ahora junto al botón Execute.

Ahora que la herramienta Query Plan está activada, puede utilizarla para evaluar consultas. Empecemos utilizándola para evaluar una consulta con un desempeño deficiente.

En Developer Console, haga clic en la ficha Query Editor en el panel inferior.
Elimine el código existente e inserte el siguiente fragmento de código:
```
SELECT Id, CaseNumber FROM Case WHERE Status != 'New'
```
Haga clic en Query Plan.

El cuadro de diálogo Query Plan muestra una tabla que enumera el costo de la consulta y que realizará una exploración de tablas TableScan. Esto no es bueno. Consulte las notas en el panel inferior, que explican más los resultados.

Analicemos ahora otra consulta que obtiene los mismos resultados que la primera consulta.

Haga clic en la ficha Query Editor en el panel inferior.
Elimine el código existente e inserte el siguiente fragmento de código:
```
SELECT Id, CaseNumber FROM Case WHERE IsClosed = true
```
Haga clic en Query Plan.

El cuadro de diálogo Query Plan muestra una tabla que enumera el coste de la consulta, pero esta vez se muestra otra fila que indica que es posible utilizar un índice.

Las dos consultas que pasamos por Query Plan recuperaron el mismo número de filas, pero los planes de ejecución variaron bastante debido a los campos y los operadores que elegimos. Estas diferencias parecen pequeñas debido a la ínfima cantidad de datos que tiene en su organización de desarrollo, pero cuando empieza a comparar consultas en organizaciones con millones de registros, estas diferencias pueden cambiar el curso del juego.

Para obtener más información sobre lo que revela cada columna de la consulta Query Plan, consulte el vínculo sobre la herramienta Query Plan en Recursos.

Más información

Esfuércese siempre por evitar la creación de consultas con campos de fórmula no deterministas. Los campos de fórmula son campos personalizados que le permiten calcular de forma dinámica el valor de un campo en tiempo de ejecución. Estos tipos de campos tienden a estar muy difundidos en la mayoría de las organizaciones y pueden sobreutilizarse fácilmente. Un campo de fórmula se considera no determinista cuando su valor cambia con el paso del tiempo. Consulte el vínculo en Recursos sobre las mejores prácticas de SOQL: Campos nulos y de fórmula para obtener más información.

Lamentablemente, no puede utilizar la herramienta Query Plan para evaluar las consultas SOSL, pero eso no significa que no pueda tener en cuenta el desempeño de esos tipos de consultas. Aprenda más sobre lo que hay que evitar cuando se redactan consultas SOSL consultando los vínculos de Mejores prácticas y Desempeño que hay como referencia en Recursos.