A database query is a request for information or an operation against data managed by a database system. In relational databases, queries are commonly written in SQL and can retrieve, filter, combine, aggregate, insert, modify or delete data depending on the statement type and context. A SELECT statement is generally used to retrieve data, while INSERT, UPDATE and DELETE modify stored information.
More broadly, a query can be any structured request interpreted by a database engine, including queries in non-relational systems that use APIs, document syntax or specialised query languages. The fundamental purpose is to express what information or operation is required while allowing the database system to determine how to execute it.
A simple SQL query might request all customers whose status is active, while a more complex query might join several tables, filter records by date, aggregate transactions and sort the resulting groups. SQL separates the logical request from many physical execution details. The database optimiser can decide whether to use an index, scan a table, join tables using a hash strategy, nested loops or another method, and perform operations in an order intended to minimise cost. This separation is one of the important strengths of declarative database languages. The user describes the desired result, while the database engine determines an execution plan subject to its optimiser, statistics, indexes and configuration.
Queries can involve filtering through predicates, projection of selected columns, joins between related tables, grouping, aggregation and ordering. A WHERE clause can restrict rows, SELECT determines expressions or columns returned, JOIN combines information based on relationships, GROUP BY forms groups and aggregate functions such as COUNT, SUM, AVG, MIN and MAX calculate values. HAVING can filter groups after aggregation, while ORDER BY requests a defined result ordering. SQL also supports subqueries, common table expressions, window functions and set operations such as UNION. These mechanisms allow a relatively compact query to express sophisticated data transformations and retrieval requirements.
Query execution normally involves several stages. The database parses and validates the query, resolves object names and data types, transforms the logical request into an internal representation, chooses an execution plan and then executes that plan. The optimiser considers available indexes, statistics, estimated row counts, join relationships and operation costs. The selected plan can involve scans, seeks, joins, sorts, aggregations and other operators. The actual terminology and optimisation algorithms vary between database systems. Execution plans can be inspected using database-specific diagnostic tools and are important when investigating slow queries.
Query performance depends on much more than the query text. Table size, indexes, data distribution, database statistics, memory, storage speed, network latency, concurrency and transaction contention can all influence execution time. A query that performs well on a thousand rows may become inefficient on hundreds of millions of rows. Functions applied to indexed columns, leading wildcard searches, unnecessary joins and retrieving far more data than needed can sometimes reduce efficiency, although the actual impact depends on the database engine and execution plan. Performance optimisation should therefore use measurement and execution-plan analysis rather than relying solely on general rules.
Queries that modify data require particular attention to transactions and concurrency. An UPDATE statement can alter many rows, and an incorrectly specified WHERE condition can modify substantially more data than intended. Transactions allow multiple related statements to be treated as a unit according to the database's transaction model. Isolation levels determine how concurrent transactions interact and what phenomena, such as dirty reads or non-repeatable reads, can occur. Parameterised queries are also important for security because constructing SQL by directly concatenating untrusted input can create SQL injection vulnerabilities. Database access should therefore combine correct query semantics with transaction and security controls.
Queries are not limited to relational SQL. Document databases may provide JSON-oriented query APIs, graph databases may use graph-specific query languages, and search engines may expose structured query DSLs. Even within SQL systems, implementations differ in supported syntax, functions and optimisation features. An API request to retrieve data from a web service is also sometimes informally called a query, although technically it may be a request to an application rather than directly to a database. The precise meaning should therefore be determined from context.
A database query is fundamentally a formal expression of a desired data operation or result. Effective query design requires understanding the schema, relationships, constraints, indexes, data types and semantics of the database. A query can be simple enough to retrieve one record by primary key or complex enough to transform and aggregate large datasets across many tables. Good queries return the required information accurately and efficiently while respecting security, transaction and consistency requirements. Query languages provide the interface through which applications and users turn a database's stored structures into useful information and controlled data modifications.
