Die Listenquery lädt den Artikel nicht mehr
News, Notes und Cases speichern drei HTML-Bodies in JSON. Das Raster braucht Titel und Anrisse. Den Artikel braucht es nicht.
Jede News-Zeile hält Titel, Anriss und Body als JSON mit en, ru und de. Die öffentliche Liste wählte die Zeile. Fünfzig Artikel zogen etwa 1,2 MB HTML in den InnoDB-Buffer-Pool. Die JSON-API warf das meiste weg, bevor die Antwort PHP verließ. Das Raster druckte nie einen Body.
Die Listenquery fragt jetzt nach id, Kategorie, Titel, Anriss, Bild, Größe, Daten und Sort. Body bleibt auf der Detailquery. Derselbe Schnitt landete auf Notes und Cases. Ein Muster, drei Ressourcen.
Der Index
Öffentliche Listen filtern is_published und sortieren nach sort_order oder published_at. Ein zusammengesetzter Index deckt das in der richtigen Spaltenreihenfolge. Zwei Indizes, die die führenden Spalten duplizierten, sind weg. Sie kosteten Writes und gaben nichts zurück.
Plan-Checks gehören auf Produktionsgröße. Auf einer kleinen Seed-Tabelle wählt MySQL den Scan und sieht gesund aus. Der Kipp zum Full Scan ist eine Zeilenzahl, keine Vermutung in der Entwicklung.
Worauf Vue SSR nicht mehr wartet
Das SSR-Raster wartet nicht mehr auf einen Blob, den es nie druckt. Detailseiten wurden nicht sichtbar langsamer. Falls doch, ist das die eine Query zum Cachen, per id, mit einem TTL, das beim Admin-Save stirbt.
JSON ist das Admin-Format. Der Listenpfad liest eine kurze Zeile. Der Artikelpfad liest den Body. Sie zu mischen war bequem und teuer.