Salesforce userà davvero l'indice?

Disponibile anche in 19 lingue

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

Capitolo 8 di Data Architect, Parte 2: Architettare su larga scala. Precedente: Progettare per la scala.

I send you into a library with 10 million books and ask for every book by A. Ortiz. No catalog. You start at one end and open every book. That’s a table scan. Now give you a card catalog with a drawer by author: that’s an index. And add a librarian who decides, for every question, whether the drawers or the shelves are faster: that’s the query optimizer. ⟲

Here’s the catch, and the hardest idea on the exam: an index that exists isn’t an index Salesforce will use. Think of it as the nitro in a race car. It only fires when three things are true at once: there’s an index on the field, you ask in a selective way, and few enough records match. Ask the catalog for every book in English when 95% of the library is in English, and it hasn’t narrowed anything. Everybody lives in Arizona. That’s why “don’t worry, that field is indexed” is never the end of the conversation. ⟲

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. ⟲

Before the library, we open the hood. Salesforce isn’t a database you install for one company. It’s one building with many tenants, a few shared tables that hold every org’s records, and metadata that describes your objects and fields. That design explains why Salesforce indexes the way it does, and why a query can do work you never asked for. ⟲

The last chapter counted the zeros. This one finds things inside them: first with queries, then with search, which finds by words. ⟲

Le idee di questo capitolo

Salesforce is multitenant and metadata-driven. Adding a field adds a row of metadata, not a column. Standard and custom fields are stored apart, so a query that uses both does a join you never wrote. ⟲
An index is a copy: one fact and the record’s location. Every index makes finding faster and every save slower. ⟲
Three checks for every filter: is there an index; do you ask in a selective way (equals and starts with, not contains, not equal or empty); and are you under the threshold? ⟲
Le soglie, da sapere a memoria: indice standard, 30% del primo milione di record più 15% oltre, con un tetto di 1 milione; indice personalizzato, 10% più 5%, con un tetto di 333.333.
A query can go bad without changing. Cases close, history piles up, the object grows 30% a year, and the filter stops narrowing. ⟲
The librarian decides, every time. Measure the distribution, then read the Query Plan; the optimizer chooses the path, not you. ⟲
When it’s slow: index, rewrite, redesign or archive, chosen deliberately. Skinny tables are for the pattern you “know in your heart”: the same few fields, again and again, on a giant object. ⟲
Search is not query. Search finds tokens first, then fetches the records; its index is asynchronous; and it cuts the list at 2,000 before it checks what the user can see. That’s search crowding. ⟲
Data can deserve to exist without deserving to appear in search. Decide what’s searchable, by object, profile and field. ⟲
Search to discover; query to operate. ⟲

Five questions, five modules

The question	Where it’s answered
Why doesn’t Salesforce work like a traditional database?	Module 1, the engine
What is an index, and which ones does Salesforce give you?	Module 2, the library
When can Salesforce use an index?	Module 3, the nitro
Who decides how the query runs, and what if it’s slow?	Module 4, the librarian
When should you search instead of query?	Module 5, search

Il percorso di questo capitolo

Cinque moduli, ognuno si regge da solo.

Inside the Salesforce Engine. One building, many tenants, kept apart by the org ID; no new tables, just metadata; the few shared tables; the join you never wrote; why a normal index doesn’t fit; and how Salesforce rebuilt the engine underneath without anyone noticing. ⟲
How Salesforce Finds Your Data. The library and its card catalog: a table scan, an index as a copy, every copy kept up to date, two ways to ask (SOQL and SOSL), the standard indexes, custom indexes, which fields can be indexed, and index tables. ⟲
When Salesforce Uses an Index. The nitro’s three checks: is there an index, are you asking it the right way, and are you under the threshold. Everybody lives in Arizona, the thresholds and their caps, the closed-cases trap, and 30% growth. ⟲
How Salesforce Executes a Query. Four words (query, fetch, table scan, join), the librarian, reports at volume, the Query Plan, more than one index, two-column indexes, skinny tables, divisions, database statistics, and index, rewrite, redesign or archive. ⟲
Search Is Not Query. Tokens first, then the fetch; freshness; search crowding step by step, and a seven-step playbook to reduce it; search runs as someone; search to discover, query to operate. ⟲

Finding by meaning (semantic and hybrid retrieval), and agents that retrieve far more often than any person, are in chapter 16, Choosing How the Agent Gets the Data. ⟲

Cosa decide qui un architetto

Quali pattern di recupero contano, e quali percorsi gli offre il modello.
Whether each important filter stays selective at year three and year five, at real volume and real distribution. ⟲
Which indexes are worth their cost, standard, custom or two-column, and when a skinny table is the answer. ⟲
Se indicizzare, riscrivere, riprogettare o archiviare quando il recupero non scala.
When to search and when to query, and what deserves to be searchable at all. ⟲

Beyond the exam: AI doesn’t repeal database physics. An assistant writes plausible SOQL that dies at 50 million rows, and an agent runs the same inefficient retrieval a thousand times a day. The librarian still decides, the thresholds still apply, and search still cuts at 2,000. Each module ends with what AI changes for its part of retrieval. ⟲

Per approfondire

Salesforce Architects, Platform Multitenant Architecture (si apre in una nuova scheda), checked 2026-11-01. ⟲
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (si apre in una nuova scheda) (Winter ‘27), checked 2026-11-01. ⟲
Salesforce Help, Make Salesforce Platform SOQL Query Selective (si apre in una nuova scheda), checked 2026-11-01. ⟲
Salesforce Help, How Search Crowding Affects Search Results (si apre in una nuova scheda), checked 2026-11-01. ⟲

Successivo: Integrazione e movimento dei dati