Mysqldump cu add drop table?

Acest lucru se întâmplă deoarece sintaxa generală arată cam așa:

mysql>mysqldump --opt --all-databses > all.sql

--opt este activat implicit (ceea ce implică: --add-drop-table), așa cum este menționat în documentația MySQL.

Când eliminați --add-drop-table din această sintaxă, --add-drop-table este folosit oricum, deoarece --opt este implicit (cu excepția cazului în care utilizați --skip-opt), iar --opt include --add-drop-table. Consultați aici: https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_opt

Și, așa cum s-a menționat mai sus, nu înseamnă că tabelele dvs. sunt șterse atunci când faceți backup, ci că comenzile pentru ștergerea tabelelor sunt incluse în fișierul SQL, deoarece aceasta este ceea ce doriți pentru un dump, astfel încât să puteți importa dump-ul fără a primi erori că tabelele există deja.

Da, acest lucru ar face exact ce spune, adică ar șterge tabelul dacă acesta există deja. Vă rugăm să rețineți că creați un dump care va fi importat (în două scenarii):

1. În cazul creării unei baze de date (sau tabele) noi, instrucțiunea DROP TABLE nu face nicio diferență, deoarece nu există niciun tabel de șters.

2. Dar pentru a omite ștergerea tabelei deja existente; folosiți --skip-add-drop-table în schimb. (De asemenea, folosiți --no-create-info împreună cu --skip-add-drop-table, deoarece nu doriți nici instrucțiunea de creare a tabelului) adică:

   mysqldump --skip-add-drop-table --no-create-info -h mysqlhostserver -u mysqlusername -p databasename tablename | bzip2 -c > blog.bak.sql.bz2

Pentru informație: Nu puteți exporta mai multe tabele folosind (tablename, tablename, tablename). Fie exportați toate tabelele fără a specifica niciun nume de tabel după numele bazei de date, SAU folosiți un singur nume de tabel.

Editare

Vă rugăm să rețineți că, dacă tabela dvs. este mare, este indicat să o exportați în părți. Adică creați fișiere dump de 80k (optzeci de mii) de înregistrări (aproximativ echivalente cu 10 Mb) folosind următoarea comandă; Pentru informație: Am împărțit exportul folosind clauza WHERE în mysqldump.

mysqldump -h mysqlhostserver -u mysqlusername -p --add-drop-table --add-drop-trigger --skip-triggers --dump-date --single-transaction --where='1 limit 0,80000' databasename tablename > /home/blog1.bak.sql
mysqldump mysqlhostserver -u mysqlusername -p --skip-add-drop-table --no-create-info --dump-date --single-transaction --where='1 limit 80000,999999' databasename tablename > /home/blog2.bak.sql

Comanda de mai sus creează mai întâi fișierul cu primele 80K de înregistrări blog1.bak.sql (rețineți că am omis trigger(ele) în acest dump. Am descoperit mai târziu că, dacă primul dump avea trigger(e) asociate la inserare sau actualizare, atunci când importați acest prim fișier dump,

1. acesta va crea tabela
2. va insera înregistrările în tabela nou creată.
3. va crea trigger(e) asociate acestei tabele și le va impune

Deci, când veți importa celălalt fișier dump după primul; acesta va impune trigger(ele) (nu există nicio modalitate de a dezactiva trigger(ele) pentru moment; cu excepția rescrierii acestor trigger(e) și adăugării de cod complicat pentru a le dezactiva pentru depanare sau în cazul nostru importare). De obicei, trigger(ele) aveau cod cu join-uri la alte tabele; care ar putea să nu fie importate înainte de acest import și astfel să provoace eșecul importului.