In JDBC, what does PreparedStatement do that Statement does not, and why prefer it?

## The three statement types A JDBC `Connection` can produce three kinds of statement object. `createStatement()` returns a `Statement`, whose `executeQuery`/`executeUpdate` methods take the complete SQL text as an argument. `prepareStatement(sql)` returns a `PreparedStatement`, which is bound to one SQL string given at creation time; its execute methods take no SQL. `prepareCall(sql)` returns a `CallableStatement`, which extends `PreparedStatement` and adds registration of OUT parameters for stored-procedure calls. The distinction that matters day to day is the first two: with `Statement` the SQL text is assembled by your code every time; with `PreparedStatement` the text is fixed and only the values change. ## Placeholders and typed setters In a `PreparedStatement` every place a value would appear is written as a `?`. After creating the statement you bind each placeholder by its **1-based** position: `ps.setString(1, email)`, `ps.setLong(2, tenantId)`, `ps.setNull(3, Types.VARCHAR)`. Indexes count `?` characters left to right through the SQL text; they have nothing to do with result columns and they do not start at zero. The setters are typed, which is more valuable than it first looks. `setTimestamp` hands the driver a `java.sql.Timestamp` and lets the driver render it in whatever form the wire protocol wants; you never write a date format string and never discover at 2 a.m. that one database wanted a different literal syntax. `setBigDecimal` avoids the precision loss of formatting a decimal into text. `setNull` expresses a genuine SQL NULL, which string building cannot do without special-casing. ## What the fixed text buys you Because the SQL grammar is complete before any value is supplied, the database parses a statement whose shape cannot be changed by the data. A bound parameter is transported as a value in its own slot; the parser never sees it as part of the statement. That is why parameter binding — not filtering or escaping the input — is the standard defence against SQL injection, and why reviewers scan JDBC code for string concatenation inside `executeQuery(...)` as a first pass. The limit of the mechanism is worth stating precisely: **a `?` can stand only for a value**. It cannot stand for a table name, a column name, a sort direction, an operator, or any other piece of SQL grammar, because those participate in parsing. Queries where callers choose a sort column therefore need the identifier chosen from a fixed set inside your code and interpolated into the text, with only the values still bound. ## Reuse and plan caching The second benefit is performance under repetition. A loop that inserts a thousand rows with `Statement` sends a thousand distinct SQL texts, each of which the database must parse and plan. The same loop with one `PreparedStatement` sends one text and a thousand parameter sets, so the parsed statement can be reused. Many drivers go further and hold a server-side prepared statement, sometimes only after the same statement has been executed a few times — PostgreSQL's driver, for example, exposes this as its `prepareThreshold` setting. Whether a real server-side prepare happens is a driver and configuration question; "prepared" in the name is a JDBC-level contract, not a promise about the wire. This reuse is also the precondition for batching: `addBatch()`/`executeBatch()` on a `PreparedStatement` accumulates parameter sets against one statement. ## Generated keys and other conveniences `prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)` followed by `getGeneratedKeys()` after `executeUpdate()` returns a `ResultSet` of the keys the database assigned — the standard way to recover an auto-increment id. `Statement` supports the same flag on its execute overloads, but with a `PreparedStatement` you get it alongside safe binding. ## Practical rules Use `PreparedStatement` by default, including for queries with no parameters at all: it costs nothing, keeps the code uniform, and means a later change that adds a parameter cannot accidentally be written as concatenation. Reserve `Statement` for one-off DDL or administrative SQL that contains no external input. Close statements — ideally with try-with-resources — because each one can hold a server-side cursor. And never build an `IN (...)` list by concatenating values: generate the right number of `?` placeholders and bind each one, or use `setArray` where the driver supports it.