Das CMSMS Dev Problem - zu wenig Ahnung von Mysql

Wer sich die Struktur der verwendeten Mysql Tabellen  anschaut stellt fest - es wurden teils  massiv Indexe angelegt.
Das hört sich gut an denkt man doch das Mysql damit schnellere Abfragen ausführt.

Aber ob diese Indexe tatsächlich jemals zum Einsatz kommen - das hat bei Cmsms wohl niemand geprüft. Es schaut so aus als wenn man gedacht hätte das Mysql sich schon einen passenden Index bei Abfragen auswählen würde.

Tatsächlich kommen die meisten Indexe nie zum Einsatz.

Aber sie müssen von Mysql geführt und somit verwaltet werden. Ein Absturz während eines Schreibvorganges und diese teils zahlreichen Indexe und der Tatsache das man keine Transaktionen verwendet können das aus für die Tabelle oder DB bedeuten.

Hier ein ganz einfaches Beispiel an Hand Originalabfrage.

SELECT * FROM cms_modules ORDER BY module_name

Das führt dazu das Mysql ein Filesort ausführt.
Filesort ist aufwendig und belastet den Server.

Die bessere Variante wäre die Mysql mitzuteilen welchen Index verwendet, denn der hier nutzbare Index der liegt vor:

SELECT * FROM cms_modules FORCE INDEX (cms_idx_modules_by_name)

Diese Abfrage führt zu einem simplen Select ohne jeglichen Sortierungsaufwand da die Sortierung über den Index bereits vorliegt.

Der Unterschied bei dieser kleinen Abfrage mit wenigen Einträgen in der Tabelle mag hier klein sein.

Aber andere Tabellen sind größer und vor allem die Tabellen werden ausgelöst vom Besucher abgefragt und verursachen kumuliert eine enorme Mehrbelastung des Servers.

Das Endergebnis - de Site selbst wird deutlich langsamer .

Halten wir fest

• es gibt jede Menge Indexe
• Indexe werden aber meist nicht verwendet
• Indexe die man hätte gebrauchen können gibt es nicht.

Diese Situation ist im übrigen kein Einzelfall sondern die Regel.
Das deutet darauf hin das die Developer von Cmsms eigentlich keine wesentlichen Kenntnisse von Mysql haben.

Nachtrag:

Hier noch ein weiteres Beispiel aus dem Adminbereich

Original Netto SQL:
SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (1,2,3,4,5,6,7,8,9,10,11,22) ORDER BY hierarchy
Fabriziert:
Using index condition; Using filesort

Bessere SQL:
SELECT * FROM cms_content FORCE INDEX (cms_idx_content_by_hier) WHERE content_id IN (1,2,3,4,5,6,7,8,9,10,11,22)
Fabriziert:
Using where

Man hat offenbar für die Originalabfrage irgendwann mal den darin angegebenen Index angelegt.
Der Index in der besseren Abfrage war schon vorhanden.

Der Unterschied - die Originalabfrage ist 1/3 langsamer als die bessere.

Das Problem ist aber immer generell - unnötige Belastungen des Servers, Mysql und der PHP Umgebung ziehen alles runter.

Manch Möchtegernoptimierer sieht immer nur die realen Ergebnisse einer einzigen Optimierung und meint dann - lohnt nicht - solche sehen das Ganze nicht und fallen rein.