--- term: 'Consultas de Banco de Dados' seoTitle: 'O que é uma Consulta de Banco de Dados? Linguagens de Consulta' headline: 'O que é uma consulta de banco de dados?' slug: consultas-de-banco-de-dados category: database shortDefinition: 'Uma consulta de banco de dados é um pedido estruturado por dados — filtrar, ordenar, projetar, paginar — numa linguagem que o motor planeja e executa.' relatedTerms: - database-index - n-plus-one-query-problem - relational-queries-document-databases - graphql-vs-rest contrastsWith: - auto-generated-database-apis faq: - question: 'O que é uma consulta de banco de dados, em termos simples?' answer: 'Um pedido estruturado para o banco recuperar ou alterar dados — "me dê os artigos publicados com mais de mil visualizações, mais recentes primeiro, vinte por vez". Ela é escrita numa linguagem de consulta ou montada por um SDK, segue uma sintaxe estrita para o motor conseguir interpretá-la, e retorna exatamente a fatia de dados que descreve.' - question: 'SQL é declarativo ou imperativo?' answer: 'Declarativo — você declara quais dados quer, e o otimizador do motor decide como buscá-los: quais índices usar, qual ordem de join, qual algoritmo. Essa divisão de trabalho é a ideia central da consulta moderna, e vale além do SQL: APIs de consulta de documentos e GraphQL também são declarativas. Código imperativo itera sobre registros; queries declarativas descrevem resultados.' - question: 'Como uma consulta é executada de verdade?' answer: 'Um pipeline de quatro estágios: o motor interpreta o texto numa árvore sintática, valida contra o schema, planeja e otimiza — escolhendo índices, ordens de join e algoritmos por custo estimado — e então executa o plano escolhido e devolve os resultados. O plano é inspecionável: EXPLAIN mostra exatamente o que o otimizador decidiu, e é onde toda depuração de performance começa.' - question: 'Qual é a anatomia de uma consulta?' answer: 'Cinco verbos cobrem quase tudo: filtrar (quais registros — WHERE), ordenar (em que ordem — ORDER BY), projetar (quais campos — a lista do SELECT), paginar (quantos, a partir de onde — LIMIT/OFFSET ou um cursor) e agregar (resumos computados — GROUP BY). Toda linguagem de consulta e todo SDK expressam esses mesmos cinco; só a sintaxe muda.' - question: 'Como os índices tornam as consultas rápidas?' answer: 'Eles trocam varredura por busca direta: em vez de ler todos os registros atrás dos que casam (linear no tamanho da tabela), o motor percorre uma estrutura ordenada direto até eles (logarítmico). A diferença é invisível com mil linhas e decisiva com dez milhões. EXPLAIN diz qual dos dois a sua query está fazendo — um sequential scan numa tabela grande é a bandeira vermelha clássica.' - question: 'O que é SQL injection e como queries parametrizadas evitam?' answer: 'Injection é o input do atacante mudando a estrutura de uma query — os truques clássicos de aspas e comentário transformando uma checagem de login numa tautologia. Queries parametrizadas fecham o buraco separando código de dados: o texto da query tem placeholders, os valores são vinculados à parte, e o input do usuário só é tratado como valor — nunca interpretado como sintaxe. SDKs e query builders parametrizam por construção.' - question: 'Qual a diferença entre paginação por offset e por cursor?' answer: 'Paginação por offset (pule N, pegue 20) é simples e salta para qualquer página, mas o motor precisa contar e descartar as linhas puladas — a página 500 custa mais que a página 1 — e escritas concorrentes deslocam resultados entre páginas. Paginação por cursor ("depois desta chave, pegue 20") continua rápida e estável em qualquer profundidade, ao custo de não pular para páginas aleatórias. Feeds pedem cursores; tabelas administrativas pequenas vivem bem de offset.' - question: 'SDKs e query builders substituem saber consultas?' answer: 'Eles substituem escrever a sintaxe, não entender a semântica. Uma cadeia de builder compila para a mesma anatomia filtrar-ordenar-projetar-paginar e acerta os mesmos índices — ou erra. A falha clássica é o padrão N+1: uma query por item dentro de um loop, invisível no código, brutal em produção. A anatomia e o modelo de custo valem em qualquer superfície.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Query language (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Query_language' - name: 'PostgreSQL — Using EXPLAIN' url: 'https://www.postgresql.org/docs/current/using-explain.html' - name: 'GraphQL specification and docs' url: 'https://graphql.org/learn/' - name: 'SDK query documentation' url: 'https://docs.parseplatform.org/js/guide/#queries' cta: title: 'Consultas sem a linguagem de consulta' text: 'No Back4app, o query builder de cada SDK compila para queries indexadas e parametrizadas sobre os seus dados — os mesmos cinco verbos, zero superfície de injection, mais GraphQL quando os clientes querem pedir exatamente o que precisam.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: database-queries --- **Uma consulta de banco de dados é um pedido estruturado por dados — filtrar, ordenar, projetar, paginar — numa linguagem que o motor planeja e executa.** A ideia profunda debaixo de toda linguagem de consulta é a *declaratividade*: você descreve o resultado, e o motor escolhe o caminho. Domine os cinco verbos e o modelo de custo uma vez, e toda sintaxe — SQL, APIs de documentos, GraphQL, builders de SDK — vira sotaque, não idioma novo. ## Principais pontos | Pergunta | Resposta | | --- | --- | | O que é | Um pedido preciso: quais registros, em que ordem, quais campos, quantos | | O paradigma | Declarativo — você diz *o quê*; o otimizador decide *como* | | O pipeline | Interpretar → validar → planejar/otimizar → executar | | O modelo de custo | Busca por índice vs. varredura completa — EXPLAIN diz qual você levou | | A regra de segurança | Parametrize sempre; nunca concatene input em queries | ## A mesma consulta em quatro linguagens de consulta O mesmo pedido — *artigos publicados, mais de 1.000 visualizações, mais recentes primeiro* — através das famílias de linguagem: ```sql -- SQL: o declarativo original SELECT title, views FROM articles WHERE status = 'published' AND views > 1000 ORDER BY published_at DESC LIMIT 20; ``` ```javascript // API de consulta de documentos db.articles.find( { status: 'published', views: { $gt: 1000 } }, // filtro { title: 1, views: 1 } // projeção ).sort({ publishedAt: -1 }).limit(20) // GraphQL: o cliente declara o formato que quer de volta query { articles(where: { status: "published", views_gt: 1000 }, orderBy: publishedAt_DESC, first: 20) { title views } } ``` E o builder do SDK — a superfície que a maior parte do código de aplicação usa de fato, compilando para a mesma anatomia: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Filter, sort, project, paginate — the full anatomy in one query const query = new Parse.Query('Article'); query.equalTo('status', 'published'); // filter query.greaterThan('views', 1000); // filter (range) query.descending('publishedAt'); // sort query.select('title', 'views'); // project: only these fields query.limit(20).skip(40); // paginate: page 3 const articles = await query.find(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Filter, sort, project, paginate — the full anatomy in one query final query = QueryBuilder(ParseObject('Article')) ..whereEqualTo('status', 'published') // filter ..whereGreaterThan('views', 1000) // filter (range) ..orderByDescending('publishedAt') // sort ..keysToReturn(['title', 'views']) // project: only these fields ..setLimit(20)..setAmountToSkip(40); // paginate: page 3 final response = await query.query(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Filter, sort, project, paginate — the full anatomy in one query let query = Article.query("status" == "published", "views" > 1000) .order([.descending("publishedAt")]) // sort .select("title", "views") // project: only these fields .limit(20).skip(40) // paginate: page 3 query.find { result in if case .success(let articles) = result { render(articles) } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Filter, sort, project, paginate — the full anatomy in one query val query = ParseQuery.getQuery("Article") query.whereEqualTo("status", "published") // filter query.whereGreaterThan("views", 1000) // filter (range) query.orderByDescending("publishedAt") // sort query.selectKeys(listOf("title", "views")) // project: only these fields query.limit = 20; query.skip = 40 // paginate: page 3 query.findInBackground { articles, e -> if (e == null) render(articles) } ``` ## Como um banco de dados executa uma consulta ```mermaid flowchart LR accTitle: Pipeline de execução de consultas accDescr: O motor interpreta o texto da query numa árvore sintática, valida contra o schema, planeja e otimiza escolhendo índices e estratégias de join com base em custo, e então executa o plano e retorna os resultados. Q["Texto da query"] --> P["Interpretar
árvore sintática"] P --> V["Validar
contra o schema"] V --> O["Planejar e otimizar
índices · ordem de join · custo"] O --> E["Executar
devolver resultados"] ``` O otimizador é o motivo de a consulta declarativa funcionar: ele pesa os [índices](/glossary/pt/indice-de-banco-de-dados/) disponíveis, estima contagens de linhas e escolhe o plano mais barato — e o [EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html) mostra a decisão dele. O método de performance em uma linha: rode EXPLAIN, procure a varredura completa, crie o índice que o filtro está implorando, olhe de novo. ## Declarativo vs. imperativo | Dimensão | Query declarativa | Código imperativo | | --- | --- | --- | | Você escreve | O resultado que quer | Os passos para computá-lo | | Quem otimiza | O motor, a cada execução | Você, uma vez, na hora de escrever | | Adapta ao volume de dados | Sim — planos mudam com as estatísticas | Não — o loop é o loop | | Onde vive | SQL, APIs de documentos, GraphQL, builders | Loops da aplicação sobre registros | | Cheiro de falha | Plano errado (resolve com índices/hints) | Loops N+1, estouros de memória | A anatomia que atravessa todas elas: **filtrar** (`WHERE`), **ordenar** (`ORDER BY`), **projetar** (a lista do SELECT — peça só o que precisa), **paginar** (`LIMIT` mais offset ou cursor), **agregar** (`GROUP BY` e companhia). Cinco verbos, toda superfície. ## As duas regras que evitam a maioria dos incidentes com queries **Parametrize, sempre.** Injection é input de atacante virando *estrutura* de query — resolvido por completo com placeholders que vinculam o input como valor: ```javascript // Vulnerável: input concatenado na estrutura da query db.query(`SELECT * FROM users WHERE name = '${input}'`); // nunca isso // Seguro: parametrizado — o input é dado, não sintaxe db.query('SELECT * FROM users WHERE name = $1', [input]); ``` Builders de SDK e variáveis do GraphQL fazem isso por construção — uma das vitórias silenciosas de segurança das superfícies de consulta de mais alto nível. **Pagine pelo formato do acesso.** Paginação por offset (`LIMIT 20 OFFSET 400`) salta para qualquer página, mas paga linearmente pela profundidade e balança sob escritas concorrentes; paginação por cursor (`WHERE published_at < $last`) é estável e de custo constante em qualquer profundidade, mas só anda para a frente. Feeds e scroll infinito pedem cursores; tabelas administrativas com número de página são território honesto do offset. ## Casos de uso comuns - **Leituras da aplicação.** Listas, telas de detalhe, busca — o quarteto filtrar-ordenar-projetar-paginar no habitat natural. - **Agregação e relatórios.** Contagens, somas, resumos agrupados — empurrados para o motor, onde os dados estão, em vez de computados no código da aplicação. - **Superfícies de API.** [APIs geradas automaticamente](/glossary/pt/apis-geradas-automaticamente/) traduzem parâmetros de URL ou seleções GraphQL nessas mesmas queries — a anatomia vaza por toda abstração. - **Filtros em tempo real.** Assinaturas ao vivo são queries de plantão — os mesmos predicados, avaliados continuamente. - **Depurar produção.** EXPLAIN mais o log de queries lentas é o loop de diagnóstico para a classe de incidente "ficou lento". ## Linguagem crua, builder ou SDK? Matriz de decisão | Escolha… | Quando… | Cuidado com… | | --- | --- | --- | | Linguagem de consulta crua | Agregações complexas, relatórios, migrações | Injection se concatenar; portabilidade | | Query builder / SDK | CRUD e listas da aplicação — a maior parte do código | Loops N+1; builders escondem o plano | | GraphQL | Clientes precisam escolher campos e aninhar relações | Custo de query sem limites | | Lógica no servidor | Operações multi-passo perto dos dados | Lógica escondida da base de código | A regra honesta da [discussão sobre camada de abstração](/glossary/database-abstraction-layer/) vale ao pé da letra: builders para os 90% rotineiros, queries cruas onde o controle paga o próprio custo — e o conhecimento da anatomia transfere de qualquer jeito. ## Limitações e trade-offs - **Declarativo não é de graça.** O otimizador é tão bom quanto suas estatísticas e índices; a query certa sobre índices errados continua lenta. - **Queries escondem o próprio custo.** Uma linha de builder pode ser uma varredura sobre milhões de linhas; EXPLAIN é o único espelho honesto. - **A armadilha N+1 mora acima da query.** Queries individualmente perfeitas, disparadas num loop, são coletivamente patológicas — batching e includes existem para isso. - **Paginação profunda degrada.** Profundidade de offset é custo linear; desenhe feeds em volta de cursores desde o primeiro dia. - **A proliferação de linguagens é real.** SQL, APIs de documentos, GraphQL, DSLs de busca — os times pagam um imposto por superfície; a anatomia compartilhada é o antídoto. ## Consultas no Back4app O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Sua história de consultas é o caminho do builder de SDK levado a sério: o [query builder](https://docs.parseplatform.org/js/guide/#queries) de cada SDK — as abas de código acima — compila filtro, ordenação, projeção e paginação em queries parametrizadas sem superfície de injection, `include()` resolve relações sem loops N+1, os mesmos predicados alimentam [live queries](https://www.back4app.com) para atualizações em tempo real, e o GraphQL serve os clientes que querem declarar os próprios formatos. Os cinco verbos, toda superfície, um backend.