Eine der großen Änderungen in MySQL 5.5 ist, daß die InnoDB Storage Engine jetzt der Default Table Type ist. Das bedeutet, daß eine Tabelle mit ENGINE=InnoDB erzeugt wird, wenn keine ENGINE-Clause beim Anlegen der Tabelle angegeben wird.

CODE:CREATE TABLE demo (

  id integer unsigned not null primary key auto_increment,

  d varchar(20) not null

);

In MySQL bis einschließlich 5.1 wäre diese Tabelle als MyISAM angelegt worden, ab 5.5 wird sie als InnoDB-Tabelle angelegt.

Um existierenden Code auf das neue MySQL vorzubereiten sind ein paar wichtige Handgriffe zu erledigen.

Transaktionen und AUTOCOMMIT

Existierender Code, der für die MyISAM-Engine optimiert ist, wird in der Regel nicht mit Transaktionen arbeiten. Das bedeutet, der Code wird schreibende SQL-Statements erzeugen, …

Lenz Grimmer versorgt einen Google Calendar mit Veranstaltungshinweisen zum Thema MySQL (und Oracle).

Man kann das Ding abonnieren oder seinem eigenen Google Kalender zufügen.

Golem, Heise, Pro-Linux und viele andere auch schreiben über den neuen MySQL 5.5 Release Candidate, 5.5.6.

In den Kommentaren zu den Artikeln gibt es eine Reihe von Fragen, zum Beispiel wieso MySQL 5.5 zwischen 3 und 4.6 mal schneller als 5.1.50 sein soll. Eine bessere Quelle der Information als das Presserelease von Oracle sind vielleicht diese Präsentationen von Mikael Ronstrom.

InnoDB hat, um das "A" in "ACID" gewährleisten zu können, wie jede Datenbank, einen Haufen interne …

Taxonomy upgrade extras: mysqlDBAworkshopfortgeschrittenegermanFromDual plant, mit einem seiner Partner, einen MySQL DBA Workshop für Fortgeschrittene anzubieten. Die erste Durchführung soll im November 2010 erfolgen.

Um den Teilnehmern den bestmöglichen Inhalt anbieten zu können, würden wir gerne Ihre Meinung über den geplanten Inhalt, fehlende Punkte und was Sie im allgemeinen über diesen Workshop denken, hören.

Bitte lassen Sie uns Ihre Meinung wissen. Entweder …

In diesem Webseminar erfahren Sie, wie Sie MySQL Datenbanken mit Hilfe der MySQL Workbench richtig entwerfen und gestalten, einschließlich Forward- und Reverse-Engineering. Außerdem behandelt werden die Themen Datentypen, Indizes und Fremdschlüssel sowie verschiedene Anwendungsszenarien.

Date and Time: Friday, 15 Oct 2010, 11:00 CET

Kurzer SQL WTF von heute:

QUOTE:mysql> SELECT 'a'='b';

0

mysql> SELECT 'a'='b'='c';

1

Warum ist das so?

Im MySQL Sourcecode ist in sql/sql_yacc.yy definiert:

QUOTE:%left EQ EQUAL_SYM GE GT_SYM LE LT NE IS LIKE REGEXP IN_SYM

Damit ist der Operator EQ (das Vergleichheitszeichen) als links-assoziativ definiert. Vergleiche von Vergleichen sind also zugelassen, 1 = 2 = 3 ist also ein zulässiges Konstrukt und es wird als ( 1 = 2 ) = 3 evaluiert. Statt links-assoziativ könnte es auch als rechts-assoziativ ( 1 = (2 = 3 )) oder als nicht-assoziativ (ein Mehrfachvergleich ist unzulässig) definiert sein.

Daher ist der boolsche Ausdruck 'a' = 'b' offensichtlich falsch, also 0. Und damit wird "0 = 'c'" zu einem Vergleich eines Integers links mit einem Character rechts. In einem links-assoziativen Ausdruck bestimmt der linke Ausdruck den Typ, zu dem der …

ORACLE bietet im September 2010 mehrere Live Webcasts in diversen Sprachen an.

More:
http://www.oracle.com/dm/11q1field/55580_mysql_september_webcast.html

d> Ist es normal, daß root keine Grants auf INFORMATION_SCHEMA setzen darf? Falls "nein", ist die wunderliche DB von neulich noch wunderlicher.

Isotopp> INFORMATION_SCHEMA ist immer fuer alle User sichtbar. Tables in INFORMATION_SCHEMA enthalten jedoch nur Informationen, die für den abfragenden User sichtbar sein dürften. Grants sind daher komplett überfluessig.

Isotopp> INFORMATION_SCHEMA ist /proc fuer Datenbanken. Da muß man ja auch keine Permissions setzen können.

d> Der Backup-User hat folgende Rechte: ... Bei der anderen DB darf er damit INFORMATION_SCHEMA sichern.

Isotopp> INFORMATION_SCHEMA sollst Du nicht sichern. Du kannst es ja auch nicht zurück spielen.

Isotopp> Du sicherst ja auch /proc nicht.

Für viele MySQL-Anwendungen sind Covering Indexes eine wichtige Sache. Domas hat einen Artikel darüber Wie Wikipedia von Covering Indexes profitiert, und auch sonst sind solche Indices für viele MySQLer ein täglicher Bestandteil der Optimierungsarbeit.

Nun las ich neulich in einem Artikel eine Seitenbemerkung, daß Postgres keine Covering Indices unterstützt und das scheint tatsächlich der Fall zu sein, auch wenn ich in der Doku selber keine Hinweise darauf gefunden habe.

Warum Postgres das nicht kann ist zunächst einmal klar: MVCC macht das sehr schwierig. In meinem Vortrag zur InnoDB Storage Engine ( …

Das verspricht interessant zu werden: im Oktober werden wir zwei eintägige Seminare zum Thema "MySQL-Hochverfügbarkeit" veranstalten, bei denen die verschiedenen MySQL Hochverfügbarkeits-Technologien und -Architekturen vorgestellt werden. Aus der Beschreibung:

Wir werden Anwendungsfälle und optimale Verfahrensweisen für die Implementierung der MySQL Replikation, von MySQL Cluster und anderen Hochverfügbarkeits-Technologien betrachten. Im Rahmen dieses Seminars erfahren Sie außerdem, wie diese Technologien grundlegend funktionieren und kombiniert werden können, um besser skalierbare und hochverfügbare Datenbankinfrastrukturen zu erstellen.

Das erste Seminar findet am 5. Oktober in Heimstetten bei München statt, am 27. Oktober wird es eine ähnliche Veranstaltung in Langen bei Frankfurt geben.

Die Teilnahme ist kostenlos - daher empfehle ich, sich früh für die Teilnahme anzumelden! Weitere Informationen findet …