To execute a query, you create a [Statement] instance and pass it to [Session#execute()][execute] or

[Session#executeAsync][executeAsync]. The driver provides various implementations:

[execute]: http://docs.datastax.com/en/drivers/java/3.0/com/datastax/driver/core/Session.html#execute-com.datastax.driver.core.Statement-

[executeAsync]: http://docs.datastax.com/en/drivers/java/3.0/com/datastax/driver/core/Session.html#executeAsync-com.datastax.driver.core.Statement-

Use [PreparedStatement] for queries that are executed multiple times in your application:

BoundStatement bound = prepared.bind("234827", "Mouse");

session.execute(prepared.bind("987274", "Keyboard"));

When you prepare the statement, Cassandra will parse the query string, cache the result and return a unique identifier

(the `PreparedStatement` object keeps an internal reference to that identifier):

When you bind and execute a prepared statement, the driver will only send the identifier, which allows Cassandra to

skip the parsing phase:

You should prepare only once, and cache the `PreparedStatement` in your application (it is thread-safe). If you call

`prepare` multiple times with the same query string, the driver will log a warning.

If you execute a query only once, a prepared statement is inefficient because it requires two roundtrips. Consider a

[simple statement](../simple/) instead.

To turn the statement into its executable form, you need to *bind* it to create a [BoundStatement]. As shown previously,

there is a shorthand to provide the parameters in the same call:

You must set all parameters. If you fail to do so, the driver will throw an error when executing the statement. If you

want to send a `NULL` value, set it explicitly to `null` (use `setToNull` for Java primitives). Note that this is a new

behavior in 2.1, branch 2.0 of the driver assumed unset values were null.

`BoundStatement` is **not thread-safe**. You can reuse an instance multiple times with different parameters, but only

from a single thread, and only if you use the synchronous API ([Session#execute][execute] is fine,

[Session#executeAsync][executeAsync] is not).

Also, make sure you don't accidentally reuse parameters from previous executions.

Cassandra does not replicate prepared statements across the cluster. It is the

node in the cluster (this avoids hitting all nodes in case

Use [SimpleStatement] for queries that will be executed only once (or a few times) in your application:

SimpleStatement statement = new SimpleStatement(

"SELECT value FROM application_params WHERE name = 'greeting_message'");

session.execute(statement);

When you don't need to customize anything on the `SimpleStatement` object, there is a convenient shortcut:

session.execute("SELECT value FROM application_params WHERE name = 'greeting_message'");

Each time you execute a simple statement, Cassandra will parse the query string again; nothing is cached (neither on the

client nor on the server):

If you execute the same query often (or a similar query with different column values), consider a

[prepared statement](../prepared/) instead.

Instead of sending a raw query string, you can use anonymous bind markers and provide values separately:

String paramName = ...

session.execute(

"SELECT value FROM application_params WHERE name = ?",

paramName);

This syntax has a few advantages:

* if the values already come from some other part of your code, it looks cleaner than doing the concatenation yourself;

* you don't need to translate the values to their string representation. The driver will sent them alongside the query,

in their serialized binary form.

The number of values must match the query string, and their types must match the database schema. Note that the driver

does not parse query strings, so it cannot perform those checks on the client side; if you make a mistake, the query

will be sent anyway, and the error will be caught by Cassandra (`InvalidQueryException` is a server-side error):

session.execute(

"SELECT value FROM application_params WHERE name = ?",

"foo", "bar");

Another consequence of not parsing query strings is that the driver has to make a guess on how to serialize values,

based on their Java type (see the [default type mappings](../../#cql-to-java-type-mapping)). This can be tricky, in

particular for numeric types:

session.execute(

"INSERT INTO bigints (b) VALUES (?)",

1);

The problem here is that the literal `1` has the Java type `int`. So the driver serializes it as a CQL `int` (4 bytes),

but the server expects a CQL `bigint` (8 bytes). The fix is to specify the correct Java type:

session.execute(

"INSERT INTO bigints (b) VALUES (?)",

1L);

In the same vein, strings are always serialized to `varchar`, so you could have a problem if you target an `ascii`

column:

session.execute(

"INSERT INTO ascii_quotes (id, t) VALUES (?, ?)",

1, "Touché sir, touché...");

In that situation, there is no way to hint at the correct type. Your only option is to serialize the value manually:

ProtocolVersion protocolVersion = cluster.getConfiguration().getProtocolOptions().getProtocolVersionEnum();

ByteBuffer bytes = DataType.ascii().serialize("Touché sir, touché...", protocolVersion);

session.execute(

"INSERT INTO ascii_quotes (id, t) VALUES (?, ?)",

1, bytes);