Dela upp och komprimera SQL-filer med SQL Splitter

Antingen en .sql.gz-fil som phpMyAdmin importerar direkt eller flera .sql-filer som var och en ryms inom din gräns, både separat och som ZIP. Du kan även få dem som .sql.gz eller som text att kopiera. community-db.sql med 98 KB blir 20 KB som .sql.gz eller 3 delar med målstorleken 40 KB. Varje del innehåller dumpens inledning och visas i den ordning du ska importera dem. Verktyget visar dessutom storlek, statements och tabeller för varje del.

phpMyAdmin tar emot filer via PHP, och PHP begränsar storleken på uppladdningar (upload_max_filesize och post_max_size). På våra databasservrar är gränsen 2 MB. phpMyAdmin visar den under Importera som ”Maximal storlek: 2.048 KiB”. Även text som du klistrar in på fliken SQL omfattas av gränsen. Därför finns läget ”Klistra in i SQL-konsolen” i verktyget: Det utgår från den storlek som webbläsaren faktiskt skickar och gör delarna mindre därefter.

Ofta, ja. Gränsen gäller den uppladdade filen, alltså den komprimerade, och SQL-dumpar innehåller mycket upprepad text. phpMyAdmin packar själv upp en .sql.gz vid import. SQL Splitter beräknar först storleken på .sql.gz, visar hur många gånger mindre den är och rekommenderar bara uppdelning om den komprimerade filen fortfarande överskrider din gräns.

Ladda in en .sql-, .sql.gz- eller .zip-fil i SQL Splitter, till exempel en export från mysqldump, mariadb-dump, phpMyAdmin, HeidiSQL eller Adminer. Filen delas bara mellan fullständiga satser: Verktyget känner igen strängar med escape-tecken, kommentarer, /*!…*/-rader och DELIMITER-block för triggers och procedurer. Ett semikolon inuti dem delar inte upp innehållet. Om en INSERT-sats med många rader är större än en del, delas den mellan två poster i flera INSERT-satser med samma inledning. Om en enskild post är större än målstorleken, oftast en bild i en BLOB-kolumn, anger verktyget satsnummer, rad och tabell. Importera den delen med HeidiSQL eller mysql-klienten, eller försök ladda upp den som .sql.gz.

Importera delarna i nummerordning, med del 1 först, och alla till samma databas. Del 1 innehåller oftast CREATE TABLE-satserna, medan senare delar fyller tabellerna. Om dumpen har främmande nycklar stänger varje del av kontrollen av dem i början och slår på den igen i slutet. Om en del avbryts åtgärdar du felet och fortsätter med just den delen. Importera inte tidigare delar igen, annars får du ”Table already exists” eller ”Duplicate entry”. Om du inte längre vet vad som har importerats tömmer du databasen (markera och ta bort alla tabeller på fliken Struktur i phpMyAdmin) och börjar om med del 1.

Vyer, triggers, procedurer och händelser sparar vilken användare de körs under (DEFINER). Om det står en användare från den gamla servern där, till exempel root, får din databasanvändare inte skapa dem. Markera ”Ta bort DEFINER” i verktyget, så skapar servern dem med din användare. MariaDB kallar den saknade behörigheten SET USER. Om dumpen kommer från MySQL kan även raderna SQL_LOG_BIN (behörigheten BINLOG ADMIN) och GTID_PURGED orsaka fel. För dem finns ”Ta bort replikeringsrader”.

utf8mb4_0900_ai_ci är standardkollationen i MySQL 8. MariaDB känner inte igen den, inte ens i version 11.6, och avbryter CREATE TABLE med #1273. Korrigeringen ”Ersätt MySQL 8-kollationer” byter ut den och övriga 0900-varianter mot utf8mb4_unicode_ci, och de skiftlägeskänsliga mot utf8mb4_bin. INSERT-satserna, och därmed dina data, lämnas oförändrade.

Nej. En dump innehåller ofta kunduppgifter och inloggningsuppgifter, så verktyget läser filen enbart i din webbläsare, i en Web Worker. Ingen uppladdning, lagring eller konto behövs. På fliken Nätverk i utvecklarverktygen kan du se att inga förfrågningar med din fil skickas när du komprimerar eller delar upp den.