Wenn die Datumswerte in der .csv nicht gerade zufällig im MySQL-Format vorliegen, kann ein INSERT INTO INFILE diese Daten nicht richtig in die entsprechende Spalte laden und sie werden auf 0 gesetzt.

1. Schritt: richtiges Datumsformat finden

In einer .csv Datei liegt alles nur als Text vor. Dieser Text muss nun erstmal in ein Datum verwandelt werden. Dies geschieht mit der 
STR_TO_DATE()-Funktion. Um das richtige Format zu finden, kann man nun das Datum im .csv kopieren und hier einfügen. Anschließend fummelt man so lange an dem Format, bis die Konvertierung gelingt. Das sieht dann beispielsweise so aus:

2. Schritt: richtig in INSERT INTO FILE einbauen

Leider ist es in INSERT INTO FILE nicht ganz elegant gelöst, einen Import durchzuführen, wenn die Spalten in der .csv von den Spalten in der MySQL-Tabelle abweichen. So müssen erstmal alle Spalten mit Namen in der entsprechenden Reihenfolge aufgeführt werden, also z.B. 

LOAD DATA INFILE 'C:/projects.csv'
INTO TABLE t_remote             
FIELDS TERMINATED BY ';' 
LINES TERMINATED BY '\n' 
IGNORE 1 LINES
(id, coid, comp, ptitle, ptime, ptime2, pother, parea, pdesc, purl, pextid, @created, pcity)
SET created = STR_TO_DATE(@created, '%d.%m.%Y %H:%i')
; 

Der erste Zweck von Prepared Statements ist eine schnellere Ausführung von ähnlichen SQL-Statements, die mehrfach nacheinander ausgeführt werden. Der zweite Zweck ist ein Verhindern von SQL-Injektions, also einer bestimmten Angriffsmethode. Beides haut mich jetzt nicht vom Hocker, denn der letzten Millisekunde Geschwindigkeitssteigerung jage ich nicht hinterher und ich frage mich schon, ob man SQL-Injektions nicht auch eleganter verhindern kann. Aber manchmal kommt man wohl nicht umhin, sich mit ihnen zu beschäftigen. 

Prepared Statements sind erstmal völlig unabhängig von irgendwelchen Programmiersprachen (PHP, Java, etc.) und sind erstmal Dinger, die in Datenbanken leben. Die gängigen Datenbank-Systeme (z.B. mySQL und Oracle) können Prepared Statements (Quelle)

Doch was sind Prepared Statements? Prepared Statements sind  SQL-statements, die schon mal unfertig an die Datenbank vorausgeschickt werden. Unfertig, weil sie an der ein oder anderen Stelle nur mit Platzhalten (im Romme würde man Joker sagen) gefüllt sind, damit sie in der Datenbank schon mal auf ihren Einsatz (=Ausführung) vorbereitet (daher der Name prepared statement) werden.  Da sie dort schon vorbereitet sitzen, können sie eben schneller ausgeführt werden, wenn es losgeht. Los geht’s, wenn eine Anweisung kommt, die sie namentlich aufruft und sie über die Werte informiert, die bisher nur als Platzhalter vorliegen (im Romme würde man sagen, dass der Joker beispielsweise mit der Herz 8 ausgetauscht wird).

Wie die Prepared Statements genau erzeugt werden, hat Peter Kropf in seinem Tutorial schön und einfach beschrieben.

Man kann auf jeden Fall probieren, den kompletten data-folder des kaputten mysql-servers in einen funktionierenden mysql-server zu kopieren (den dortigen data-folder zuvor natürlich wegsichern). Das hat bei uns schon einmal funktioniert

 

Falls das nicht funktioniert, ist folgender beschwerlicher Weg eine Alternative

http://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/

Method #1:

Wichtig ist, dass die innodb_file_per_table UND das log in den Optionen eingeschaltet wird, hier bsps.weise in HeidiSQL:

Außerdem ist mit „pre-existing .idb“ ein beliebiges .idb file aus den zu restorenden Tabellen gemeint. Diese beliebige .idb muss nur umbenannt werden in den Namen, den auch die .frm Datei hat: z.B. product.frm -> product.ibd

Es scheint, als Schritt 3b (also das Löschen der Datenbank nicht optional sondern verpflichtend ist), weil sonst das Inkrementieren der tablespaces nicht funktioniert.