Is the following possible? I am unable to do so. Do I have to have a permanent table to create index?
declare #Beatles table
(
LastName varchar(20) ,
FirstName varchar(20)
)
CREATE CLUSTERED INDEX Index_Name_Clstd ON #Beatles(LastName)
Not on a table variable, but on a temp table see this http://www.sqlteam.com/article/optimizing-performance-indexes-on-temp-tables
No, you cannot create indices on a table variable - see this article here and this posting here comparing local, global temporary tables to table variables.
Restrictions
You cannot create a non-clustered
index on a table variable, unless the
index is a side effect of a PRIMARY
KEY or UNIQUE constraint on the table
(SQL Server enforces any UNIQUE or
PRIMARY KEY constraints using an
index).
According to this post - YES you can.
The following declaration will generate 2 indexes:
DECLARE #Users TABLE
(
UserID INT PRIMARY KEY,
UserName VARCHAR(50),
FirstName VARCHAR(50),
UNIQUE (UserName,UserID)
)
The first index will be clustered, and will include the primary key.
The second index will be non clustered and will include the the columns listed in the unique constraint.
Here is another post, showing how to force the query optimizer to use the indexes generated dynamically, because it will tend to ignore them (the indexes will be generated after the execution plan is evaluated)
Related
I have a table in SQL Server containing some user related info where the primary key is id (auto increment by 1) and has a column named userId. Each user can only has one record in the table, so I have added a unique constraint on column userId. As per SQL Server docs, SQL Server will automatically create an index for the unique constraint column.
For the usage on the table, there can be many update and insert operations, as well as select operations, and that's where my questions arise.
I see that the index that got created automatically by SQL Server on the unique constraint column is a non-clustered index, where it is good for update and insert operations, but for select operation, it is not as fast as the clustered index. (ref. differences-between-a-clustered-and-a-non-clustered-index)
For this table, there can be many select by userId operations. From the performance perspective, should a clustered index on userId be created, given that clustered index is the fastest for read operations ?
If yes, but a non-clustered index has already been automatically created on column userId, could a clustered index still be created on the userId column? (I have found some similar question, from the answers, it seem like if doing so, it will first search through the non-clustered index, then it will points to the clustered index and continue that search non-clustered-index-and-clustered-index-on-the-same-column)
Assuming your table was created in the following manner:
CREATE TABLE dbo.users
(
id int identity(1,1),
userId int,
userName varchar(100),
emailAddress varchar(100),
constraint PK_dbo_users primary key (Id)
);
alter table dbo.users
add constraint UNQ_dbo_users_userId UNIQUE(userId);
... then you already have a clustered index on "id" column by default.
A table can only have one clustered index, as Jonathon Willcock mentioned in the comments. So you cannot add another clustered index to userId column.
You also cannot recreate the clustered index to switch it to the userId column, as the constraints must much the existing constraint. Also, assuming there are foreign key references involved from other tables, you would have to drop the foreign keys before you can drop the users table.
Another option is to create a nonclustered covering index with an INCLUDE clause that contains all the columns needed for your query. This will avoid key lookups in the query plan.
For example:
create nonclustered index IX_dbo_users
on dbo.users (userId) include (id, userName, emailAddress);
Whether the PK and/or clustered index should be on userId or Id column depends on your users queries. If more queries, or more important queries, rely on "id" having clustered index, then keep it. Etc.
But if your table does not already have a clustered index, then yes, add it on userId column.
Hope for help because of the following problem. Assume we have a table
CREATE TABLE [dbo].[dummy](
[id] [char](36) NOT NULL,
[name] [varchar](50) NOT NULL
) ON [PRIMARY]
If I create a primary key like this (version 1)
ALTER TABLE dummy ADD CONSTRAINT PK_dummy PRIMARY KEY (ID);
I get a unique name. In this case PK_dummy.
But if I create a primary key like this (version 2)
ALTER TABLE dummy ADD PRIMARY KEY Clustered (ID);
The name changes with every recreation of this primary key.
The format is always PK__dummy__"a dynamic number"
What is the meaning of this number?
And how can I identify primary keys created with version 2 in a hugh database?
Thanks for hints.
What is the meaning of this number?
This depends on product version - it is either based on a unique id or generated randomly.
how can I identify primary keys created with version 2 in a huge database?
SELECT *
FROM sys.key_constraints
WHERE is_system_named = 1
If you don't define the name of a constraint, index, key, etc, SQL Server will give it a name. To ensure uniqueness across the database, it therefore will add "random" characters at the end.
If having a consistent name is important then define the name in your statement, as you did in the first statement.
Does temp table with PK and identity creates clustered index internally in sql server. Or we have to create explicitly?
I was working on SP optimization, and came across one article which says that #Temp table with bulk data can have temp db out of memory issue. i reduced #Table size to only few required columns which stores only int columns. Now considering sort operation, for actual table has some benefit of PK and Clusterd Index. so i was curious does #table utilize the same capabilities of SQL.
IDENTITY is purely a property of a column, like NOT NULL. It isn't CLUSTERED, nor is it a PRIMARY KEY unless you tell SQL Server so.
CREATE TABLE T (ID int IDENTITY); will not create an index on the column ID, nor will be be indexed.
The only way you would create a CLUSTERED INDEX on an IDENTITY column would be by using synnax for declare it as your CLUSTERED PRIMARY KEY in your create, altering your table to add the IDENTITY column as a CLUSTERED PRIMARY KEY or creating a CLUSTERED INDEX on the column (as your primary key and Clustered Index don't have to be the same column).
I use SQL Server 2008.
I am trying to create a nonclustered index on my table. I want to check if there exists a way to create this without giving a name to the index.
For e.g.
CREATE TABLE #mytable (Date_ datetime NOT NULL, ID_ varchar(10) NOT NULL, Value_)
When I add a PK to this table, I do not specify the name of that key. For e.g.
ALTER TABLE #mytable ADD PRIMARY KEY CLUSTERED (Date_ ASC, ID_ ASC)
Is it possible to do something similar to create a nonclustered index without specifying a name?
For e.g.
ALTER TABLE #mytable ADD NONCLUSTERED INDEX (Date_, Value_) -- FAILS!!!
The only command I know is
CREATE NONCLUSTERED INDEX *keyname* ON #mytable (Date_, Value_)
After create temp table execute dynamic sequel with guid as index name
DECLARE #NewId VARCHAR(64) = REPLACE(NEWID(),'-','');
EXEC('CREATE INDEX IX_'+#NewId+' ON #Table (ColA,ColB) INCLUDE (ColZ)');
No, it is not possible to create a non-clustered index without a name, the syntax is quite clear:
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
index_name
Is the name of the index. Index names must be unique within a table or
view but do not have to be unique within a database. Index names must
follow the rules of identifiers.
CREATE INDEX (Transact-SQL)
The database object name is referred to as its identifier. Everything
in Microsoft SQL Server can have an identifier. Servers, databases,
and database objects, such as tables, views, columns, indexes,
triggers, procedures, constraints, and rules, can have identifiers.
Identifiers are required for most objects, but are optional for some
objects such as constraints.
Database Identifiers
Can I create a non-unique index during the CREATE TABLE statement in SQLServer 2012? I've found some pre-release documents referencing this, but when I try it, it doesn't work. It looks like that didn't make it into the release, but I'd like to get a more definitive answer.
The document indicated you could do something like:
create table rm.test (
t1 int not null,
t2 int,
constraint pk_t1 primary key (t1),
index idx_t2 (t2)
)
However, it complains on the "index". Is there a way to do this or am I stuck with doing a CREATE INDEX after the table is created?
No.
The inline index definition is new for SQL Server 2014.
In this case you can do
CREATE TABLE rm.test
(
t1 INT NOT NULL CONSTRAINT pk_t1 PRIMARY KEY,
t2 INT,
CONSTRAINT idx_t2 UNIQUE NONCLUSTERED (t2, t1)
)
Which actually creates the same thing though.
Primary keys are the clustered index by default and the CI key gets appended to non unique non clustered keys implicitly to guarantee uniqueness.