Nutzt Salesforce den Index wirklich?

Auch in 19 Sprachen

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

Kapitel 8 von Data Architect, Teil 2: Architektur im großen Maßstab. Zurück: Für Skalierung entwerfen.

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

Die Ideen in diesem Kapitel

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? ⟲
Die Schwellen, auswendig zu kennen: Standardindex 30 % der ersten Million Datensätze plus 15 % darüber, gedeckelt bei 1 Million; benutzerdefinierter Index 10 % plus 5 %, gedeckelt bei 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

Der Weg durch dieses Kapitel

Fünf Module, jedes steht für sich.

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

Was Architekt:innen hier entscheiden

Welche Abrufmuster zählen, und welche Wege das Modell ihnen gibt.
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. ⟲
Ob indiziert, umgeschrieben, umgestaltet oder archiviert wird, wenn der Abruf nicht skaliert.
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. ⟲

Weiterlesen

Salesforce Architects, Platform Multitenant Architecture (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (öffnet in einem neuen Tab) (Winter ‘27), checked 2026-11-01. ⟲
Salesforce Help, Make Salesforce Platform SOQL Query Selective (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
Salesforce Help, How Search Crowding Affects Search Results (öffnet in einem neuen Tab), checked 2026-11-01. ⟲

Weiter: Integration und Datenbewegung