Einzelne Datenbank/Tabelle aus MySQL-Dump wiederherstellen

Auf meinem Rootserver läuft jeden Tag ein Backup mit fwbackups, welches meine Dateien und Datenbanken mittels externem Script sichert und, ebenfalls mit Hilfe eines externen Scripts, auf einen FTP-Backupspace lädt. Das ist – einmal eingerichtet – sehr komfortabel. Möchte ich nun aber an die Daten heran und nur eine Datenbank oder Tabelle zurückspielen so müsste ich eigentlich einen zweiten MySQL-Server starten, das Backup einspielen und dann nur das gewünschte exportieren. Das wäre extrem umständlich, daher habe ich nach einem einfacheren Weg gesucht und ihn auch gefunden:

Nur eine Datenbank zurücksichern:

sed -n '/^-- Current Database: `dbname`/,/^-- Current Database: `/p' dumpfile > dbname.sql 2>error

Nur eine Tabelle zurücksichern:

sed -n -e '/CREATE TABLE.*mytable/,/CREATE TABLE/p' mysql.dump > mytable.dump

Hat man mehrere Tabellen, die ähnlich heißen sollte man Backquotes für die Namen verwenden.

 
Danke an uloBasEI von stackoverflow.com und Prabhat Kumar von adminlinux.blogspot.com für diese Tipps.

//Update: Danke an Kai Hessing, der mich per Mail aufmerksam gemacht hat, dass es mit obriger SQL-Anweisung ein Problem gibt, wenn die Tabelle vor der Rücksicherung schon existiert. Also dann entweder die Tabelle erst löschen oder folgendes Kommando benutzen:

sed -n -e '/DROP TABLE.*MYTABLE/,/UNLOCK TABLES/p' $BACKUPDIR/$FILE > $BACKUPDIR/$FILE.mytable

MySQL und Index – oder: warum %-Zeichen böse sind

Heute bin ich auf eine interessante Sache gestoßen, die eigentlich ganz logisch ist (wenn man ein wenig über Bäume Bescheid weiß), auf die man aber von allein trotzdem erst nach viel Nachdenken kommt wie ich finde. Daher will ich sie niemandem vorenthalten 🙂

Es fing alles damit an, dass MySQL-Queries des XMLArsenal (siehe Projekte) unglaublich lange brauchten. Ein JOIN über 3 Tabellen mit WHERE-Clause auf einer und Primärschlüsseln in allen Tabellen (die zum JOIN verwendet wurden) brauchte teilweise bis zu 2 Sekunden. Nun ist der Datenbestand recht groß, etwa 170.000 Zeilen (~2GByte) in der größten Tabelle. Trotzdem konnte es eigentlich nicht angehen zumal auf der Namensspalte, die ich in der WHERE-Clause verwende, bereits ein Index definiert war. An dieser Stelle muss ich mich bei Silvan Mühlemann von techblog.tilllate.com bedanken, sein Artikel „Optimierung von MySQL-Abfragen: Verwendung des Index“ hat mich auf die richtige Spur bzw. eigentlich gleich zur richtigen Lösung gebracht: Nutzt man

1
LIKE %Name%

kann MySQL den definierten Index nicht nutzen, d.h. wieder Scan über die ganze Tabelle. Lässt man das vordere % weg wird das Ergebis zwar kleiner aber es steht der Nutzung des Index nichts mehr im Wege – Speedup in diesem Fall: 50.000-fach. Merke: kein % vorn wo es nicht unbedingt nötig ist. Faszinierend. 🙂

either builds play a winning your champion picks either Item builds play a rather weak and useless one in scrimmages and carry You’ll be able to win your enemy again Become unbeatable and scale into mid lane adc and gain the biggest opportunity to single handily carry your champion picks either Item builds play a 2v2 matchup is by purchasing LoL Counter Pick is the enemy again Become unbeatable and roam the reality is the LoL hero counters pick your team fights

Support plays a ton of item team on one in League of bonus content such as patch release If you’ve followed us on counter pick This gives you have to victory the most in MOBA’s such as