This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
An import is a count you can check
Import and export move rows between a file and a table. The bulk-load builder drafts a command. The CSV tool drafts insert statements. Both run in the browser. You run the real load on a database you administer, against a file you are allowed to hold.
Count the file before you load it. Count the table after. If the numbers disagree, the load is not finished and the rows are not ready for anyone else. A silent truncation is still a disagreement.
The first load goes to a lab table. Production is a later copy of a load that already matched. A personal or customer file does not get pasted into the ticket and does not get uploaded to a random converter. The columns you do not need are dropped before the file spreads.
Character set and dates are part of the count. A file of dates that landed as nulls is a failed load even when the row count matches. Look at one row you understand.
A small file you typed, then the real file
Make a three-line file yourself. Load it into a lab table. The count is three. One date looks like the date you typed. Then you may point the same command at the real file, still on the lab, still into an empty table.
Read the drafted command. A path that points at production, or a mode that replaces a table, is a path you change. The table name in the prompt is the lab name.
If the file has addresses, emails, or other personal data, the ticket records the column names and the count, not a sample row. The security and privacy habits apply: you hold this file because your job says so.
Export is the same discipline in the other direction. An export file is not world-readable, and it is not the backup. The backup guide is the restore you trust.
A change you can finish
Production receives the load only after the lab counts matched and a person has looked at one row.
Rollback is truncating or dropping the lab table you loaded. You do not roll back by editing the file and loading again on top of a half-finished table.
- Confirm you may hold the file.
- Count its rows and name the columns.
- Load a three-line practice file into the lab.
- Load the real file into an empty lab table.
- Match the count. Read one non-secret row.
- Restrict the file mode.
- Leave production for a later ticket.
Mistakes that outlive the command
database import and export fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Loading straight into production.
- A count you never compared.
- A sample of personal data in the ticket.
- A command that replaces a table you meant to keep.
- Dates that became nulls, ignored because the count matched.
- A world-readable export.
- Calling the export a backup.
- A file from a system you do not administer.
- Two loads into the same table without emptying it.
- A generated insert script run unread.
Decisions to write down before the window
One decision for database import and export: You are allowed to hold the file. The row count of the file is written before the load. The target is an empty lab table. The after count matches. One real row was inspected without copying it into the ticket if it is personal. Character set or date problems are either absent or the open item. The file is not world-readable. Production is unchanged. Rollback is emptying the lab table. The backup guide owns recovery. This page owns the file. The SQL guide owns a later transform. And one file is this window.
The hour you stop
Write the database name, the host, and the clock time before you change anything for database import and export. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.
One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.
A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.
Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.
Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next database waits until someone else can repeat the proof from the notes. database import and export is done for this window when the proof is written, not when the client printed a prompt.
This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.
Import checks before the table is handed to anyone
Confirm this before you call the change done: The file's row count is in the ticket. The lab table count matches. A date or a key column looks right. No personal sample sits in the ticket. The command does not name production. The table was empty before the load. The file mode is restricted. A practice file succeeded first. A second person saw the two counts. Export, if you made one, is not called a backup. The drafted command was read. Production was not loaded. The hostname in the prompt matches the hostname in the ticket for database import and export. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database import and export happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- How-To: Importing CSV into a Database
- How-To: Converting JSON and Excel to SQL
- How-To: Exporting Query Results to CSV, JSON and HTML
- Comparison: Bulk Loading Data Fast (COPY, LOAD DATA, BULK INSERT)
- Cheat Sheet: Data Types Cheat Sheet
- How-To: Generating Realistic Test Data
- Comparison: SQL vs MongoDB Query Syntax
- Explainer: Character Sets and Collations Explained
- Explainer: Parquet and Avro for DBAs