¿usará Salesforce de verdad el índice?

También en 19 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Capítulo 8 de Data Architect, Parte 2: Arquitectura a escala. Anterior: Diseñar para la escala.

Te mando a una biblioteca con 10 millones de libros y te pido todos los libros de A. Ortiz. Sin catálogo. Empiezas por un extremo y abres cada libro. Eso es un recorrido completo de la tabla (table scan). Ahora te doy un catálogo de fichas con un cajón por autor: eso es un índice. Y añado un bibliotecario que decide, para cada pregunta, si son más rápidos los cajones o las estanterías: ese es el optimizador de consultas.

Aquí está el truco, y la idea más difícil del examen: que un índice exista no significa que Salesforce lo vaya a usar. Piénsalo como el nitro de un coche de carreras. Solo se dispara cuando se cumplen tres cosas a la vez: hay un índice en el campo, preguntas de forma selectiva y coinciden pocos registros. Pide al catálogo todos los libros en inglés cuando el 95 % de la biblioteca está en inglés, y no ha acotado nada. Todo el mundo vive en Arizona. Por eso “no te preocupes, ese campo está indexado” nunca es el final de la conversación.

On a race car's dashboard, a switch with its red guard lifted waits under three lights: two green, the third still dark.

Image generated with AI. ⟲

Antes de la biblioteca, abrimos el capó. Salesforce no es una base de datos que se instala para una sola empresa. Es un único edificio con muchos inquilinos, unas pocas tablas compartidas que guardan los registros de todas las organizaciones y metadatos que describen tus objetos y campos. Ese diseño explica por qué Salesforce indexa como indexa, y por qué una consulta puede hacer un trabajo que nunca pediste.

El capítulo anterior contó los ceros. Este encuentra cosas dentro de ellos: primero con consultas, luego con la búsqueda, que encuentra por palabras.

Las ideas de este capítulo

Salesforce es multiinquilino y está basado en metadatos. Añadir un campo añade una fila de metadatos, no una columna. Los campos estándar y personalizados se guardan por separado, así que una consulta que usa ambos hace una unión (join) que nunca escribiste.
Un índice es una copia: un dato y la ubicación del registro. Cada índice hace más rápido encontrar y más lento cada guardado.
Tres comprobaciones para cada filtro: ¿hay un índice?; ¿preguntas de forma selectiva (igual a y empieza por, no contiene, no distinto de ni vacío)?; ¿y estás por debajo del umbral?
Los umbrales, para saberlos de memoria: índice estándar, el 30 % del primer millón de registros más el 15 % del resto, con un máximo de 1 millón; índice personalizado, el 10 % más el 5 %, con un máximo de 333.333.
Una consulta puede estropearse sin cambiar. Los casos se cierran, el historial se acumula, el objeto crece un 30 % al año y el filtro deja de acotar.
El bibliotecario decide, cada vez. Mide la distribución y luego lee el Query Plan; el optimizador elige el camino, no tú.
Cuando va lento: indexar, reescribir, rediseñar o archivar, elegido de forma deliberada. Las skinny tables son para el patrón que “sabes en el fondo”: los mismos pocos campos, una y otra vez, en un objeto gigante.
Buscar no es consultar. La búsqueda encuentra primero los tokens y luego trae los registros; su índice es asíncrono; y corta la lista en 2.000 antes de comprobar lo que el usuario puede ver. Eso es la saturación de la búsqueda (search crowding).
Unos datos pueden merecer existir sin merecer aparecer en la búsqueda. Decide qué se puede buscar, por objeto, perfil y campo.
Busca para descubrir; consulta para operar.

Cinco preguntas, cinco módulos

La pregunta	Dónde se responde
¿Por qué Salesforce no funciona como una base de datos tradicional?	Módulo 1, el motor
¿Qué es un índice y cuáles te da Salesforce?	Módulo 2, la biblioteca
¿Cuándo puede Salesforce usar un índice?	Módulo 3, el nitro
¿Quién decide cómo se ejecuta la consulta, y qué pasa si es lenta?	Módulo 4, el bibliotecario
¿Cuándo deberías buscar en lugar de consultar?	Módulo 5, la búsqueda

El recorrido de este capítulo

Cinco módulos, cada uno se sostiene por sí solo.

Dentro del motor de Salesforce. Un edificio, muchos inquilinos, separados por el ID de la organización; sin tablas nuevas, solo metadatos; las pocas tablas compartidas; la unión que nunca escribiste; por qué un índice normal no encaja; y cómo Salesforce reconstruyó el motor por debajo sin que nadie lo notara.
Cómo encuentra Salesforce tus datos. La biblioteca y su catálogo de fichas: un recorrido completo de la tabla, un índice como copia, cada copia mantenida al día, dos maneras de preguntar (SOQL y SOSL), los índices estándar, los índices personalizados, qué campos se pueden indexar y las tablas de índices.
Cuándo usa Salesforce un índice. Las tres comprobaciones del nitro: ¿hay un índice?, ¿lo preguntas de la manera correcta? y ¿estás por debajo del umbral? Todo el mundo vive en Arizona, los umbrales y sus topes, la trampa de los casos cerrados y el crecimiento del 30 %.
Cómo ejecuta Salesforce una consulta. Cuatro palabras (consulta, recuperación, recorrido completo de la tabla, unión), el bibliotecario, los informes con volumen, el Query Plan, más de un índice, los índices de dos columnas, las skinny tables, las divisiones, las estadísticas de la base de datos e indexar, reescribir, rediseñar o archivar.
Buscar no es consultar. Primero los tokens, luego la recuperación; la frescura; la saturación de la búsqueda paso a paso, y un plan de siete pasos para reducirla; la búsqueda se ejecuta como alguien; busca para descubrir, consulta para operar.

Encontrar por significado (recuperación semántica e híbrida), y los agentes que recuperan datos con mucha más frecuencia que cualquier persona, están en el capítulo 16, Choosing How the Agent Gets the Data.

Lo que decide aquí un arquitecto

Qué patrones de recuperación importan, y qué caminos les da el modelo.
Si cada filtro importante sigue siendo selectivo en el tercer año y en el quinto, con el volumen real y la distribución real.
Qué índices compensan su coste, estándar, personalizados o de dos columnas, y cuándo la respuesta es una skinny table.
Si indexar, reescribir, rediseñar o archivar cuando la recuperación no escala.
Cuándo buscar y cuándo consultar, y qué merece siquiera poder buscarse.

Más allá del examen: la IA no deroga la física de las bases de datos. Un asistente escribe un SOQL verosímil que se hunde con 50 millones de filas, y un agente ejecuta la misma recuperación ineficiente mil veces al día. El bibliotecario sigue decidiendo, los umbrales siguen aplicándose y la búsqueda sigue cortando en 2.000. Cada módulo termina con lo que la IA cambia en su parte de la recuperación.

Explora

Salesforce Architects, Platform Multitenant Architecture (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva) (Winter ‘27), checked 2026-11-01. ⟲
Salesforce Help, Make Salesforce Platform SOQL Query Selective (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Salesforce Help, How Search Crowding Affects Search Results (se abre en una pestaña nueva), checked 2026-11-01. ⟲

Siguiente: Integración y movimiento de datos