Import CSV to Database: MySQL PostgreSQL Guide

A Importação de Banco de Dados às 3 da Manhã Que Mudou Tudo

Eu ainda me lembro do pânico na voz do meu desenvolvedor júnior quando ele me ligou às 3 da manhã. "A importação de CSV do cliente está rodando há seis horas e está apenas 40% completa. O negócio deles abre em três horas e eles precisam destes dados do cliente ao vivo." Isso foi há sete anos, no início da minha carreira como arquiteto de banco de dados em uma plataforma de e-commerce de médio porte. Hoje, depois de otimizar centenas de operações de importação de CSV em bancos de dados MySQL e PostgreSQL para empresas que processam de 50.000 a 50 milhões de linhas, posso lhe dizer que a maioria dos desenvolvedores está fazendo isso errado—e isso lhes custa horas de tempo de processamento e milhares em custos de servidor.

A verdade é que a importação de arquivos CSV em bancos de dados é uma daquelas tarefas que parece enganosamente simples até que você esteja encarando um arquivo de 2GB que precisa estar em produção pela manhã. Eu já vi equipes recorrerem à escrita de scripts personalizados em Python que levam 8 horas para importar o que poderia ser feito em 12 minutos com a abordagem certa. Eu já vi servidores travarem sob a carga de memória de importações mal configuradas. E eu ajudei empresas a reduzir seus custos mensais de processamento de dados em 73% simplesmente mudando de instruções INSERT para métodos de carregamento em massa.

Neste guia, vou compartilhar tudo o que aprendi ao importar mais de 2 bilhões de linhas de dados CSV em bancos de dados MySQL e PostgreSQL. Vamos cobrir os métodos que realmente funcionam em ambientes de produção, os marcos de desempenho que você precisa saber e as armadilhas que o salvarão dessas ligações de pânico às 3 da manhã. Se você está importando uma lista de clientes de 5MB ou um log de transações de 50GB, você sairá sabendo exatamente qual abordagem usar e por quê.

Entendendo a Verdadeira Diferença de Desempenho Entre Métodos de Importação

Antes de mergulharmos no como fazer, você precisa entender por que seu método de importação é tão importante. No ano passado, realizei um extenso teste de benchmark para um cliente que estava importando dados de vendas diárias—aproximadamente 2.3 milhões de linhas em um arquivo CSV que tinha 847MB de tamanho. Nós testamos quatro métodos de importação diferentes em hardware idêntico: uma instância padrão AWS RDS db.m5.xlarge com 4 vCPUs e 16GB de RAM.

"A diferença entre instruções INSERT e carregamento em massa não é apenas sobre velocidade—é a diferença entre uma janela de importação de 6 horas e uma de 12 minutos. Em produção, essa diferença é a diferença entre sucesso e fracasso."

Os resultados foram surpreendentes. Usar instruções INSERT individuais através de um script Python levou 4 horas e 23 minutos. A mesma importação usando instruções preparadas com agrupamento (1000 linhas por grupo) completou em 47 minutos. O LOAD DATA INFILE do MySQL terminou em 8 minutos e 12 segundos. Mas aqui está o que me chocou ainda mais: usando o comando COPY do PostgreSQL com a configuração adequada, a importação inteira foi concluída em apenas 3 minutos e 41 segundos. Isso representa uma melhoria de desempenho de 71x em relação à abordagem ingênua.

A diferença não é apenas sobre velocidade—é sobre a utilização de recursos. Durante a abordagem de instruções INSERT, vimos a utilização da CPU disparar para 89% e permanecer lá durante toda a duração. O I/O de rede estava constantemente no limite porque cada linha exigia uma viagem de ida e volta ao banco de dados. Os métodos LOAD DATA INFILE e COPY, em contraste, mantiveram a utilização da CPU em torno de 34% e completaram a transferência de rede nos primeiros 90 segundos, gastando o tempo restante em I/O de disco e construção de índices.

Aqui está o que a maioria dos desenvolvedores não percebe: quando você usa instruções INSERT individuais, você não está apenas enviando dados—você está enviando toda a estrutura da instrução SQL para cada linha. Para uma tabela com 10 colunas, você pode estar enviando 200 bytes de sobrecarga SQL para cada 150 bytes de dados reais. Isso resulta em uma relação de sobrecarga de 133%. Os métodos de carregamento em massa eliminam completamente essa sobrecarga, enviando apenas os dados brutos com uma embalagem de protocolo mínima.

A carga de memória conta outra história. A abordagem do script Python manteve todo o CSV na memória antes de processá-lo, consumindo 1.2GB de RAM no servidor de aplicação. Os métodos de carregamento em massa transmitiram os dados diretamente para o banco de dados, usando menos de 50MB de memória da aplicação. Essa diferença se torna crítica quando você está executando múltiplas importações simultaneamente ou lidando com arquivos maiores.

MySQL LOAD DATA INFILE: O Caminho Rápido para Importações MySQL

O LOAD DATA INFILE do MySQL é a ferramenta que eu uso primeiro ao trabalhar com bancos de dados MySQL. Está embutido diretamente no mecanismo do banco de dados e otimizado a nível de código C para máximo throughput. Na minha experiência, ele consistentemente oferece um desempenho 15-25x melhor do que scripts de importação em nível de aplicação, e é surpreendentemente simples de usar uma vez que você entende suas peculiaridades.

A sintaxe básica é a seguinte: LOAD DATA INFILE '/caminho/para/o/arquivo.csv' INTO TABLE sua_tabela FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 ROWS; Mas o diabo está nos detalhes, e esses detalhes podem significar a diferença entre uma importação de 10 minutos e um pesadelo de 3 horas.

Primeiro, entenda a palavra-chave LOCAL. Quando você usa LOAD DATA LOCAL INFILE, o MySQL lê o arquivo da máquina cliente e o transfere pela rede. Sem LOCAL, o MySQL espera que o arquivo esteja no próprio servidor do banco de dados. Eu já vi isso causar problemas para desenvolvedores dezenas de vezes—eles recebem um erro de "arquivo não encontrado" porque estão tentando carregar um arquivo do seu laptop em uma instância RDS remota sem usar LOCAL. A diferença de desempenho também é significativa: LOCAL adiciona tempo de transferência de rede, mas ainda é muito mais rápido do que as instruções INSERT. Nos meus testes, LOCAL acrescentou cerca de 40% ao tempo de importação em comparação com carregamento do lado do servidor, mas isso ainda é 10x mais rápido que a alternativa.

A codificação de caracteres é outra mina terrestre. Por padrão, o MySQL assume que seu CSV está no conjunto de caracteres do servidor, que pode não corresponder ao seu arquivo. Eu sempre especifico explicitamente o conjunto de caracteres: CHARACTER SET utf8mb4. Isso me salvou de inúmeras horas de depuração sobre por que certos caracteres apareciam como pontos de interrogação ou causavam a falha da importação no meio do caminho. UTF-8 com suporte a 4 bytes (utf8mb4) lida com emojis e caracteres especiais que se tornam cada vez mais comuns em conjuntos de dados modernos.

Aqui está um exemplo do mundo real de um projeto onde importamos dados de catálogo de produtos com descrições complexas: LOAD DATA LOCAL INFILE 'products.csv' INTO TABLE products CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\r\n' IGNORE 1 ROWS (product_id, name, description, price, stock_quantity) SET created_at = NOW(), updated_at = NOW(); Note como podemos mapear colunas CSV para colunas da tabela e até definir campos adicionais com valores computados. Essa flexibilidade significa que você não precisa pré-processar seu CSV para que corresponda exatamente à estrutura da tabela.

Uma otimização crítica: desative os índices antes de grandes importações e reconstrua-os depois. Para uma tabela com três índices, medi um aumento de 3.2x na velocidade ao remover índices, importar e depois recriá-los. A sequência de comandos é: ALTER TABLE sua_tabela DISABLE KEYS; depois sua instrução LOAD DATA, em seguida ALTER TABLE sua_tabela ENABLE KEYS; O MySQL reconstrói todos os índices em uma única passada, o que é muito mais eficiente do que atualizá-los para cada linha inserida.

PostgreSQL COPY: O Campeão de Desempenho

Se o LOAD DATA INFILE do MySQL é rápido, o comando COPY do PostgreSQL é uma nave foguete. Em todos os benchmarks que executei, o COPY superou as importações equivalentes do MySQL em 20-40%, e oferece mais flexibilidade para lidar com cenários de dados complexos. Depois de trabalhar extensivamente com ambos os sistemas, passei a preferir o PostgreSQL para cargas pesadas de importação de dados, e o COPY é uma grande razão para isso.

"A maioria dos desenvolvedores trata as importações CSV como uma tarefa única e otimiza para conveniência. Mas quando você está processando m