Conversor de CSV para SQL
Carregue um arquivo CSV ou cole dados para converter em instruções SQL INSERT
Arraste um arquivo CSV aqui ou clique para selecionar
O que é CSV para SQL?
CSV para SQL é uma ferramenta online de conversão de formatos de dados que converte dados no formato CSV (valores separados por vírgulas) em instruções SQL INSERT para facilitar a importação em bancos de dados.
CSV é um formato de dados tabulares comum, amplamente utilizado em planilhas e exportação de dados. SQL é a linguagem de consulta padrão para bancos de dados relacionais, e as instruções INSERT são usadas para inserir dados em tabelas de banco de dados.
Com esta ferramenta, você pode converter rapidamente dados CSV em instruções SQL executáveis, com suporte a nomes de tabela personalizados, nomes de campos e estilos de aspas para facilitar operações de migração e importação de dados.
Como usar
Como usar
- Cole ou insira dados CSV na caixa de entrada ou faça upload de um arquivo CSV
- Defina o nome da tabela (o padrão é table_name)
- Selecione o delimitador adequado (o padrão é vírgula)
- Escolha se a primeira linha deve ser usada como nomes de campo
- As instruções SQL INSERT serão geradas à direita
Segurança de importação
- Revise as instruções INSERT geradas quanto a nome da tabela, ordem das colunas, escaping, valores NULL e formatos numéricos antes da execução.
- Execute um pequeno lote primeiro e envolva as importações reais em uma transação, quando o banco de dados permitir.
Casos de uso
Princípio técnico
A entrada CSV é analisada com uma máquina de estados compatível com RFC 4180 (tratando campos entre aspas, aspas duplas escapadas e terminadores de linha CRLF/LF), e então emitida como instruções SQL INSERT ANSI. As duas gramáticas não se sobrepõem: CSV usa duplicação de aspas duplas para escapes ("O""Brien"), enquanto SQL usa duplicação de aspas simples dentro de literais de string ('O''Brien') conforme ISO/IEC 9075. O conversor reescreve cada apóstrofo interno para um par duplicado antes de envolver o valor em aspas simples, que é o único mecanismo de escape garantido entre MySQL, PostgreSQL, SQLite, SQL Server e Oracle. A citação de identificadores é específica do dialeto: MySQL usa crases `users`, PostgreSQL e SQL Server usam aspas duplas "users" (sensível a maiúsculas quando citado), e SQLite aceita ambos — escolha o estilo que corresponda ao engine de destino para evitar erros de "coluna desconhecida" causados por conversão de maiúsculas. A inferência de tipos é intencionalmente mínima porque CSV não possui metadados de tipo. O rascunho opcional de CREATE TABLE emite VARCHAR(255) para cada coluna — seguro, mas subótimo — e cabe ao usuário substituir por INT, BIGINT, DECIMAL(p,s), DATE, TIMESTAMP ou TEXT antes de executar em produção. Células vazias são emitidas como NULL (o marcador de ausência da lógica de três valores do SQL) em vez de string vazia '', porque a maioria das exportações de planilhas usa um campo em branco para representar dados ausentes; se a distinção de string vazia for importante, mude para um carregador tipado em vez disso. Palavras reservadas como user, order e group NÃO são citadas automaticamente, então uma coluna literalmente chamada order falhará na análise no MySQL a menos que o usuário a envolva em crases manualmente. Para grandes importações, instruções INSERT de linha única são corretas mas lentas: o max_allowed_packet padrão do MySQL é 64 MB e um INSERT INTO t VALUES (...), (...), (...) com múltiplas linhas em lotes de ~1000 linhas por instrução é tipicamente 5-10x mais rápido que uma instrução por linha, devido à sobrecarga de ida e volta de rede e análise. Envolver o lote em BEGIN; ... COMMIT; permite que o banco de dados faça staging dos inserts e os confirme atomicamente, o que é essencial quando um insert parcial deixaria uma relação de chave estrangeira inconsistente. Observe que esta ferramenta não infere chaves estrangeiras, índices, restrições de chave primária ou AUTO_INCREMENT — ela apenas converte dados de linhas, então o schema de destino já deve existir ou o rascunho de CREATE TABLE deve ser editado antes da execução. Para cargas em massa de milhões de linhas, prefira sintaxes nativas do banco de dados: PostgreSQL COPY FROM, MySQL LOAD DATA INFILE ou SQL Server bcp.
- Escape de string literal SQL conforme ISO/IEC 9075: aspas simples são duplicadas ('O''Brien'), não escapadas com barra invertida.
- Citação de identificadores difere: ` para MySQL, " para PostgreSQL/SQL Server, ambos aceitos no SQLite.
- Célula CSV vazia -> SQL NULL (lógica de três valores), não '' — a distinção de string vazia é perdida.
- Palavras reservadas (order, user, group) não são citadas automaticamente; escape manual é necessário.
- INSERTs de múltiplas linhas em lotes de ~1000 linhas atingem ~5-10x de throughput vs. instruções de linha única (MySQL max_allowed_packet 64 MB padrão).
- Envolver com BEGIN; ... COMMIT; para inserts de seed atômicos; falhas parciais fazem rollback de forma limpa.
- Cargas em massa acima de 1M de linhas: prefira PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp em vez de INSERTs gerados.
Exemplos
CSV básico -> instruções INSERT (MySQL com backtick)
CSV:
id,name,email
1,Alice,alice@example.com
2,Bob,bob@example.com
SQL:
INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Bob', 'bob@example.com');Com CREATE TABLE (estilo aspas duplas do PostgreSQL)
CSV:
product_id,price,in_stock
101,29.99,true
102,15.50,false
SQL:
CREATE TABLE "products" (
"product_id" VARCHAR(255),
"price" VARCHAR(255),
"in_stock" VARCHAR(255)
);
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('101', '29.99', 'true');
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('102', '15.50', 'false');
-- Dica: troque VARCHAR(255) por INT / DECIMAL(10,2) / BOOLEAN antes de rodar em produção.Escapando aspas simples dentro dos valores
CSV:
id,note
1,O'Brien signed off
2,It's already done
SQL:
INSERT INTO `notes` (`id`, `note`) VALUES (1, 'O''Brien signed off');
INSERT INTO `notes` (`id`, `note`) VALUES (2, 'It''s already done');
Note: aspas simples são duplicadas (''), o escape padrão do SQL.Inferência de tipos - INT vs DECIMAL vs TEXT
CSV:
user_id,score,bio
1,100,Hello
2,87.5,Long bio text...
Tipos detectados (heurística):
user_id -> INT
score -> DECIMAL(10,2)
bio -> VARCHAR(255) (considere TEXT para conteúdo mais longo)
SQL preview:
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (1, 100, 'Hello');
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (2, 87.5, 'Long bio text...');Perguntas frequentes
Que tipo de SQL a ferramenta gera?
Ela produz comandos CREATE TABLE seguidos de INSERT INTO. O dialeto é SQL portátil por padrão — funciona em MySQL, PostgreSQL, SQLite e MSSQL com pequenos ajustes de tipos. Algumas páginas permitem escolher o dialeto de destino para os tipos de dado (VARCHAR vs TEXT, INT vs INTEGER, etc.).
Como os nomes das colunas são derivados?
Da primeira linha do CSV quando 'a primeira linha é cabeçalho' está ativado. A página sanitiza os nomes substituindo espaços por underline e colocando palavras reservadas entre aspas. Com cabeçalhos desativados, as colunas viram col_1, col_2, etc.
Como o tipo de dado de cada coluna é inferido?
A página analisa amostras dos valores e escolhe o tipo mais estreito que cabe: INTEGER se toda célula for um número inteiro, DECIMAL se algumas forem fracionárias, VARCHAR(N) dimensionado para a célula mais longa, BOOLEAN para true/false, DATE/DATETIME para strings em formato ISO. Você pode sobrescrever o tipo inferido antes de gerar o SQL.
E aspas e caracteres especiais nos dados?
Aspas simples dentro de strings são escapadas duplicando-as (O'Brien → 'O''Brien'). Barras invertidas e caracteres Unicode passam literalmente — isso corresponde ao comportamento do PostgreSQL com standard_conforming_strings = on. Verifique o resultado no modo NO_BACKSLASH_ESCAPES do MySQL se for esse seu destino.
Por que NULL é diferente de string vazia?
Uma célula vazia no CSV (ex.: 'a,,c') vira NULL no SQL; uma string vazia entre aspas ('a,"",c') vira ''. A página segue essa convenção. Desative 'tratar vazio como NULL' se precisar preservar strings vazias nos dois casos.
Meus dados são enviados para algum servidor?
Não. O CSV é interpretado e o SQL é gerado no seu navegador. Entradas e saídas nunca saem da página. Use o resultado como um script SQL que você mesmo importa no seu servidor de banco de dados.
Devo usar o SQL gerado em um banco de produção?
Revise antes. O CREATE TABLE pode não bater com o seu schema existente; os INSERTs não incluem constraints, chaves estrangeiras ou índices. Use como um ponto de partida que você edita, principalmente para chaves primárias, restrições NOT NULL e tipos de dado adequados.