Is it redundant to add a separate, single-column index on the first field of a multicolumn primary key? Does it depend on the relative quantitiy of unique values in that first column compared to the size of the table?
My specific scenario is that I’m building several moderately sized tables (20k – 500k rows) with two- and three-column primary keys. The first column in these tables is an integer which corresponds to a certain business activity (I’ll just call it an “activity” here) and the second column is either a product ID (a UPC actually) or a business location identifier:
-- Activity - upc table: entire table is a two-column primary key
CREATE TABLE activity_upc (
activity_id int NOT NULL,
upc_id dec(18,0) NOT NULL,
CONSTRAINT PRIMARY KEY PK_activity_upc CLUSTERED ( activity_id, upc_id )
)
-- One of several transaction tables, unique by activity, location, and date
-- (date in SQL server is a 3-byte integer)
CREATE TABLE activity_stuff (
activity_id int NOT NULL,
location_id smallint NOT NULL,
transaction_date date NOT NULL,
[ other columns ],
CONSTRAINT PRIMARY KEY PK_activity_stuff CLUSTERED (
activity_id, location_id, transaction_date )
)
There are several hundred unique locaton IDs, several thousand unique activity IDs, and over a million unique UPCs. I have an index on the location_id because it is very frequent to query just by location_id. Would it help, or be silly and redundant, to add a separate index on activity_id, which is also used frequently as a single-column filter?
It is redundant. You can easily check it by adding/deleting index and comparing
explainresults. On the other hand, for the second column in your composite key additional index will help.