SELECTHANDLERINSERTINSERT DELAYEDUPDATEDELETETRUNCATEREPLACELOAD DATA INFILE
DOBuy this Reference Manual in softcover from Barnes & Noble!
LOAD DATA INFILE
LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name.txt'
[REPLACE | IGNORE]
INTO TABLE tbl_name
[FIELDS
[TERMINATED BY '\t']
[[OPTIONALLY] ENCLOSED BY '']
[ESCAPED BY '\\' ]
]
[LINES TERMINATED BY '\n']
[IGNORE number LINES]
[(col_name,...)]
Команда LOAD DATA INFILE читает строки из текстового файла и вставляет их в таблицу с очень высокой скоростью. Если задано ключевое слово LOCAL, то файл читается с клиентского хоста. Если же LOCAL не указывается, то файл должен находиться на сервере. (Опция LOCAL доступна в версии MySQL 3.22.6 и более поздних.)
Если текстовые файлы, которые нужно прочитать, находятся на сервере, то из соображений безопасности эти файлы должны либо размещаться в директории базы данных, либо быть доступными для чтения всем пользователям. Кроме того, для применения команды LOAD DATA INFILE к серверным файлам необходимо обладать привилегиями FILE для серверного хоста. See section 4.2.7 Привилегии, предоставляемые MySQL.
В версиях MySQL 3.23.49 и MySQL 4.0.2 команда LOCAL не будет работать в случаях, если демон mysqld запущен с параметром --local-infile=0 или если для клиента не включена возможность поддержки LOCAL. See section 4.2.4 Вопросы безопасности, относящиеся к команде LOAD DATA LOCAL.
Если указывается ключевое слово LOW_PRIORITY, то выполнение данной команды LOAD DATA будет задержано до тех пор, пока другие клиенты не завершат чтение этой таблицы.
Если указывается ключевое слово CONCURRENT при работе с таблицами MyISAM, то другие потоки могут извлекать данные из таблицы во время выполнения команды LOAD DATA. Использование этой возможности, конечно, будет немного влиять на производительность выполнения LOAD DATA, даже если никакой другой поток не использует данную таблицу в это же время.
При применении опции LOCAL выполнение может происходить несколько медленнее в сравнении с предоставлением серверу доступа к файлам напрямую, поскольку содержимое файла должно переместиться с клиентского хоста на сервер. С другой стороны, в этом случае нет необходимости в привилегиях FILE для загрузки локальных файлов.
При использовании версий MySQL до 3.23.24 при помощи команды LOAD DATA INFILE нельзя выполнять чтение из FIFO. Если необходимо читать из FIFO (например, стандартный вывод gunzip), следует использовать LOAD DATA LOCAL INFILE.
Можно также загружать файлы данных, используя утилиту mysqlimport. Эта утилита выполняет загрузку файлов путем посылки на сервер команд LOAD DATA INFILE. Опция --local заставляет mysqlimport читать файлы данных с клиентского хоста. Можно указать параметр --compress, чтобы получить лучшую производительность при работе через медленные сети, если и клиент, и сервер поддерживают протокол сжатия данных.
В случаях, когда файлы находятся на сервере, последний действует по следующим правилам:
datadir).Отсюда следует, что файл, заданный как `./myfile.txt', читается из серверного каталога данных, в то время как файл, заданный как `myfile.txt', читается из каталога используемой базы данных. Например, следующая команда LOAD DATA читает файл data.txt в каталоге базы данных для db1, поскольку db1 является текущей базой данных, даже если эта команда явно содержит указание загрузить файл в таблицу базы данных db2:
mysql> USE db1; mysql> LOAD DATA INFILE "data.txt" INTO TABLE db2.my_table;
Ключевые слова REPLACE и IGNORE управляют обработкой входных записей, которые дублируют существующие записи с теми же величинами уникальных ключей. Если указать REPLACE, то новые строки заменят существующие с таким же уникальным ключом. Если указать IGNORE, то входные строки, имеющие тот же уникальный ключ, что и существующие, будут пропускаться. Если не указан ни один из параметров, то при обнаружении дублирующегося значения ключа возникает ошибка и оставшаяся часть текстового файла игнорируется.
Если данные загружаются из локального файла с использованием ключевого слова LOCAL, то сервер не сможет прервать передачу данных посреди этой операции, поэтому по умолчанию выполнение команды происходит так же, как и в случае, когда указывается IGNORE.
При использовании LOAD DATA INFILE на пустых таблицах MyISAM все неуникальные индексы создаются в отдельном пакете (как в REPAIR). Обычно это значительно ускоряет работу LOAD DATA INFILE в случае большого количества индексов.
Команда LOAD DATA INFILE является дополнительной к SELECT ... INTO OUTFILE. See section 6.4.1 Синтаксис оператора SELECT. Чтобы записать данные из базы данных в файл, используется SELECT ... INTO OUTFILE. Чтобы прочитать данные обратно в базу данных, используется LOAD DATA INFILE. Синтаксис FIELDS и LINES одинаков в обеих командах. Обе части являются необязательными, но если указаны оба, то FIELDS должно предшествовать LINES.
Если указывается FIELDS, то каждое из его подвыражений (TERMINATED BY, [OPTIONALLY] ENCLOSED BY, и ESCAPED BY) также является необязательным, однако необходимо указать по меньшей мере одно из них.
Если утверждение FIELDS не определено, то по умолчанию его параметры будут принимать следующие значения:
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'
Если утверждение LINES не определено, то по умолчанию оно имеет следующую структуру:
LINES TERMINATED BY '\n'
Иными словами, при установках по умолчанию команда LOAD DATA INFILE при чтении входных данных будет работать следующим образом:
И, наоборот, если действуют установки по умолчанию при записи выходных данных, команда SELECT ... INTO OUTFILE будет работать следующим образом:
Следует учитывать, что в записи FIELDS ESCAPED BY `\' необходимо указывать два обратных слеша для величины, которая должна читаться как один обратный слеш.
Опцию IGNORE number LINES можно применять для игнорирования заголовка имен столбцов в начале файла:
mysql> LOAD DATA INFILE "/tmp/file_name" INTO TABLE test IGNORE 1 LINES;
При использовании SELECT ... INTO OUTFILE совместно с LOAD DATA INFILE для того, чтобы данные из базы данных прочитать в файл, а затем - обратно из файла в базу данных, опции, обрабатывающие поля и строки, для обеих команд должны совпадать. В противном случае LOAD DATA INFILE не сможет интерпретировать содержимое данного файла правильно. Предположим, что команда SELECT ... INTO OUTFILE используется для записи в файл с полями, разделенными запятыми:
mysql> SELECT * INTO OUTFILE 'data.txt'
FIELDS TERMINATED BY ','
FROM ...;
Чтобы прочитать этот разделенный запятыми файл обратно в базу данных, корректная команда должна иметь вид:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
FIELDS TERMINATED BY ',';
Если вместо этого попытаться прочитать этот файл с помощью команды, представленной ниже, то она не будет работать, поскольку предписывает команде LOAD DATA INFILE искать символы табуляции между полями:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
FIELDS TERMINATED BY '\t';
Похожий результат получился бы, если бы каждая входная строка интерпретировалась как отдельное поле.
Команду LOAD DATA INFILE можно также использовать для чтения файлов, полученных из внешних источников. Например, поля в файле формата базе данных dBASE будут разделены запятыми и заключены в двойные кавычки. Если строки в данном файле заканчиваются символами новой строки, то для записи файла можно использовать приведенную ниже команду, в которой проиллюстрировано задание опций, обрабатывающих поля и строки:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n';
Любая из опций, обрабатывающих поля и строки, может задавать пустую строку (''). Если строка не пустая, то величины опций FIELDS [OPTIONALLY] ENCLOSED BY и FIELDS ESCAPED BY должны содержать один символ. Величины опций FIELDS TERMINATED BY и LINES TERMINATED BY могут содержать более чем один символ. Например, чтобы записать строки, заканчивающиеся парами ``возврат каретки - перевод строки'' (как в текстовых файлах MS DOS или Windows), необходимо задать следующее выражение: LINES TERMINATED BY '\r\n'.
Например, чтобы прочитать файл `jokes', в котором строки разделены символами %%, в таблицу SQL, необходимо сделать следующее:
CREATE TABLE jokes (
a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
joke TEXT NOT NULL);
LOAD DATA INFILE "/tmp/jokes.txt" INTO TABLE jokes FIELDS TERMINATED BY "";
LINES TERMINATED BY "\n%%\n" (joke);
Опция FIELDS [OPTIONALLY] ENCLOSED BY служит для управления полями, заключенными в заданные символы. Если параметр OPTIONALLY опущен, то в выводе (SELECT ... INTO OUTFILE) все поля будут заключены в символы, заданные в ENCLOSED BY. Пример такого вывода (в котором в качестве разделителя полей используется запятая) показан ниже:
"1","a string","100.20" "2","a string containing a , comma","102.20" "3","a string containing a \" quote","102.20" "4","a string containing a \", quote and comma","102.20"
Если указан параметр OPTIONALLY, то заданным в ENCLOSED BY символом выделяются только поля типа CHAR и VARCHAR:
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a \" quote",102.20 4,"a string containing a \", quote and comma",102.20
Следует учитывать, что появление символов ENCLOSED BY внутри величины поля экранируется применением перед ними префикса из ESCAPED BY. Также следует учитывать, что если в ESCAPED BY указана пустая величина, то существует возможность создать вывод, который оператор LOAD DATA INFILE не сможет правильно прочитать. Например, если символ экранирования является пустой строкой, то вывод, представленный выше, окажется таким, как показано ниже. Обратите внимание: второе поле в четвертой строке содержит запятую, следующую за кавычкой, которая (ошибочно) появляется, чтобы ограничить данное поле:
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a " quote",102.20 4,"a string containing a ", quote and comma",102.20
Для ввода символ ENCLOSED BY, если он есть, удаляется из обоих концов величин полей. (Это справедливо независимо от того, указан или нет параметр OPTIONALLY: при работе с входными данными параметр OPTIONALLY не учитывается.) Если встречается символ ENCLOSED BY, которому предшествует символ ESCAPED BY, то он интерпретируется как часть текущей величины поля. Кроме того, двойные символы ENCLOSED BY, встречающиеся внутри поля, интерпретируются как одиночные символы ENCLOSED BY, если данное поле само начинается с этого символа. Например, если указывается ENCLOSED BY '"', то кавычки обрабатываются, как показано ниже:
"The ""BIG"" boss" -> The "BIG" boss The "BIG" boss -> The "BIG" boss The ""BIG"" boss -> The ""BIG"" boss
Опция FIELDS ESCAPED BY служит для управления записью или чтением специальных символов. Если символ FIELDS ESCAPED BY не пустой, он используется в качестве префикса для следующих символов в выводе:
FIELDS ESCAPED BY
FIELDS [OPTIONALLY] ENCLOSED BY
FIELDS TERMINATED BY и LINES TERMINATED BY
0 (в действительности после экранирующего символа пишется ASCII `0', а не байт с нулевой величиной)Если символ FIELDS ESCAPED BY пустой, то никакие символы не экранируются. На самом деле указывать пустой экранирующий символ нет смысла, особенно если величины полей в обрабатываемых данных содержат какие-либо из символов, указанных в приведенном выше списке.
Если символ FIELDS ESCAPED BY не пуст, то в случае входных данных вхождения такого символа удаляются и следующий за таким вхождением символ принимается буквально как часть величины поля. Исключениями являются экранированные `0' или `N' (например, \0 или \N, если экранирующим символом является `\'). Эти последовательности интерпретируются как ASCII 0 (байт с нулевой величиной) и NULL. См. ниже правила обработки величины NULL.
Чтобы получить более полную информацию о синтаксисе экранирующего символа `\' см. раздел section 6.1.1 Литералы: представление строк и чисел.
В ряде случаев опции обработки полей и строк взаимодействуют:
LINES TERMINATED BY является пустой строкой и FIELDS TERMINATED BY является не пустой строкой, то строки также заканчиваются символами FIELDS TERMINATED BY.FIELDS TERMINATED BY и FIELDS ENCLOSED BY являются пустыми (''), то применяется формат с фиксированной строкой (без разделителей). В формате с фиксированной строкой не предусмотрены никакие разделители между полями. Вместо этого при чтении и записи величин столбцов используется ширина ``вывода'' столбцов. Например, если столбец объявлен как INT(7), значения для этого столбца записываются с использованием полей шириной 7 символов. Входные значения для этого столбца получаются чтением 7 символов. Формат с фиксированной строкой влияет также на обработку величин NULL (см. ниже). Отметим, что формат с фиксированными размерами не будет работать при использовании мультибайтного набора символов.Значения NULL в зависимости от используемых опций FIELDS и LINES будут обрабатываться по-разному:
FIELDS и LINES NULL записывается как \N для вывода и \N читается как NULL для ввода (исходя из предположения, что символ ESCAPED BY равен `\').FIELDS ENCLOSED BY не является пустым, то поле, значение которого представляет собой слово из букв NULL, читается как величина NULL (в отличие от слова NULL, заключенного между символами FIELDS ENCLOSED BY, которое читается как строка 'NULL').FIELDS ESCAPED BY является пустым, NULL записывается как слово NULL.FIELDS TERMINATED BY и FIELDS ENCLOSED BY - являются пустыми), NULL записывается как пустая строка. Отметим, что вследствие этого величина NULL и пустая строка в данной таблице будут неразличимы при записи в файл, поскольку они обе записываются как пустые строки. Если необходимо, чтобы эти величины были различными при обратном чтении файла, то не следует использовать формат с фиксированной строкой.Некоторые случаи, не поддерживаемые оператором LOAD DATA INFILE:
FIELDS TERMINATED BY и FIELDS ENCLOSED BY пустые) и столбцы типа BLOB или TEXT.LOAD DATA INFILE не сможет интерпретировать ввод правильно. Например, следующее утверждение FIELDS вызовет проблемы:
FIELDS TERMINATED BY '"' ENCLOSED BY '"'
FIELDS ESCAPED BY пустая, то содержащееся в значении поля вхождение символа FIELDS ENCLOSED BY или LINES TERMINATED BY, за которым следует символ FIELDS TERMINATED BY, приведет к преждевременному завершению чтения поля или строки командой LOAD DATA INFILE. Это происходит вследствие того, что LOAD DATA INFILE не может правильно определить, где заканчивается поле или строка.Следующий пример загружает все столбцы таблицы persondata:
mysql> LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;
Список полей не указывается, следовательно, команда LOAD DATA INFILE ожидает входные строки для заполнения каждого столбца таблицы. При этом используются значения FIELDS и LINES по умолчанию.
Если требуется загрузить только некоторые из столбцов таблицы, необходимо задать список столбцов:
mysql> LOAD DATA INFILE 'persondata.txt'
INTO TABLE persondata (col1,col2,...);
Список полей необходимо задавать и в случаях, если порядок следования полей во входном файле отличается от порядка столбцов в данной таблице. В противном случае MySQL не сможет установить соответствие вводимых полей и столбцов таблицы.
Если строка имеет слишком мало полей, то столбцы, для которых отсутствуют поля во входном файле, устанавливаются в свои значения по умолчанию. Назначение величин по умолчанию описывается в разделе section 6.5.3 Синтаксис оператора CREATE TABLE.
Значение пустого поля интерпретируется иначе, чем отсутствие значения:
0.Отметим, что это те же самые величины, которые окажутся в столбце в результате явного назначения пустой строки столбцам строкового, числового типов, либо типов даты или времени в команде INSERT или UPDATE.
Столбцы типа TIMESTAMP устанавливаются только в текущую дату или время в случаях, если для столбца назначено значение NULL или (только для первого столбца TIMESTAMP) если столбец TIMESTAMP находится вне списка полей, если такой список задан.
Если входная строка имеет слишком много полей, то лишние поля игнорируются и количество предупреждений увеличится.
Команда LOAD DATA INFILE интерпретирует все входные данные как строки, поэтому нельзя указывать числовые величины для столбцов ENUM или SET так же, как для команд INSERT. Все величины ENUM и SET должны быть заданы как строки!
При использовании C API можно получить информацию о запросе, вызвав функцию API mysql_info() по окончании запроса LOAD DATA INFILE. Ниже показан формат строки информации для этого случая:
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
Предостережения выдаются при тех же обстоятельствах, что и при записи величин командой INSERT (see section 6.4.3 Синтаксис оператора INSERT), за исключением того, что команда LOAD DATA INFILE дополнительно генерирует предупреждения, когда во входной строке слишком мало или слишком много полей. Предостережения нигде не хранятся; количество предупреждений может использоваться только для того, чтобы проверить, нормально ли выполнились указанные действия. Если необходимо точно знать причины предупреждений, то следует выполнить команду SELECT ... INTO OUTFILE в другой файл и сравнить результат с первоначальным входным файлом - это единственный способ получить такую информацию.
Если необходимо выполнить LOAD DATA для чтения из канала, можно применить следующий трюк:
mkfifo /mysql/db/x/x chmod 666 /mysql/db/x/x cat < /dev/tcp/10.1.1.12/4711 > /nt/mysql/db/x/x mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x
При использовании версии MySQL старше, чем 3.23.25, вышеприведенное можно сделать только с LOAD DATA LOCAL INFILE.
Чтобы получить более подробную информацию об эффективности INSERT в сравнении с LOAD DATA INFILE и увеличении скорости LOAD DATA INFILE, см. раздел section 5.2.9 Скорость выполнения запросов INSERT.
| Posted by Jason Titus on Friday May 17 2002, @6:24am | [Delete] [Edit] |
"The warnings are not stored anywhere; the number of warnings can only be used as an
indication if everything went well"
You have got to be kidding me. Is this done as some sort of DBA punishment? i.e. - We
KNOW what the problems were, but you'll just have to build a output file and look through
your millions of records to find them". Didn't MySQL used to put these in the errorlog,
where they belong? Go ahead and make it an option, but this is enough trouble to make
me switch back to Oracle (and that takes alot).
| Posted by on Friday May 17 2002, @6:24am | [Delete] [Edit] |
Second that. (!) I don't understand how you
write that sentance with a straight face.
| Posted by on Friday May 17 2002, @6:24am | [Delete] [Edit] |
Also, no information about which rows are skipped
is given.
| Posted by on Friday May 17 2002, @6:24am | [Delete] [Edit] |
This feature is very usefull when submitting an
INSERT from a web page. If the user hits
refresh, and reposts form data that results in a
subsequent INSERT of the same primary key data,
boom, the app breaks. This way, the user could
hit F5 till their face turns blue, and they
won't break the REPLACE statement.
| Posted by [name withheld] on Friday May 17 2002, @6:24am | [Delete] [Edit] |
I have a MyDB folder in c:\mysql\data
I place there Data.txt and when I execute
LOAD DATA LOCAL INFILE "Data.txt" INTO TABLE
MyTable it says: Command has successfully executed
but NO values are adde to MyTable.
I am under W2K
| Posted by van hoof philip on Friday May 17 2002, @6:24am | [Delete] [Edit] |
I want to syncronize my database with another
database from time to times. This means that I
will have to use the REPLACE thing. But what about
records that don't excist anylonger in the newer
database. Will they be deleted in the MySQL one ?
Is there a way to auto-delete these ? Or is the
only solution to drop my MySQL table and recreate
before I start LOAD'ing it. I am using crontab
scripts for this operation so no human interaction
is possible during these operations.
| Posted by [name withheld] on Friday May 17 2002, @6:24am | [Delete] [Edit] |
The documentation is unclear about what
constitutes a "unique" key/index in this area. It
backreferences to 'insert', but insert doesn't
have such a constraint. I've found that primary
keys are sufficiently unique, but I've had to add
primaries where I didn't want them. Perhaps I'm
missing something....
| Posted by [name withheld] on Friday May 17 2002, @6:24am | [Delete] [Edit] |
It is very frustrating to get warnings when one is
importing data into a MySQL database and not be
able to access any information about the warnings.
MySQL really needs to add a feature that will
report what a warning is ABOUT rather than just
report a warning. Ideally the information about
the warning should be provided immediately. At
the very least some sort of error-log should be
created that a user can access.
| Posted by on Friday May 17 2002, @6:24am | [Delete] [Edit] |
On the 'F5 till their face turns blue' subject...
This should be handled in the application. It
certainly doesn't hurt to tell the user, 'You've
already entered this. Please stop refreshing.'
Actually, due to the number of hyperimpatient end
lusers out there, this seems like a particularly
good idea.
| Posted by on Tuesday August 20 2002, @11:50am | [Delete] [Edit] |
It would be very helpful to have an addtional option
to "IGNORE CONSTRAINTS" during the loading
process.
| Posted by on Thursday September 5 2002, @1:34am | [Delete] [Edit] |
There is a catch with "on an empty MyISAM table, all
non-unique indexes are created in a separate batch"
since the mechanism used is a "repair with
keycache" which can be very slow if you have many
indexes. One really needs to use the mechanism to
stop keys being created and then do the repair with
myisamchk using "repair with sort" as described in
section 5.2.9 (if you can get it to work :-( )
| Posted by [name withheld] on Wednesday October 9 2002, @12:43pm | [Delete] [Edit] |
Is it possible to import data without any errors? I
only ever seem able to import half the file.
| Posted by on Monday November 11 2002, @10:08am | [Delete] [Edit] |
I agree, It is extreamly frustrating to try and
load data from a file getting warnings and not
have any idea what they are. With enough
persistance I am making some ground but geez what
a pain this is.....
| Posted by [name withheld] on Wednesday November 20 2002, @7:49am | [Delete] [Edit] |
HOLY CRAP I would LOVE to know why those
warnings occur! I got it all to work once with no
warnings... that was a good day!
| Posted by on Wednesday November 20 2002, @4:09pm | [Delete] [Edit] |
Windows users need to specify LINES TERMINATED
BY '\r\n' to load the whole file if only half the records
are appearing. Windows adds a carriage return as
well as a new line character to the end of the file.
| Posted by [name withheld] on Thursday November 21 2002, @12:35pm | [Delete] [Edit] |
Nice! abombss Totally beat me to saying the same
thing but a small addition is that NOTEPAD adds
the '\r\n' where as WORDPAD only adds '\r' for text
files.
Oddness..
| Posted by on Wednesday December 4 2002, @10:13am | [Delete] [Edit] |
Because the LOAD DATA syntax is also used by the
SELECT .. OUTFILE command, it would be useful to
have some sort of "WITH COLUMN_NAMES" clause.
This would simply exporting into spreadsheets and
other databases. If you wanted to get radical, there
could also be a "WITH COLUMN_INFORMATION"
clause that would allow self describing text files by
having the first two lines describing the column
names and the the types, respectively.
| Posted by [name withheld] on Tuesday January 7 2003, @3:10pm | [Delete] [Edit] |
Hi,
How can i run a sql script to create tables & insert data?
My sql files has a script to create all the tables i need, I can run this file on my Oracle DB and can create all the tables & basic data @ once. Could to tell me how can i run this sql file in MySQL?
Thanks
| Posted by Fred Heutte on Sunday January 26 2003, @5:04pm | [Delete] [Edit] |
Use source scriptfile from the mysql command line, or
do mysql < scriptfile from the shell or command prompt.
If you're running directly from the shell, remember to include a connect database statement before
any table-oriented commands.
See section 3.6 of the manual for additional details.
| Posted by on Sunday January 26 2003, @10:27pm | [Delete] [Edit] |
For whatever it's worth, I found that the \r\n is particularly required when the last field of your line is a text field. When I used only \n, loads with lines ending in int types had no warnings, but those ending with text (varchar) loaded every other line.
| Posted by on Sunday February 2 2003, @1:37pm | [Delete] [Edit] |
I agree it's crazy that MySQL generates a warning but won't tell you what it is. Happily, I also found documentation of a 'SHOW WARNINGS' command that's in MySQL 4.1.0. I don't have 4.1 to try it on, but it looks like it'll do the job.
http://www.mysql.com/doc/en/SHOW_WARNINGS.html
| Posted by [name withheld] on Thursday February 6 2003, @9:20am | [Delete] [Edit] |
164,000 records loaded and 2 warnings? Where? Have the folks at MySQL even put this in the "to-do" list? I don't recall seeing it in the past. Subqueries would be great, but I have to believe warnings descriptions would be an easy and welcome addition. After all, the program is already doing the hard part, validating the data.
MySQL AB; please help us out by telling us what isn't right with our load.
| Posted by Steve Rock on Saturday February 8 2003, @4:38pm | [Delete] [Edit] |
TIP: Importing Quoted CSV Data to MySQL Table on Win98 (and perhaps others)
If the default line termination fails, try:
LOAD DATA INFILE 'drive:/path/filename.csv'
INTO TABLE dbname.tblname
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\r\n' <--default \n failed
(fieldname1, fieldname2, ...) <--fields previously defined in a CREATE TABLE
| Posted by Ryan Bates on Wednesday February 19 2003, @3:21pm | [Delete] [Edit] |
LOAD DATA ... REPLACE seems to replace the entire row (every column) even when specifying to load data into only one of those columns--this sets every column which you did not specify to its default value. I think a more useful feature would be to replace only the specified columns. I have yet to find a decent work around to update only a couple columns in a few rows using data from a text file. If someone knows of a quick and easy way to do this please let me know at: rbates at artbeats dot com.
| Posted by on Thursday February 20 2003, @7:48am | [Delete] [Edit] |
Hmm, seems like it's time to switch to another database system. Not showing warnings and therefore forcing me to dump the entire table to a file and use diff to check the differences makes me go crazy!
Anyway, using this syntax:
mysql> load data local infile '/home/koen/Cylution/Cylution_links.txt' into table Cylution_link FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\'' LINES TERMINATED BY '\n';
Query OK, 98 rows affected (0.01 sec)
Records: 98 Deleted: 0 Skipped: 0 Warnings: 2
mysql> select * from Cylution_link into outfile '/tmp/testlink.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\'' LINES TERMINATED BY '\n';
Query OK, 98 rows affected (0.00 sec)
let me check what the differences where using:
diff /tmp/testlink.txt /home/koen/Cylution/Cylution_links.txt
I also noticed that trailing spaces are trimmed from text. (Don't know if this is desired.)
| Posted by on Thursday March 6 2003, @1:34am | [Delete] [Edit] |
The query
LOAD DATA INFILE 'datafile.txt' INTO TABLE table_name (col1,col2,col3) FIELDS TERMINATED BY '|';
don't work. But replace (col1,col2,col3) to the end of query can work. like that:
LOAD DATA INFILE 'datafile.txt' INTO TABLE table_name FIELDS TERMINATED BY '|' (col1,col2,col3);
Add your own comment.