DB Konzeptionsfehler rächen sich schnell

Falsches Verständnis von Mysql aber auch von grundsätzlichen Techniken führen dazu das SQL Konstrukte entstehen die unterm Strich grauenvolle Ergebnisse zeigen können aber nicht vermuten lassen.

Nehmen wir als Beispiel einen Konzeptionsfehler bei dem Titel Cmsmadesimple.

Dort werden Childs eine Menüpunktes mit folgender SQL ausgelesen:

SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (36,37,29,30,46,45,38,47) ORDER BY hierarchy

Sieht ja recht vernünftig aus - aber untersucht man es genauer dann stellt man fest - diese Abfrage verursacht Using index condition; Using filesort,

Führt man eine Messung durch ergibt sich folgendes Bild:

Der Grund - der verwendete Index geht über Tabellenspalten content_id und hierarchy.
Es gibt aber auch einen Index der nur über hierarchy geht.

Ändert man die Abfrage demnach auf

SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (36,37,29,30,46,45,38,47) ORDER BY hierarchy

sieht die Sache bereits etwas anders aus.

Es kommt ein simples using where zum Einsatz da man simple einen Index abgrasen kann.

Die Messung ergibt dann folgendes:

Ganz klar - diese Abfrage ist mehr als doppelt so schnell.

Was man nicht auf den ersten Blick erkennen kann - die erste Originalabfrage ist gefährlich.
Betrachtet man es in der Situation das 100, 200 oder mehr Besucher gleichzeitig das Web besuchen - dann erfolgt eine massive Belastung von Mysql und dem Server - das kann je nach Seitenvolumen und Struktur bereits dazu führen, das ein solches Web ungenießbar wird.

Aber es gibt noch ganz andere Fallstricke die man als Fachmann erahnen kann.

Dieser Teil IN (36,37,29,30,46,45,38,47) bezeichnet die eindeutigen ID's der Child-Inhalte.
Die aber wurden vorher abgefragt und mittels PHP aufbereitet.

Die betreffenden Startseite hat eine Hierarchie von 00002 - die Childs demnach z.B. 00002.00001, 00002.00002  usw. .
Die Hierarchie liegt in der DB vor.

Demnach kann man die Childs direkt mit folgender Abfrage abholen.

SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE INSTR(hierarchy,'00002.')=1 AND active = 1 ORDER BY hierarchy

active=1 muss hier gesetzt sein, da dieser Teil bei der Startabfrage und Bildung von IN (36,37,29,30,46,45,38,47)  bereits geklärt wurde.

Auch diese Abfrage verwendet  ein simples where und die Messung ergibt folgendes Bild:

Die kostspielige Aufbereitung  mittels vorheriger Abfragen und PHP entfällt komplett.

Da hier nur die reine Abfrage gemessen wurde aber nicht das ganze betrachtet wurde erkennt man nicht die ganze Auswirkung der Originalkonstruktion wie sie von Cmsmadesimple verwendet wird.

Die ist in der Tat eine Katastrophe in der Gesamtwirkung - reduziert dramatisch die Gesamtleistung.

Nehmen wir einmal ein anderes Beispiel:

 SELECT modified_date FROM cms_content ORDER BY modified_date DESC LIMIT  1

Hier geht es darum das Datum zu ermitteln, wann eine Seite des Web's zuletzt bearbeitet wurde.

Einen Index über modified_date gibt es nicht, was also passiert.
Es wird von allen vorhandenen Seiten die Spalte modified_date gelesen, dann wird alles nach modified_date per filesort absteigend sortiert um dann den ersten zu nehmen.

Kein größeres Ding meint man - aber eine unnötige Last und insbesondere dann wenn man hunderte oder gar tausende Seiten hat.
Ein einfacher Index über diese Spalte und der Zwang diesen Index zu nutzen würde daraus ein einfaches  where machen und nur einen Datensatz betreffen.

Durch den strategischen Fehler Adodb einzusetzen welches keine Rückgabe als Objekt erlaubt - Cmsmadesimple aber intern mit Objekten arbeitet werden zudem auch noch mittels PHP die verwendungsfähigen Ergebnisse mittels PHP als Objektarray umgesetzt.

Nun ist das hier nicht DER Kardinalfehler sondern unter Cmsms einer von vielen die bezüglich Mysql etabliert wurden.

Indexe die auf Grund von Abfrageformulierungen überhaupt nicht zum tragen kommen.
Abfragen zu denen Indexe möglich wären aber keine gebildet wurden.
Abfragen geben kein direkt verwendbares Ergebnis wieder.
Es wird massiv mittels PHP vorher und nachher aufbereitet.

Im Klartext - es hat sich von den Entwicklern niemand den Gebrauch von EXPLAIN erklären lassen oder mal eine Messung ausgeführt - die mittels Phpmyadmin ganz simple möglich wäre.

Alle diese Dinge sind wesentliche Gründe warum ein solches System unter Last sehr schnell massive Probleme bekommt und sogar zusammenbricht.