ALTER INDEX applies a to an index.
This schema change statement is registered as a job. You can view long-running jobs with .
Required privileges
Refer to the respective subcommands.Synopsis
Parameters
Additional parameters are documented for the respective subcommands.
Subcommands
CONFIGURE ZONE
ALTER INDEX... CONFIGURE ZONE is used to add, modify, reset, or remove replication zones for an index. To view details about existing replication zones, use . For more information about replication zones, see .
You can use replication zones to control the number and location of replicas for specific sets of data, both when replicas are first added and when they are rebalanced to maintain cluster equilibrium.
For examples, see Replication Controls.
For instructions showing how to troubleshoot replication zones that may be misconfigured, see .
Required privileges
The user must be a member of the or have been granted or privileges. To configure , the user must be a member of theadmin role.
Parameters
For usage, see Synopsis.
PARTITION BY
ALTER INDEX... PARTITION BY is used to partition, re-partition, or un-partition a secondary index. After defining partitions, is used to control the replication and placement of partitions.
Similar to , partitions can improve query performance by limiting the numbers of rows that a query must scan. In the case of , partitioning can limit a query scan to data in a specific region. For examples, see .
The is different from the conventional primary key: The unique identifier in the primary key must be prefixed with all columns you want to partition and subpartition the table on, in the order in which you want to nest your subpartitions.
If the primary key in your existing table does not meet the requirements, you can change the primary key with .
For examples, see Define partitions.
Required privileges
The user must have theCREATE on the table.
Parameters
For usage, see Synopsis.
RENAME TO
ALTER INDEX... RENAME TO changes the name of an index.
It is not possible to rename an index referenced by a view. For more details, see .
Required privileges
The user must have theCREATE on the table.
Parameters
For usage, see Synopsis.
SCATTER
ALTER INDEX... SCATTER runs a specified set of ranges for a table or index through the queue. If many ranges have been created recently, the replication queue may transfer some leases to other replicas to balance load across the cluster.
Note that this statement makes a best-effort attempt to redistribute replicas and leaseholders for the ranges of an index. It does not return an error even if replicas are not moved.
SCATTER has the potential to result in data movement proportional to the size of the table or index being scattered, thus taking additional time and resources to complete.Required privileges
The user must have theINSERT on the table or index.
Parameters
For usage, see Synopsis.
SPLIT AT
ALTER INDEX... SPLIT AT forces a at a specified row in the index.
CockroachDB breaks data into ranges. By default, CockroachDB attempts to keep ranges below . To do this, the system will automatically if it grows larger than this limit. For most use cases, this automatic range splitting is sufficient, and you should never need to worry about when or where the system decides to split ranges.
However, there are reasons why you may want to perform manual splits on the ranges that store tables or indexes:
- When a table only consists of a single range, all writes and reads to the table will be served by that range’s . If a table only holds a small amount of data but is serving a large amount of traffic, load distribution can become unbalanced and a can occur. Splitting the table’s ranges manually can allow the load on the table to be more evenly distributed across multiple nodes. For tables consisting of more than a few ranges, load will naturally be distributed across multiple nodes and this will not be a concern.
- When a table is created, it will only consist of a single range. If you know that a new table will immediately receive significant write traffic, you may want to preemptively split the table based on the expected distribution of writes before applying the load. This can help avoid reduced workload performance that results when automatic splits are unable to keep up with write traffic and a occurs.
Required privileges
The user must have theINSERT on the table or index.
Parameters
For usage, see Synopsis.
UNSPLIT AT
ALTER INDEX... UNSPLIT AT removes a split enforcement on a , at a specified row in the index.
Removing a split enforcement from a table or index (“unsplitting”) allows CockroachDB to merge ranges as needed, to help improve your cluster’s performance. For more information, see .
For examples, see Split and unsplit indexes.
Required privileges
The user must have theINSERT on the table or index.
Parameters
For usage, see Synopsis.
VISIBILITY
ALTER INDEX... VISIBILITY specifies the visibility of an index between a range of 0.0 and 1.0.
-
VISIBILITY 0.0means that an index is not visible to the . This is equivalent toNOT VISIBLE. -
VISIBILITY 1.0means that an index is visible to the optimizer. This is equivalent toVISIBLE. -
Any value between
0.0and1.0means that an index is visible to the specified fraction of queries. This is known as a partially visible index.For the purposes of , partially visible indexes are treated as . If a partially visible index can be used to improve a query plan, the will recommend making it fully visible. For an example, refer to .
[NOT] VISIBLE
ALTER INDEX... VISIBLE and ALTER INDEX... NOT VISIBLE determines whether the index is visible to the .
By default, indexes are visible. If an index is NOT VISIBLE, queries will not read from the index unless it is specifically selected with an or the property is overridden with the . In order to keep NOT VISIBLE indexes up to date, queries will still write to the index as they insert and update data in the table.
This allows you to create an index and check for query plan changes without affecting production queries. For an example, refer to Set an index to be not visible.
Note the following considerations for index visibility:
- Primary indexes must be visible.
- Queries may still read from
NOT VISIBLE, indexes to enforce . - Queries may still read from
NOT VISIBLEindexes to perform foreign key cascades and enforce . - When defining a , you cannot use the
NOT VISIBLEsyntax to make the corresponding index not visible. Instead, useALTER INDEX... NOT VISIBLEafter creating theUNIQUEconstraint.
Aliases
In CockroachDB, the following are aliases forNOT VISIBLE:
INVISIBLE
Examples
Configure replication zones
Setup
The following examples use MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see . To follow along, run with the--geo-partitioned-replicas flag. This command opens an interactive SQL shell to a temporary, 9-node in-memory cluster with the movr database.
Create a replication zone for an index
The on a table will automatically use the replication zone for the table. You can also add distinct replication zones for secondary indexes. To control replication for a specific secondary index, use theALTER INDEX... CONFIGURE ZONE statement to define the relevant values (other values will be inherited from the parent zone).
Edit a replication zone
Remove a replication zone
When you discard a zone configuration, the objects it was applied to will then inherit a configuration from an object “the next level up”; e.g., if the object whose configuration is being discarded is a table, it will use its parent database’s configuration.You cannot
DISCARD any zone configurations on multi-region tables, indexes, or partitions if the created the zone configuration.Troubleshoot replication zones
For instructions showing how to troubleshoot replication zones that may be misconfigured, see .Define partitions
Define a list partition on an index
Suppose we have a table calledstudents_by_list, a secondary index on the table called name_idx, and the primary key of the table is defined as (country, id). We can define partitions on the index by list:
Define a range partition on an index
Suppose we have a table calledstudents_by_range, with a secondary index called name_idx, and the primary key of the table is defined as (expected_graduation_date, id). We can define partitions on the index by range:
Define subpartitions on an index
Suppose we have a table namedstudents, with a secondary index called name_idx, and the primary key is defined as (country, expected_graduation_date, id). We can define partitions and subpartitions on the index:
Repartition an index
Unpartition an index
Rename indexes
Rename an index
Scatter indexes
Before scattering, you can view the current replica and leaseholder distribution for an index:Split and unsplit indexes
Setup
The following examples use MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see . To follow along, run with the--geo-partitioned-replicas flag. This command opens an interactive SQL shell to a temporary, 9-node in-memory cluster with the movr database.
Split an index
Add a new secondary to therides table, on the revenue column:
Set the expiration on a split enforcement
For an example, see .Unsplit an index
Add a new secondary to therides table, on the revenue column, and then split the table ranges by secondary index values as described in Split an index.
To remove the split enforcements, run the following:
split_enforced_until column. The table also contains information about ranges in your CockroachDB cluster, including the split_enforced_until column.
25.00, 50.00, and 75.00, but the split_enforced_until column is now NULL for all ranges in the table. The split is no longer enforced, and CockroachDB can in the table as needed.
Set index visibility
Set an index to be not visible
Start the on a 3-node CockroachDB demo cluster with a larger data set.-
Show the indexes on the
ridestable. In the second-to-last column,visible, you can see that all indexes have the valuet(true). -
Explain a query that filters on revenue. Since there is no index on the
revenuecolumn, the query performs a full scan. -
Create the recommended index.
-
Display the indexes on the
ridestable to verify the newly created indexrides_revenue_idx. -
Explain the query behavior after creating the index. The query now uses the
rides_revenue_idxindex and scans many fewer rows. -
Alter the index to be not visible to the optimizer, specifying the
NOT VISIBLEclause. -
Display the table indexes and verify that the index visibility for
rides_revenue_idxisf(false). -
Explain the query behavior after making the index not visible to the optimizer. With the index not visible, the optimizer reverts to full scan and recommends that you make the index visible.
Set an index as partially visible
Using therides_revenue_idx created in the preceding example:
-
Set the visibility of the index to
0.5. -
Display the table indexes and verify that the index visibility for
rides_revenue_idxis0.5. -
Explain the query behavior after making the index partially visible to the optimizer. For the purposes of index recommendations, a partially visible index is treated as not visible. The optimizer recommends that you make this index fully visible.

