Ein Grid mit hundert Testeinträgen fühlt sich immer schnell an - die Testimonial-Verwaltung mit tausenden Einträgen (mehrere Sprachen, mehrere Jahre gesammelte Kundenstimmen) zeigt erst dann, wo die eigentlichen Engpässe liegen. Dieses Kapitel geht die häufigsten Performance-Hebel durch.

Indizes auf gefilterten/sortierten Spalten

Jede Spalte, die im Grid regelmäßig gefiltert oder sortiert wird, sollte in db_schema.xml einen passenden Index bekommen - ohne Index scannt MySQL bei jedem Filter die komplette Tabelle:

<index referenceId="MIRONSOFT_TESTIMONIAL_IS_ACTIVE" indexType="btree">
    <column name="is_active"/>
</index>
<index referenceId="MIRONSOFT_TESTIMONIAL_POSITION" indexType="btree">
    <column name="position"/>
</index>

Nach einer Änderung an db_schema.xml gilt erneut die Regel aus Kapitel 2: setup:upgrade ist zwingend, sonst bleibt der Index nur auf dem Papier.

Nicht benötigte Spalten ausblenden

Jede zusätzliche Spalte bedeutet zusätzliche Daten pro Zeile, die über die Leitung an den Browser gehen. Selten genutzte Spalten (etwa created_at in einer Übersicht, die primär nach Status filtert) lassen sich mit <visible>false</visible> standardmäßig ausblenden, ohne sie ganz zu entfernen - Redakteure können sie über columnsControls (Kapitel 7) bei Bedarf selbst einblenden.

N+1-Abfragen in eigenen Column-Renderern vermeiden

Volltextsuche und LIKE-Abfragen

Der Text-Filter aus Kapitel 7 nutzt LIKE %wert% - ein führendes Prozentzeichen verhindert grundsätzlich die Nutzung eines B-Tree-Index für diese Spalte, weil MySQL nicht von links nach rechts im Index vergleichen kann. Für sehr große Tabellen mit häufiger Volltextsuche ist ein dedizierter FULLTEXT-Index (über db_schema.xml als indexType="fulltext") die deutlich performantere Alternative, allerdings mit anderer Such-Semantik (Wortgrenzen statt Teilstring).

Paginierung korrekt nutzen

Die Standard-Paginierung (Kapitel 4) begrenzt die Datenbankabfrage bereits korrekt über LIMIT/OFFSET - das eigentliche Performance-Risiko liegt selten hier, sondern in eigenem Code, der versehentlich vor der Paginierung auf der vollen Collection arbeitet (zum Beispiel eine PHP-Schleife in getData(), die über parent::getData() hinausgeht, bevor LIMIT angewendet wurde).

Checkliste für große Grids

• Index auf jeder häufig gefilterten/sortierten Spalte in db_schema.xml.
• Selten benötigte Spalten standardmäßig ausblenden (visible: false), nicht entfernen.
• Keine Datenbankabfragen pro Zeile in Column-Renderern - stattdessen einmalig vorladen.
• Bei intensiver Volltextsuche einen FULLTEXT-Index statt LIKE %...% erwägen.
• Eigene getData()-Logik immer nach, nicht vor der Paginierung ausführen lassen.