phpMyAdmin-ის import და export: ლიმიტები, charset-ები და გამოსწორებები

ბაზის ასლის გასაკეთებლად: Export, აირჩიე Custom, ფორმატი SQL, compression-ში მონიშნე gzipped და დააჭირე Go. მის დასაბრუნებლად: Import, აირჩიე ფაილი, შეამოწმე, რომ character set-ში წერია utf-8, და დააჭირე Go. როცა ყველაფერი გამართულად მუშაობს, მთელი საქმე ესაა, და უმეტესად მართლაც ასე ხდება. როცა არ მუშაობს, თითქმის ყოველთვის სამიდან ერთია: ფაილი Import გვერდზე დაწერილ ატვირთვის ლიმიტზე დიდია, ფაილის character set სამიზნე ბაზისას არ ემთხვევა, ან dump-ში არის ობიექტი, რომლის შექმნის უფლებაც შენს ბაზის მომხმარებელს არ აქვს. ეს გზამკვლევი ჯერ ორივე ჩანართს დეტალურად განიხილავს, შემდეგ კი ამ პრობლემებს სათითაოდ.

phpMyAdmin ვებ ინტერფეისია, ვებ ინტერფეისებს კი timeout-ები და ატვირთვის ჭერი აქვთ, რაც ბრძანების ხაზს არ აქვს. ეს ერთი წინადადება ხალხის უმეტესი გაღიზიანების მიზეზს ხსნის. როცა იცი, სად არის ჭერი და რა სამი გზით შეიძლება მისი გვერდის ავლა, ორსაათიანი ჭიდილი ხუთწუთიან საქმედ იქცევა.

რა არის phpMyAdmin და რა არ არის#

phpMyAdmin არის PHP აპლიკაცია, რომელიც შენს მაგივრად MySQL-თან თავსებად ბაზის სერვერს ესაუბრება. ის თავად ბაზა არ არის. მას საკუთარი საცავი არ აქვს, შენი მონაცემების ასლს არ ინახავს და მისი წაშლა არაფერს შლის. ყველაფერი, რასაც ის აკეთებს, არის query, რომელსაც შენც შეგეძლო თვითონ აგერიფა, ამიტომაც არსებობს SQL ჩანართი და ამიტომ ღირს ერთხელ მაინც დააჭირო ღილაკს "Show SQL", რომელიც უმეტეს ოპერაციას ახლავს.

აქედან ორი შედეგი გამომდინარეობს და ორივე მნიშვნელოვანია import-ისა და export-ისთვის:

• ყველაფერი PHP-ის ერთი request-ის შიგნით სრულდება. request-ს დროის ლიმიტი აქვს ($cfg['ExecTimeLimit'], ნაგულისხმევად 300 წამი) და მეხსიერების ლიმიტიც, ხოლო მის წინ მდგარ ვებ სერვერს - საკუთარი. dump, რომლის import-საც ოთხი წუთი სჭირდება, პრობლემა არ არის. ის, რომელსაც ორმოცი წუთი სჭირდება, ბრაუზერის გავლით ვერ დასრულდება, რასაც არ უნდა უშვრებოდე.
• ის მხოლოდ იმას აკეთებს, რისი გაკეთებაც შენს ბაზის მომხმარებელს შეუძლია. phpMyAdmin პრივილეგირებული უკანა კარი არ არის. თუ შენს ბაზაზე მიბმულ მომხმარებელს trigger-ის შექმნის უფლება არ აქვს, import, რომელიც trigger-ს შეიცავს, ამ ხაზზე გაჩერდება, რომელი პარამეტრიც არ უნდა მონიშნო.

phpMyAdmin ასევე კონკრეტულად MySQL ოჯახის ხელსაწყოა. ის PostgreSQL-ს ან MongoDB-ს ვერ მართავს და ვერანაირი კონფიგურაცია ამას ვერ შეცვლის. თუ შენი ბაზა Postgres-ია, იგივე საქმეს pg_dump და pg_restore აკეთებს; თუ Mongo-ა - mongodump და mongorestore. ამ პოსტის დანარჩენი ნაწილი ვარაუდობს, რომ შენ წინ სწორედ phpMyAdmin გიდგას.

ბაზის slot-ის გახსნა panel-ზე დაფუძნებულ ჰოსტზე#

panel-ზე დაფუძნებულ ჰოსტზე phpMyAdmin-ს შენ არ აყენებ და არც იცი, სად დგას. გეგმაში შედის გარკვეული რაოდენობის ბაზის slot-ები და თითოეული იქმნება panel-ის Databases ჩანართიდან. შექმნისას გენერირდება ოთხი მნიშვნელობა, რომლებიც კიდევ დაგჭირდება:

სწორედ ეს ოთხი მნიშვნელობა მიდის wp-config.php-ში, .env ფაილში ან connection string-ში. კოდში და ვერსიების კონტროლში ნუ შეინახავ - გარემოს ცვლადები და საიდუმლოებები ხსნის, სად უნდა ინახებოდეს ისინი.

RE:NODE-ზე იმავე ჩანართში არის ღილაკი Open in phpMyAdmin. ის შენ შეგიყვანს ერთჯერადი token-ით, რომელიც 60 წამში იწურება, ამიტომ ბმულის გადაგზავნა, bookmark-ში შენახვა ან ხელახლა გამოყენება შეუძლებელია: თუ გახსნი და ყავის დასასხმელად წახვალ, დაბრუნებისას login გვერდს ნახავ და ღილაკს ისევ დააჭერ. ბაზის slot-ები შედის ყველა გეგმაში, სადაც ისინი გათვალისწინებულია - ერთი გეიმ გეგმაში, ორი აპლიკაციისა და ვებ გეგმებში - ხოლო credentials თითოეულ ბაზას ეკუთვნის და არა ანგარიშს. ბაზების ჰოსტინგის ხაზი სხვა პროდუქტია: ისინი PostgreSQL და MongoDB სერვერებია საკუთარი superuser-ით და phpMyAdmin-ს მათთან საერთო არაფერი აქვს.

Export: quick, custom და პარამეტრები, რომლებსაც მნიშვნელობა აქვს#

ჯერ მარცხენა ხეში აირჩიე ბაზა და არა ცხრილი, თუ მართლა ერთი ცხრილი არ გჭირდება. შემდეგ Export. შეთავაზებულია ორი მეთოდი.

Quick გაძლევს უბრალო .sql ფაილს გონივრული ნაგულისხმევი პარამეტრებით. ეს სწორი არჩევანია პატარა ბაზისთვის, რომელსაც მალე მსგავს გარემოში ისევ ჩატვირთავ.

Custom ყველაფერს გიჩვენებს და ყველაფრისთვის, რაც შენთვის მნიშვნელოვანია, ის გამოიყენე. პარამეტრები, რომლებიც შედეგს ცვლის:

"Object creation options"-ში ცალკე მონიშვნის ველებია view-ებისთვის, routine-ებისთვის (procedure-ები, function-ები და event-ები) და trigger-ებისთვის. ისინი ყველა ვერსიაში ნაგულისხმევად ჩართული არ არის, და განსხვავება dump-ს შორის, რომელიც მოქმედ აპლიკაციას აღადგენს, და იმას შორის, რომელიც მკვდარს აღადგენს, ხშირად დაკარგული stored procedure-ია. მონიშნე ისინი, შემდეგ გახსენი dump და მოძებნე CREATE PROCEDURE და CREATE TRIGGER, რომ დარწმუნდე, რომ ისინი იქ არის.

"Extended inserts" არის ყველაზე დიდი ერთეული ბერკეტი წარმადობისთვის. როცა ის გამორთულია, თითო სტრიქონზე თითო INSERT მიიღება, რაც მილიონსტრიქონიანი ცხრილისთვის SQL parser-ში მილიონ ჩავლას ნიშნავს. როცა ჩართულია, თითო ჯგუფზე ერთი ბრძანება მიიღება:

INSERT INTO `orders` (`id`, `total`, `created_at`) VALUES(1, 19.99, '2026-08-01 09:12:44'),(2, 42.50, '2026-08-01 09:31:02'),(3, 7.00,  '2026-08-01 10:04:19');

ჯგუფის ზომას განსაზღვრავს "Maximal length of created query". დატოვე ნაგულისხმევი, თუ import არ ჩავარდება შეცდომით 2006, რომელიც packet ლიმიტია და ქვემოთ არის განხილული.

და ბოლოს, აირჩიე "Save output to a file" და ნუ დატოვებ SQL-ს ბრაუზერში გამოსატანად. 200 MB-იანი dump, რომელიც ვებ გვერდად არის ნაჩვენები, მთელ tab-ს დაბლა წაიყოლებს.

Character set-ები, ანუ რატომ გადაიქცა შენი ტექსტი კითხვის ნიშნებად#

ეს არის ყველაზე გავრცელებული გზა, რომლითაც import "წარმატებით" სრულდება და მონაცემებს აფუჭებს. MySQL-ის character set, რომელსაც utf8 ჰქვია, UTF-8 არ არის. ის სამბაიტიანი ქვესიმრავლეა, სწორი სახელით utf8mb3, და ვერაფერს ინახავს ძირითადი მრავალენოვანი სიბრტყის გარეთ: ვერც emoji-ს, ვერც ზოგიერთ იშვიათ CJK სიმბოლოს, ვერც მათემატიკურ ნიშნებს. ნამდვილი ვარიანტია utf8mb4. თანამედროვე MySQL 8 ნაგულისხმევად utf8mb4-ს იყენებს; უფრო ძველი სერვერები და ძველი MariaDB ინსტალაციები ხშირად latin1-ზე არიან, და წლების წინ შექმნილი ბაზა ინარჩუნებს იმას, რითაც შეიქმნა.

ნებისმიერი export-ის წინ შეამოწმე, რა გაქვს:

SHOW VARIABLES LIKE 'character_set_%';SHOW CREATE DATABASE `shop`;SELECT table_name, table_collation FROM information_schema.tables  WHERE table_schema = 'shop';

phpMyAdmin-ის export ფაილის თავში საკუთარ დეკლარაციას წერს, რაც dump-ს გადატანადს ხდის:

/*!40101 SET NAMES utf8mb4 */;SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";START TRANSACTION;SET time_zone = "+00:00";

Import ჩანართზე არის dropdown სახელით "Character set of the file". ის უნდა ემთხვეოდეს იმ ბაიტებს, რომლებიც ფაილში მართლა წერია, და არა იმას, რაც შენ გინდა, რომ იყოს. თუ export-მა utf8mb4 დაწერა და შენ latin1-ით ჩატვირთე, ყოველი აქცენტიანი სიმბოლო ორ სიმბოლოდ იქცევა და import წარმატებას აცხადებს. არაფერი გაფრთხილებს. ზიანი მხოლოდ მაშინ ჩანს, როცა ვინმე გვერდს გახსნის და იქ, სადაც é იყო, é დახვდება.

სამი წესი, რომელიც პრობლემის მთელ კატეგორიას გაარიდებს:

1. გამოიყენე ერთი და იგივე character set export-სა და import-ში და ორივე მხარეს utf-8 ამჯობინე.
2. თუ წყარო ბაზა latin1-ია და სამიზნეზე utf8mb4 გინდა, გადაიყვანე import-ის შემდეგ ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4-ით და არა იმპორტერისთვის მცდარი ინფორმაციის მიწოდებით.
3. dump ნუ გახსნი ტექსტურ რედაქტორში, რომელიც ფაილს სხვა კოდირებით ინახავს. Windows-ის Notepad-მა ასე მთელი ბაზები დააკარგვინა ხალხს.

dump-ის import#

Import, აირჩიე ფაილი, დარწმუნდი, რომ ფორმატი SQL და character set სწორია, დააჭირე Go. ამ გვერდზე გასაგები რამდენიმე რამ:

• მაქსიმალური ზომა გვერდზეა დაწერილი, მაგალითად "Max: 2,048KiB". ის მოდის PHP-ის upload_max_filesize და post_max_size პარამეტრებიდან, რომელიც უფრო მცირეა, და ჩვეულებრივ phpMyAdmin-ის შიგნიდან მას ვერ შეცვლი.
• შეკუმშული ფაილები პირდაპირ მიიღება. ფაილი სახელით shop.sql.gz ან shop.sql.zip შემოსვლისას იშლება, ხოლო რადგან ლიმიტი ატვირთულ ბაიტებზე მოქმედებს, gzip-ით შეკუმშული dump შენს ეფექტურ ჭერს დაახლოებით ათჯერ ზრდის. ეს ყველაზე მარტივი მოგებაა და უმეტესობა მას აცდენს.
• ნაწილობრივი import-ს ორი კონტროლი აქვს: "Allow the interruption of an import in case the script detects it is close to the PHP timeout limit" და "Skip this number of queries starting from the first one". ერთად ისინი გაგრძელების საშუალებას გაძლევს. თუ import 4,000 query-ის შემდეგ გაჩერდა, მონიშნე ველი, skip-ში ჩაწერე 4,000 და იგივე ფაილი ისევ გაუშვი.
• SQL compatibility mode NONE-ზე უნდა დარჩეს, თუ არ ატვირთავ dump-ს ბევრად უფრო ძველი სერვერიდან და არ იცი, რომელი mode სჭირდება.

Import ცარიელ ბაზაში გააკეთე, სადაც კი შეგიძლია. არსებული ცხრილების თავზე import არის გზა ნახევრად შერეული მონაცემებისკენ, რომლებიც კარგად გამოიყურება მანამ, სანამ foreign key არარსებულ სტრიქონზე არ მიუთითებს. შექმენი ახალი ბაზა, ჩატვირთე, შეამოწმე, შემდეგ გადართე აპლიკაცია.

თუ dump-ში ცხრილები ერთმანეთს ეხმიანება და თანმიმდევრობა არასწორია, გამოსავალი ისაა, რომ import-ის გარშემო შემოწმებები გამორთო და არა ფაილი ხელით გადაალაგო:

SET FOREIGN_KEY_CHECKS = 0;-- paste or run the dump hereSET FOREIGN_KEY_CHECKS = 1;

ისინი იმავე სესიაში დააბრუნე და შემდეგ გაუშვი query, რომელიც დაამტკიცებს, რომ არცერთი ობოლი ჩანაწერი არ გავიდა. foreign key შემოწმებების სამუდამოდ გამორთული დატოვება გამოსწორება არ არის, ეს არის გადაწყვეტილება, რომ მოგვიანებით გაიგო.

დიდი ფაილის ჩატვირთვა, როცა ატვირთვის ლიმიტი უფრო მცირეა#

ამას აუცილებლად შეეჯახები. იმ თანმიმდევრობით, რამდენადაც უნდა მოგწონდეს:

1. შეკუმშე dump gzip-ით. გააკეთე export შეკუმშვით ან ლოკალურად გაუშვი gzip shop.sql. 300 MB-იანი dump 30-60 MB ხდება, რაც ჩვეულებრივ თავისთავად ჯდება ლიმიტში.
2. გახლიჩე ფაილი. SQL dump-ები სტრიქონებზეა დაფუძნებული, ამიტომ split მუშაობს, თუ ბრძანების საზღვრებზე ჭრი და header პირველ ნაწილთან რჩება. ამისთვის განკუთვნილი dump splitter თვალით ჭრაზე უფრო უსაფრთხოა.
3. გამოიყენე "web server upload directory" dropdown. თუ ჰოსტს $cfg['UploadDir'] დაყენებული აქვს, ფაილი შეგიძლია SFTP-ით ან ფაილ მენეჯერით სერვერზე დადო და phpMyAdmin-ში აირჩიო ბრაუზერით ატვირთვის ნაცვლად. ეს ატვირთვის ლიმიტს მთლიანად ავლის გვერდს, დროის ლიმიტს კი - არა. SFTP და ფაილ მენეჯერი აღწერს, როგორ აიტანო იქ ფაილი.
4. გამოტოვე და გააგრძელე. ნაწილობრივი import, როგორც ზემოთ. დამღლელია, მაგრამ საიმედო.
5. გამოიყენე ბრძანების ხაზი, თუ გაქვს. VDS-ზე shell წვდომით ჭერი უქმდება:

$ gunzip -c shop.sql.gz | mysql -h db.example.net -u shopuser -p shop

გაზიარებული ვებ ან გეიმ გეგმა shell-ს არ გაძლევს, ამიტომ იქ რეალური სია 1-დან 4-მდე ვარიანტებია. თუ ამას ყოველთვიურად აკეთებ, ეს არგუმენტია, რომ ბაზა ისეთ ადგილას გქონდეს, რომელსაც ტერმინალიდან მიწვდები - იხილე VDS თუ გეიმ panel პატიოსანი შედარებისთვის.

ძალიან დიდ ბაზებს სულ სხვა პასუხი აქვს: თუ შეგიძლია, ისინი ლოგიკური dump-ით საერთოდ ნუ გადაგაქვს. დაახლოებით 5 GB-ს ზემოთ import-ის დრო საათებში იზომება და სწორი მიდგომა ჩვეულებრივ replication ან ფაილის დონეზე კოპირებაა, რომელთაგან ორივეს ორივე სერვერზე ადმინისტრატორის წვდომა სჭირდება.

რას არ შეიცავს export#

ბაზის export ერთი ბაზის აღწერაა. მისი აღდგენა იმას არ აღადგენს, რაც მის გვერდით ცხოვრობს:

• მომხმარებლები და მათი grant-ები. ისინი სერვერის საკუთარ სისტემურ ცხრილებში ინახება, რომლებსაც შენ არ ექსპორტირებ. ახალ ჰოსტზე import-ის შემდეგ ქმნი ახალ მომხმარებელს და მას ახალ ბაზაზე უფლებებს აძლევ. თუ აპლიკაციის connection string-ში ძველი მომხმარებლის სახელი რჩება, კავშირი ვერ დამყარდება და შენ import-ს დაადანაშაულებ.
• ყველაფერი სხვა ბაზებში. ბაზებს შორის view-ები და query-ები ჩუმად ტყდება, სანამ რამე არ გამოიძახებს მათ.
• სერვერის კონფიგურაცია. packet-ის ზომები, timeout-ები, SQL mode, time zone ცხრილები. query, რომელიც ერთ სერვერზე მუშაობდა, მეორეზე შეიძლება ჩავარდეს, რადგან sql_mode განსხვავდება, ყველაზე ხშირად STRICT_TRANS_TABLES უარყოფს ნულოვან თარიღს, რომელსაც ძველი სერვერი იღებდა.
• ფაილები. ატვირთული სურათები, WordPress-ის wp-content საქაღალდე, მომხმარებლების ავატარები. ბაზა მათ გზებს ინახავს და არა თავად ბაიტებს. საიტის მიგრაცია ყოველთვის ორი საქმეა, და WordPress-ის ახალ ჰოსტზე გადატანა ორივეს გადის.
• view-ების, trigger-ებისა და routine-ების `DEFINER` ანგარიშები გამოსადეგი სახით. სახელები გადმოდის, მაგრამ ისინი მომხმარებლებზე მიუთითებს, რომლებიც სამიზნეზე შეიძლება არ არსებობდეს, რაც შეცდომას 1227 იწვევს.

export ასევე არ არის backup სტრატეგია, რადგან backup, რომელსაც ხელით იღებ, backup-ია, რომლის აღებასაც შეწყვეტ. დააყენე ის განრიგზე, შეინახე ერთზე მეტი თაობა და ხანდახან აღადგინე ერთ-ერთი, რომ დაამტკიცო, რომ მუშაობს. ბაზის backup-ები და აღდგენა უფრო გრძელი არგუმენტია, ხოლო აღდგენის შემოწმება, სანამ დაგჭირდება ის ნაწილია, რომელსაც ხალხი აცდენს.

შეცდომები და რას ნიშნავს თითოეული#

ამათგან ორს ცხრილის სტრიქონზე მეტი ეკუთვნის.

შეცდომა 1227 და `DEFINER`. View-ები, trigger-ები, procedure-ები და event-ები ექსპორტირდება იმ ანგარიშით, რომელმაც ისინი შექმნა, ბრძანებაში ჩაქსოვილი სახით DEFINER=old_user@localhost. ახალ ჰოსტზე ეს ანგარიში არ არსებობს და მისი გამოგონების უფლება არ გაქვს, ამიტომ ბრძანება უარყოფილია. გამოსწორება არის ძებნა და ჩანაცვლება dump-ში import-მდე: წაშალე ყოველი DEFINER= ფრაგმენტი და მის შემდეგ მდგარი მომხმარებლის სახელი, CREATE VIEW ან CREATE TRIGGER ბრძანება კი ხელუხლებელი დატოვე. მაშინ ობიექტები შენი სახელით შეიქმნება, რაც გინდა.

შეცდომა 2006 და packet ლიმიტი. max_allowed_packet ერთი ბრძანების ზომას ზღუდავს. extended insert, რომელიც დიდი text ან blob სვეტებიანი ცხრილიდან აიგება, შეიძლება მას გადასცდეს. გაუშვი export ხელახლა და "Maximal length of created query" დააყენე უფრო დაბლა - 16000 უსაფრთხო მნიშვნელობაა - და იგივე მონაცემები უფრო მრავალი, უფრო პატარა ბრძანებით მოვა. იგივე შეცდომა ჩნდება მაშინაც, როცა კავშირმა import-ის შუაში უბრალოდ timeout-ი მიიღო, რაც სხვა პრობლემაა იგივე შეტყობინებით.

პრაქტიკული მაგალითი: საიტის გადატანა ახალ ჰოსტზე#

თანმიმდევრობას მნიშვნელობა აქვს, რადგან მიზანია, რომ ასლის აღების შემდეგ ძველ ბაზაში ჩაწერა არ მოხდეს.

1. გადაიყვანე საიტი maintenance რეჟიმში, ან შეეგუე, რომ ყველაფერი, რაც ახლიდან ჩაიწერება, დაიკარგება.
2. ძველი ჰოსტის phpMyAdmin-ში: Export, Custom, SQL, gzipped, DROP TABLE ჩართული, view-ები და routine-ები მონიშნული, შეინახე ფაილში. შეამოწმე, რომ ფაილის ზომა დამაჯერებელია - 4 KB-იანი dump ცოცხალი მაღაზიისთვის ნიშნავს, რომ არასწორი რამ გაიტანე.
3. ახალ ჰოსტზე შექმენი ბაზის slot და ჩაინიშნე host, სახელი, მომხმარებელი და პაროლი.
4. გახსენი phpMyAdmin panel-იდან, აირჩიე ახალი ბაზა, Import, აირჩიე .sql.gz ფაილი, character set utf-8, Go.
5. შეადარე სტრიქონების რაოდენობა ორივე მხარეს ყველაზე დიდ სამ ცხრილში SELECT COUNT(*)-ით. ამას ერთი წუთი სჭირდება და შეწყვეტილ import-ს მაშინვე იჭერს.
6. განაახლე აპლიკაციის credentials ახალი host-ით, სახელით, მომხმარებლითა და პაროლით. WordPress-ისთვის ეს ოთხი ხაზია wp-config.php-ში.
7. გადაიტანე ფაილები, შემდეგ DNS ახალ მისამართზე მიმართე. DNS ჩანაწერები ახსნილი გეუბნება, რომელი ჩანაწერი შეცვალო; ძველი სერვერი ჩართული დატოვე, სანამ ცვლილება არ გავრცელდება.
8. dump ფაილი ორი კვირა შეინახე. ის არაფერი ღირს და ერთადერთი გზაა უკან.

თუ საიტი ბაზაში აბსოლუტურ URL-ებს ინახავს, როგორც WordPress აკეთებს, პირდაპირი import მას ძველ დომენზე მიმართულს დატოვებს. ნუ გაუშვებ უბრალო UPDATE ... REPLACE-ს კონტენტზე: სერიალიზებული PHP მასივები საკუთარი სტრიქონის სიგრძეებს ინახავს და უბრალო ჩანაცვლება მათ ანადგურებს. გამოიყენე search-replace ხელსაწყო, რომელიც სერიალიზაციას იცნობს, ან WP-CLI-ის search-replace, რომელიც ამას აკეთებს.

FAQ#

რატომ ჩერდება ჩემი import შუაში შეცდომის გარეშე?

თითქმის ყოველთვის PHP-ის დროის ლიმიტის გამო. request მოკლეს, სანამ import ჯერ კიდევ მიმდინარეობდა, ამიტომ ბრაუზერი შეწყვეტილ ან ცარიელ გვერდს აჩვენებს. მონიშნე "Allow the interruption of an import", ჩაინიშნე, რამდენი query დასრულდა და გაუშვი ფაილი ხელახლა ამ რიცხვით skip ველში.

შემიძლია მხოლოდ ერთი ცხრილის export?

დიახ. Export-ზე დაჭერამდე აირჩიე ცხრილი მარცხენა ხეში, ან აირჩიე ბაზა და Custom-ში მიუთითე, რომელი ცხრილები შევიდეს. გახსოვდეს, რომ foreign key-ებიან ნაკრებიდან ამოღებული ერთი ცხრილი ცარიელ ბაზაში თავისით არ ჩაიტვირთება.

უსაფრთხოა gzip-ით შეკუმშული export-ის backup-ად შენახვა?

ეს ბაზის სწორი ლოგიკური ასლია იმ მომენტისთვის, როცა აიღეს, და ის ნებისმიერ თავსებად სერვერზე აღდგება. რაც ის არ არის: ავტომატური, შემოწმებული, ან შენახული სადმე, გარდა იმ ადგილისა, სადაც შენ დადე. ის სამიდან ერთ ასლად მიიჩნიე და დროდადრო შეამოწმე, რომ ისევ იხსნება.

Import გვერდზე წერია Max 2,048KiB, ჩემი ფაილი კი 40 MB-ია. შემიძლია გავზარდო?

phpMyAdmin-ის შიგნიდან - არა, ეს PHP-ის პარამეტრია ვებ სერვერზე. ჯერ შეკუმშე ფაილი, გამოიყენე სერვერის upload directory, თუ ჰოსტი გთავაზობს, ან გახლიჩე dump. მანქანაზე, სადაც PHP-ს შენ აკონტროლებ, upload_max_filesize და post_max_size ერთად გაზრდა საქმეს აგვარებს.

რატომ გამოიყურება ზოგი სიმბოლო არასწორად სრულიად წარმატებული import-ის შემდეგ?

ფაილის character set არ ემთხვეოდა იმას, რაც მასში იყო. ტექსტის ადგილზე გასწორების ნაცვლად აღადგინე ორიგინალი dump ახალ ცარიელ ბაზაში სწორი პარამეტრით, ხოლო რა გაქვს, შესამოწმებლად იხილე character set-ების თავი ზემოთ.

საერთოდ მჭირდება phpMyAdmin, თუ ჰოსტი ბაზას მაძლევს?

არა. ეს მოხერხებულობაა. ნებისმიერი კლიენტი, რომელიც პროტოკოლს ლაპარაკობს, გამოდგება, მათ შორის desktop ხელსაწყოები და ბრძანების ხაზი, და დიდი ან განმეორებადი საქმეებისთვის ისინი უკეთესია. phpMyAdmin თავის ადგილს იმსახურებს სწრაფი რედაქტირებისთვის, იმის სანახავად, რა არის ცხრილში სინამდვილეში, და ერთჯერადი export-ისთვის მანქანიდან, სადაც სხვა არაფერი გიდგას.