- About TiDB
- Quick Start
- Software and Hardware Requirements
- Environment Configuration Checklist
- Plan Cluster Topology
- Install and Start
- Verify Cluster Status
- Test Cluster Performance
- Backup and Restore
- Read Historical Data
- Configure Time Zone
- Daily Checklist
- Maintain TiFlash
- Maintain TiDB Using TiUP
- Modify Configuration Online
- Monitor and Alert
- TiDB Troubleshooting Map
- Identify Slow Queries
- Analyze Slow Queries
- SQL Diagnostics
- Identify Expensive Queries
- Statement Summary Tables
- Troubleshoot Hotspot Issues
- Troubleshoot Increased Read and Write Latency
- Troubleshoot Cluster Setup
- Troubleshoot High Disk I/O Usage
- Troubleshoot Lock Conflicts
- Troubleshoot TiFlash
- Troubleshoot Write Conflicts in Optimistic Transactions
- Performance Tuning
- System Tuning
- Software Tuning
- SQL Tuning
- Understanding the Query Execution Plan
- SQL Optimization Process
- Logic Optimization
- Physical Optimization
- Prepare Execution Plan Cache
- Control Execution Plans
- Multiple Data Centers in One City Deployment
- Three Data Centers in Two Cities Deployment
- Best Practices
- Use Placement Rules
- Use Load Base Split
- Use Store Limit
- TiDB Tools
- Use Cases
- TiDB Operator
- Backup & Restore (BR)
- TiDB Binlog
- TiDB Lightning
- TiDB Data Migration
- Cluster Architecture
- Key Monitoring Metrics
- SQL Language Structure and Syntax
- SQL Statements
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
CREATE [GLOBAL|SESSION] BINDING
CREATE TABLE LIKE
DROP [GLOBAL|SESSION] BINDING
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [GLOBAL|SESSION] BINDINGS
SHOW CHARACTER SET
SHOW [FULL] COLUMNS FROM
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DRAINER STATUS
SHOW [FULL] FIELDS FROM
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW [FULL] PROCESSSLIST
SHOW PUMP STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
- Data Types
- Functions and Operators
- Type Conversion in Expression Evaluation
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Window Functions
- Miscellaneous Functions
- Precision Math
- Set Operations
- List of Expressions for Pushdown
- TiDB Specific Functions
- Clustered Indexes
- Generated Columns
- SQL Mode
- Garbage Collection (GC)
- Character Set and Collation
- System Tables
- TiDB Dashboard
- Overview Page
- Cluster Info Page
- Key Visualizer Page
- Metrics Relation Graph
- SQL Statements Analysis
- Slow Queries Page
- Cluster Diagnostics
- Search Logs Page
- Profile Instances Page
- Session Management and Configuration
- Command Line Flags
- Configuration File Parameters
- System Variables
- Storage Engines
- Errors Codes
- Table Filter
- Schedule Replicas by Topology Labels
- Release Notes
- All Releases
This document describes how to migrate data from CSV files to TiDB using TiDB Lightning. For information about how to generate CSV files from MySQL, see Export to CSV files using Dumpling.
TiDB Lightning supports reading CSV (comma-separated values) data source, as well as other delimited format such as TSV (tab-separated values).
A CSV file representing a whole table must be named as
db_name.table_name.csv. This will be restored as a table
table_name inside the database
If a table spans multiple CSV files, they should be named like
db_name.table_name.003.csv. The number part do not need to be continuous, but must be increasing and zero-padded.
The file extension must be
*.csv, even if the content is not separated by commas.
CSV files are schema-less. To import them into TiDB, a table schema must be provided. This could be done either by:
- Providing a file named
CREATE TABLEDDL statement, and also a file named
CREATE DATABASEDDL statement.
- Creating the empty tables directly in TiDB in the first place, and then setting
[mydumper] no-schema = truein
The CSV format can be configured in
tidb-lightning.toml under the
[mydumper.csv] section. Most settings have a corresponding option in the MySQL
LOAD DATA statement.
[mydumper.csv] # Separator between fields. Must not be empty. It is not recommended to use the default ','. It is recommended to use '\|+\|' or other uncommon character combinations. separator = ',' # Quoting delimiter. Empty value means no quoting. delimiter = '"' # Whether the CSV files contain a header. # If `header` is true, the first line will be skipped. header = true # Whether the CSV contains any NULL value. # If `not-null` is true, all columns from CSV cannot be NULL. not-null = false # When `not-null` is false (that is, CSV can contain NULL), # fields equal to this value will be treated as NULL. null = '\N' # Whether to interpret backslash escapes inside fields. backslash-escape = true # If a line ends with a separator, remove it. trim-last-separator = false
In all string fields such as
delimiter, if the input involves special characters, you can use backslash escape sequence to represent them in a double-quoted string (
"…"). For example,
separator = "\u001f" means using the ASCII character 0x1F as separator.
Additionally, you can use single-quoted strings (
'…') to suppress backslash escaping. For example,
separator = '\t' means using the two-character string: a backslash followed by the letter "t", as the separator.
See the TOML v1.0.0 specification for details.
Defines the field separator.
Can be multiple characters, but must not be empty.
','for CSV (comma-separated values)
"\t"for TSV (tab-separated values)
"\u0001"to use the ASCII character 0x01 as separator
Corresponds to the
FIELDS TERMINATED BYoption in the LOAD DATA statement.
Defines the delimiter used for quoting.
delimiteris empty, all fields are unquoted.
'"'quote fields with double-quote, same as RFC 4180
Corresponds to the
FIELDS ENCLOSED BYoption in the
- Whether all CSV files contain a header row.
headeris true, the first row will be used as the column names. If
headeris false, the first row is not special and treated as an ordinary data row.
not-nullsetting controls whether all fields are non-nullable.
not-nullis false, the string specified by
nullwill be transformed to the SQL NULL instead of a concrete value.
Quoting will not affect whether a field is null.
For example, with the CSV file:
In the default settings (
not-null = false; null = '\N'), the columns
Bare both converted to NULL after importing to TiDB. The column
Cis simply the empty string
''but not NULL.
Whether to interpret backslash escapes inside fields.
backslash-escapeis true, the following sequences are recognized and transformed:
Sequence Converted to
Null character (U+0000)
Line feed (U+000A)
Carriage return (U+000D)
Windows EOF (U+001A)
In all other cases (for example,
\") the backslash is simply stripped, leaving the next character (
") in the field. The character left has no special roles (for example, delimiters) and is just an ordinary character.
Quoting will not affect whether backslash escapes are interpreted.
Corresponds to the
FIELDS ESCAPED BY '\'option in the
Treats the field
separatoras a terminator, and removes all trailing separators.
For example, with the CSV file:
trim-last-separator = false, this is interpreted as a row of 5 fields
('A', '', 'B', '', '').
trim-last-separator = true, this is interpreted as a row of 3 fields
('A', '', 'B').
TiDB Lightning does not support every option supported by the
LOAD DATA statement. Some examples:
- The line terminator must only be CR (
\r), LF (
\n) or CRLF (
\r\n), which means
LINES TERMINATED BYis not customizable.
- There cannot be line prefixes (
LINES STARTING BY).
- The header cannot be simply skipped (
IGNORE n LINES). It must be valid column names if present.
Lightning works the best when the input files have uniform size around 256 MB. When the input is a single huge CSV file, Lightning can only use one thread to process it, which slows down import speed a lot.
This can be fixed by splitting the CSV into multiple files first. For the generic CSV format, there is no way to quickly identify when a row starts and ends without reading the whole file. Therefore, Lightning by default does not automatically split a CSV file. However, if you are certain that the CSV input adheres to certain restrictions, you can enable the
strict-format setting to allow Lightning to split the file into multiple 256 MB-sized chunks for parallel processing.
[mydumper] strict-format = true
Currently, a strict CSV file means every field occupies only a single line. In other words, one of the following must be true:
- Delimiter is empty, or
- Every field does not contain CR (
\r) or LF (
If a CSV file is not strict, but
strict-format was wrongly set to
true, a field spanning multiple lines may be cut in half into two chunks, causing parse failure, or even worse, quietly importing corrupted data.
The default setting is already tuned for CSV following RFC 4180.
[mydumper.csv] separator = ',' # It is not recommended to use the default ‘,’. It is recommended to use ‘\|+\|‘ or other uncommon character combinations. delimiter = '"' header = true not-null = false null = '\N' backslash-escape = true trim-last-separator = false
ID,Region,Count 1,"East",32 2,"South",\N 3,"West",10 4,"North",39
[mydumper.csv] separator = "\t" delimiter = '' header = true not-null = false null = 'NULL' backslash-escape = false trim-last-separator = false
ID Region Count 1 East 32 2 South NULL 3 West 10 4 North 39
[mydumper.csv] separator = '|' delimiter = '' header = false not-null = true backslash-escape = false trim-last-separator = true
1|East|32| 2|South|0| 3|West|10| 4|North|39|