The WHERE clause specifies which rows to query. The WHERE clause is composed of conditions
on the columns that are part of the primary key or are indexed. Use of the primary key in
the WHERE clause tells Cassandra to race to the specific node that has the data. Using the
equals conditional operators (= or IN) is unrestricted. The term on the left of the operator
must be the name of the column, and the term on the right must be the column value to filter
on. There are restrictions on other conditional operators.

Cassandra supports these conditional operators: =, >, >=, <, or <=, but not all
in certain situations.

A filter based on a non-equals condition on a partition key is supported only if the partitioner is an ordered one.

WHERE clauses can include a greater-than and less-than comparisons, but for a given
partition key, the conditions on the clustering
column are restricted to the filters that allow Cassandra to select a contiguous
ordering of rows.

This query constructs a filter that selects data about stewards whose reign started by 2450
and ended before 2500. If king were not a component of the primary key, you would need to
create an index on king to use this query:

To allow Cassandra to select a contiguous ordering of rows, you need to
include the king component of the primary key in the filter using an equality condition. The
ALLOW FILTERING clause is also required.
¶

Use IN, an equals condition operator, in the WHERE clause to specify multiple possible
values for a column. For example, select two columns, Name and Occupation, from three rows
having employee ids (primary key) 199, 200, or 207:

SELECT Name, Occupation FROM People WHERE empID IN (199, 200, 207);

Format values for the IN conditional test as a comma-separated list. The list can consist
of a range of column values.

The recommendations about when not to use an
index apply to using IN in the WHERE clause. Under most conditions, using IN in the
WHERE clause is not recommended. Using IN can degrade performance because usually many nodes
must be queried. For example, in a single, local data center cluster with 30 nodes, a
replication factor of 3, and a consistency level of LOCAL_QUORUM, a single key query goes
out to two nodes, but if the query uses the IN condition, the number of nodes being queried
are most likely even higher, up to 20 nodes depending on where the keys fall in the token
range.

When you attempt a potentially expensive query, such as searching a range of rows, this
prompt appears:

Bad Request: Cannot execute this query as it might involve data
filtering and thus may have unpredictable performance. If you want
to execute this query despite the performance unpredictability,
use ALLOW FILTERING.

To run the query, use the ALLOW FILTERING clause. Imposing a limit using the LIMIT n
clause is recommended to reduce memory used. For example:

Critically, LIMIT doesn't protect you from the worst liabilities. For instance, what if
there are no entries with no king? Then you have to scan the entire list no matter what
LIMIT is.

ALLOW FILTERING will probably become less strict as we collect more statistics on our data.
For example, if we knew that 90% of entries have no king we would know that finding 10 such
entries should be relatively inexpensive.

The TOKEN function can be used with a condition operator
on the partition key column to query. The query
selects rows based on the token of their partition key rather than on their value. The token
of a key depends on the partitioner in use. The RandomPartitioner and Murmur3Partitioner do
not yield a meaningful order.

For example, assuming you have this table defined, the following query shows how to use the
TOKEN function:

ORDER BY clauses can select a single column only. That column has to be the second column
in a compound PRIMARY KEY. This also applies to tables with more than two column components
in the primary key. Ordering can be done in ascending or descending order, default
ascending, and specified with the ASC or DESC keywords.

For example, set up the playlists table, which uses
a compound primary key, insert the example
data, and use this query to get information about a particular playlist, ordered by
song_order. As of Cassandra 1.2, you do not need to include the ORDER BY column in the
select expression.