Oli Sennhauser

Wir brauchen Dich: MySQL DBA für FromDual Support Dienste

FromDual sucht enthusiastische und erfahrene Mitarbeiter die:

• detaillierte Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen
• mit dem Open-Source Ökosystem vertraut sind
• als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
• verstehen, was beim Betrieb von Datenbanken falsche gemacht werden kann
• gerne selbständig remote arbeiten und über IRC, Skype, Mail und Telefon zu kommunizieren gewohnt sind
• sich auf Linux Systemen wohl fühlen
• gute Team-Player sind und zum Wachstum der Firma beitragen wollen
• gerne den direkten Kontakt mit Kunden haben und
• auf der Suche nach einer neuen Herausforderung sind

Stellenbeschreibung

Wir suchen Vollzeit-MySQL Support DBA's (Sie oder Ihn), welche primär für unsere MySQL Support Dienstleistungen zuständig sind und unseren Kunden helfen, ihre MySQL Datenbanken zu betreiben (remote-DBA und Notfall-Interventionen).

Du bist fit in MySQL und:

• hast Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver MySQL Datenbanken hauptsächlich auf Linux.
• Deine tägliche Arbeit ist MySQL-Replikation in allen Variationen.
• weisst, wie die meist verbreitetsten MySQL HA Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt. (Wenn Du bereits Erfahrungen mit Galera Cluster gesammelt hast, ist das ein Vorteil!)
• kennst die gängigen Open-Source Technologien (LAMP Stack, etc.)
• kannst Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (Perl, PHP, ...) erstellen.

Du wirst im direkten Kontakt mit Kunden stehen. Du hast ein gutes Gespür für deren Probleme und kannst zuhören, weisst wie antworten und findest die eigentlichen Probleme. Du wirst proaktiv handeln, bevor etwas passiert und den Kunden wieder auf den richtigen Pfad führen.
Du bist ein guter Kommunikator und ein aktiver Team Player.

Um Deine Arbeit erledigen zu können, arbeitest Du in einer Europäischen Zeitzone. Deine Arbeitszeit kannst Du in bestimmten Grenzen flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual ist eine vollständig virtuelle Firma. Ein Umzug ist daher nicht notwendig (Home-Office). Gute schriftliche und mündliche Englischkenntnisse sind zwingend. Die meisten unserer Kunden sind deutschsprachig. Deutschkenntnisse sind daher von Vorteil.

Neben Deiner Tätigkeit als Support DBA erwarten wir, dass Du Dir laufend neue Kenntnisse aneignest und Deine Fähigkeiten verbesserst sowie dazu beiträgst, unsere Monitoring-Lösung, unsere Datenbank-Steuerung und unseren weiteren Tools zu verbessern. Im weiteren erwarten wir, dass Du regelmässig zur Verfassung technischer Artikel (Blog oder Zeitschriften) beiträgst und überall mit hilfst, wo Hilfe nötig ist...

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Google, die MySQL Dokumentation, Ausprobieren, etc.). Wenn Du mal nicht weiterkommst, werden Dir Deine Kollegen von FromDual helfen.

Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.

Wer ist FromDual?

FromDual ist die führende unabhängige MySQL Beratungs- und Dienstleistungs-Firma in Europa mit ihrem Hauptsitz in der Schweiz.

Unsere Kunden befinden sich hauptsächlich in Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma.

Du wirst in einer spannenden Zeit zu uns stossen. Wir sind am wachsen und brauchen die entsprechenden Leute, welche selbst und mit uns wachsen wollen. In dem Mass, wie wir uns weiter entwickeln, muss auch unser Team wachsen uns seine Fähigkeiten erweitern.

Sich bei uns zu bewerben, kann kann Deine beste Entscheidung sein.

Wie geht's weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist (wir wissen, dass es niemanden gibt, der 100% auf diese Stellenbeschreibung passt!), würden wir uns freuen, von Dir zu hören.

Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Lohnvorstellungen und einer Liste Deiner Open-Source Beiträgen, Blog-Artikel, Vorträgen, Tweets etc. an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!

Nachdem wir Deinen Lebenslauf erhalten und geprüft haben, laden wir Dich ein, Deine technischen Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Wenn Du den Test bestanden hast, laden wir Dich für die finalen Interviews ein.

Dieses Stellenangebot ist offen bis 31. Mai 2013

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Taxonomy upgrade extras: galeramonitoringcluster

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Taxonomy upgrade extras: galeramonitoringcluster

Taxonomy upgrade extras: galeramonitoringcluster

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD'; Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD'; Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD';

Weil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

Weil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

Taxonomy upgrade extras: tabledatainnodbpartitioncompressWeil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Früher, lange, lange ist's her, konnte man den folgenden Trick verwenden um MySQL Queries in der Applikation zu taggen:

SELECT /* My Application Tag */ * FROM test;

Im Slow Query Log und im General Query Log ist das SQL Query dann wie folgt erschienen:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT /* My Application Tag */ * FROM test;

und

111020 22:03:15 1335 Query SELECT /* My Application Tag */ * FROM test

Das ist recht nützlich, wenn man nicht genau weiss woher ein Query stammt oder wie es von der Applikation schlussendlich ausformuliert wird.

Leider wurde dieses Feature irgendwann einmal von MySQL abgeschafft. Wann das genau geschehen ist, konnte ich nicht mehr herausfinden. Heute sehen die entsprechenden Einträge wie folgt aus:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT * FROM test;

und

111020 22:03:15 1335 Query SELECT * FROM test

Bei unserem heutigen Kunden hatten wir wieder mal genau dieses Problem. Zum Glück hatte er eine glorreiche Idee. Aus:

SELECT * FROM test WHERE 1 = 1;

machten wir kurzerhand:

SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und siehe da:

# Time: 111020 22:24:59 # User@Host: root[root] @ localhost [] Id: 2077 # Query_time: 12.270074 Lock_time: 0.000124 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319142299; SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und

2077 Query SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag'

es funktioniert...

Ist zwar nicht ganz so sexy, aber recht nützlich...

Taxonomy upgrade extras: tagquerygeneral query log