Ich wollte das schon immer mal loswerden, habe aber bisher nie die Zeit dazu gefunden: Zend_Db und vor allem Zend_Db_Table  sind lame. So. Früher habe ich schon oft überlegt, warum tust du dir diesen ganzen SQL-Kram immer noch an? Es gibt doch angefangen von PDO auch so bequeme Frameworks wie Zend, CakePHP oder Symfony mit Doctrine. Niemand muss doch mehr diesen Quatsch selbst hacken. Aber am Ende steht manchmal noch die Frage im Raum, ob man nun eine komplexe Infrastruktur benötigt oder einfach mal ein bisschen schnelleren Code verwenden sollte. Zu der Zeit, als ich die Überlegungen traf, kam es halt (in meiner Situation) auf jede Millisekunde an.

Weiter lesen »

Früher war es sehr oft üblich, varchar(255) an jede Hauswand zu sprühen, wo Text in MySQL zu speichern war. In letzter Zeit sehe ich häufig varchar(32), varchar(64) und so weiter in verschiedenen Datenbank-Layouts. Ist das besser? Welche Länge ist eigentlich gut? In diversen Foren wird über varchar diskutiert, denn es ist oft ein entscheidendes Performance-Kriterium.

Weiter lesen »

Ich habe mich auf MySQL 5.1 schon länger gefreut, vor allem, weil Merged Tables und Partitionen auf dem Programm standen. Irgendwie habe ich allerdings nie die Zeit gefunden, diese neuen Features auszuprobieren. Nun ist es soweit, sich den Partitionen zu widmen. Sind sie wirklich so viel schneller als ein Index?

Weiter lesen »

Also Leute, ich habe gerade über folgende Frage nachgedacht:

Ist MySQL schneller, wenn der Index lückenlos ist?

Anderherum gefragt: Ist es langsamger, Abfragen über eine zB mit 1 Million Datensätzen gefüllten Tabelle zu machen, wenn der Index durch viele Löschoperationen “fragmentiert” ist und man ausschließlich den Index für die Suchanfrage benutzt?

Ich werde diese Frage in den nächsten Tagen mal untersuchen. Bis dahin seid ihr aufgefordert, eure Tipps aus dem Bauch heraus abzugeben, gern auch mit ausschmückenden Erläuterungen. 🙂 Natürlich ist es wegen Fairness striktestestestens verboten, das Ergebnis vor der Abgabe eines Tipps zu recherchieren!

Also, ich halte die Voraussetzungen noch einmal fest:

• Beide Tabellen sind gleich aufgebaut.
• Beide Tabellen haben die gleiche Anzahl an Einträgen.
• Beide Tabellen benutzen als Schlüssel  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT.
• Beide Tabellen werden vor dem Test über phpmyadmin optimiert.
• Es werden nur Anfragen auf den Index verwendet.

Aber:

• Bei einer der Tabellen sind durch vorige Löschoperationen “Lücken” im Index.
• In der anderen sind die Indizes durchgängig nummeriert.

Ich freu mich schon auf das Ergebnis! 🙂

Größere Netzwerke, Suchmaschinen oder auch mal eben der kleine Statusbalken arbeiten viel besser, wenn man einen Zeitstempel zur Verfügung stellen kann à la “Dieser Artikel oder dieses Produkt wurde zuletzt geändert am …”.

Das ist allerdings nicht ganz so easy, wenn sich die Daten des Satzes in verschiedenen Tabellen befinden. Also muss man die sich mühevoll zusammenklauben. Bei uns im Shop sind es eigentlich nur eine Handvoll Tabellen: Der Artikeleintrag in der Warenwirtschaft, die Varianten, die Preise, Rabatte, Shop-Eintrag, Shop-Texte und Shop-Fotos.

Weiter lesen »

Ich habe mal wieder darüber nachgedacht, ob es nicht Zeit wäre, von MySQL auf Postgres umzusteigen. Bei den diesjährigen Chemnitzer Linux-Tagen habe ich ein interessantes Gespräch mit einem der Postgres-Leute gehabt. Seitdem laufen beide Datenbanken auf meinem Laptop und warten darauf, eingehend verglichen zu werden. Weiter lesen »

Mein Chef meinte zu unserem neuen Server, der sei “irgendwie lahm” . Ich hatte nach dem ersten Hochspielen unseres neuen Onlineshops eigentlich genau das Gegenteil als Erfahrung gemacht. Tatsächlich, die Seite war lahm. Vielleicht nur in seinem neuen IE7? Naja, im ewigen Streben nach mehr Geschwindigkeit habe ich mich diese Woche also ein wenig mit Indizes und Views sowie Funtionen (UDFs) in MySQL beschäftigt, um den Shop so gut wie möglich auf Trab zu bringen.

Weiter lesen »