Mit MariaDB 5.3 wird ein neuer ColumnType Einzug halten. Das sogenannte Dynamic Column. Die Idee ist gewisse Vorgehensweisen, welche aus den DocumentStore-Lösungen (z.B. MongoDB) bekannt sind zu erfüllen. Ob man das wirklich will, liegt nicht an mir zu entscheiden. Doch sei folgender Link dem geneigten Leser nahe gelegt.
Die Idee ist denkbar einfach: In der Tabelle wird eine BLOB-Spalte verwendet um darin die dynamischen Element zu verwalten.
Es sei erwähnt, dass zum Nachspielen  https://code.launchpad.net/~maria-captains/maria/5.3-mwl34 zu verwenden ist.

MariaDB [test]> SELECT VERSION();
+---------------------+
| VERSION()           |
+---------------------+
| 5.3.0-MariaDB-alpha |
+---------------------+ …

MySQL hat bisher nicht den besten Ruf was die Performance von Stored Procedures angeht. Bereits 2008 war dies ein Thema in einem Blogeintrag[1]. Darin wurde die Fibonacci Formel[2] mit einer Stored Function nachgebildet. Das Ergebnis war: PHP ist mit einer ähnlichen Funktion 10x schneller als die MySQL Stored Function. Hat MySQL inzwischen nachbessern können? UPDATE 03.05.2011

Am Dienstag, den 10. Mai 2011 findet in Berlin und am Donnerstag, den 12. Mai 2011 in Kirchheim - Heimstetten (bei München) je eine Veranstaltung zum Thema "MySQL Skalierbarkeit und Leistung verbessern" statt.

Mehr:
http://www.oracle.com/us/dm/h2fy11/70841-wwmk10037168mpp216c004-oem2-359311-de.html

Berlin:
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=131061&src=7011252&src=7011252&Act=181&evite=181

München:
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=131062&src=7011252&src=7011252&Act=179&evite=179

In diesem Seminar stellen wir Ihnen zunächst die neuen Funktionen sowohl der aktuellen Version MySQL 5.5 (GA) als auch der zukünftigen Version 5.6 vor.

Anschließend stellen wir Ihnen verschiedene Referenzarchitekturen für kleine, mittelgroße und sehr große Webunternehmen vor. Sie lernen die gängigen Bestandteile der meisten Webpräsenzen kennen, einschließlich Session Management, Authentifizierung, eCommerce und Content Management. Für jede Umgebung werden optimale Bereitstellungsarchitekturen und -topologien auf Grundlage von Größen- und Verfügbarkeitsanforderungen definiert. Im Rahmen dieses Überblicks betrachten wir auch die besonderen Anforderungen für sehr großse Anwendungen im Bereich soziale Netzwerke.

Abschließend betrachten wir verschiedene Hochverfügbarkeitslösungen mit MySQL, einschließlich Client/Server-Architekturen, MySQL Replikation und MySQL Cluster.

Erfahren Sie in diesem Seminar, …

Ich bin der Meinung, dass es sich gehört, dass Blogs Kommentare zulassen. Ist dies nicht der Fall, wird aus einem Blog zu schnell ein authistisches Tagebuch.
In diesem Blog fragt sich der Autor, ob er einen Bug in den neueren MySQL-Versionen (>5.1.x) gefunden hat:

mysql>SELECT BENCHMARK(100, fibonacci(10000));
ERROR 1690 (22003): DOUBLE value is out of range in '(f1@1 + f2@3)'


Uups, was ist das. Die MySQL Version 5.5.9 steigt mit einem SQL-Fehler (ERROR 1690) aus. Ist dies ein Bug?


Ganz im Gegenteil die Fehlermeldung ist hier genau richtig. Denn die Fibonacci-Reihe übersteigt den Definitionsbereich von DOUBLE. Das tat es schon in der 5.1.x und früher. Nur jetzt gibt es eben einen Fehler .. was gut ist!
Warum die genutzte Funktion …

"Kris, kannst Du bitte mal gucken?"

Seit heute morgen, 10:00 Uhr, wächst das Undo Log immer weiter an.

Immer wenn InnoDB Daten schreibt wird die alte Version einer Zeile aus der Tabelle in das Undo-Log verschoben, also physikalisch von der ibd-Datei der Tabelle in die ibdata1 im Datadir von MySQL. In der Tabelle wird in der veränderten Zeile ein Zeiger von der neuen Version auf die alte Version der Zeile im Undo-Log installiert, der Roll(back)-Pointer. Die alte Version im Undo-Log zeigt mit ihrem eigenen Roll-Pointer auf eine noch ältere Version derselben Zeile und so weiter - es entsteht für jede Zeile in der Datenbank eine lineare Liste von Versionen in die Vergangenheit einer Row.

Der InnoDB Purge Thread hat die Aufgabe, das Undo Log zu verkürzen. Wenn er das nicht tut, dann sieht das so aus wie oben im Graphen gezeigt. Dafür kann es zwei Gründe geben: Purge Lag - also mehr Writes als der Purge Thread …

Am Donnerstag, den 19. Mai 2011 findet in Hannover die Gründungsversammlung der DOAG SIG - Database zum Thema "MySQL" statt. Es wird viele interessante Vorträge geben.

Mehr:
http://mydoag.doag.org/termine/termine.php?tid=423270

Taxonomy upgrade extras:  mysql blob dump select german

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das …

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das Zertifikat ein falsches Format habe.

Zum Glück fand ich in der MySQL Dokumentation den folgenden Satz: If you use INTO DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line termination and without performing any escape processing. This is useful if you want to store a BLOB value in a file.

Wir haben es ausprobiert mit:

mysql> SELECT certificate
  INTO DUMPFILE …

ALTER TABLE vs. Schemaless

ALTER TABLE in MySQL nervt. Das tut es in erster Linie, weil es die Tabellen, die es verändert, mit einem exklusiven Lock (Write Lock) belegt, während es die Änderung durchführt, und weil es die Änderung durch Umkopieren der Daten und Indices durchführt, was bei einer großen bestehenden Datenmenge doch recht lange dauern kann.

Es gibt inzwischen eine Reihe von Verbesserungen in MySQL 5.5, wenn InnoDB (inzwischen die Default Storage Engine) verwendet wird. Diese Verbesserungen beziehen sich zum größten Teil auf das Erzeugen und Löschen von Indices im Hintergrund, also ohne Lock und ohne den Betrieb aufzuhalten.

Auch für das Erzeugen und Löschen von Spalten oder das Ändern von Defaults gibt es Lösungen, die in InnoDB jedoch noch nicht umgesetzt sind. Die meisten dieser Lösungen basieren …