Index creation for UPDATE,INSERT,DELETE | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Index creation for UPDATE,INSERT,DELETE

i have a table having 50,000 Records. I can update any of the field . should i create non-cluster index on every field ? If i dont create the index , SQL engine will lock the entire table to search the record first and then it will update. while the table is locked , if the same table is accessed by some other stored procedure, procedure may become the victim of deadlock. Please suggest me the solution ? 1. Should i create the index on every field ?
2. if Yes/ No . Why ?
Its better to go for non-clustered index and do this table has any primary key then default it will create clustered index ..<br />Its strange that you still dint had any index created.<br />Depending on the situation you can create other indexes on diferent fields too.<br />So that query will itself make use of composite indexes.<br />Also depending on the read/write operations select appropriate fill factor default is 100%.[<img src=’/community/emoticons/emotion-1.gif’ alt=’:)‘ />]
Create clustered index for the key column. That will be helpful in searching records
Hereafter post your question at the relevent forum
Madhivanan Failing to plan is Planning to fail
Good question! If I understand correctly, SQL Server will use the Primary Key constraint of a given table to identify the row(s) being touched and handle the locking based on that – so you can see it doesn’t lock at the column level. And if there’s no primary key defined on the table, I’m sure there is a fall-back routine to identify the row(s). Also keep in mind that the PK is not necessarily a clustered index … Although there are tables where you will see indexes on all columns, like tables that resolve many-to-many relationships, you should be careful not add too many indexes to a data entry table, as each additional index will add to the response time on inserts, updates and deletes.;EN-US;814324;EN-US;325024;EN-US;820209;en-us;304519 might be a start. Generally you will not want to create an index on each and every column. While indexes speed up data retrieval operations, they slow down data modification operations. Work your way through the links I’ve posted. They should get you going in the right direction. Btw, regarding deadlocks this might be interesting. —
Frank Kalis
Microsoft SQL Server MVP
Ich unterstütze PASS Deutschland e.V.

Hi,<br />in my opinion u should not have index each and every field / column, create index only on those columns where required (especially the columns u use for creteria / search / condition) because more index / unused can overhead your table.<br /><br />and Adriaan ,<br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">Also keep in mind that the PK is not necessarily a clustered index …<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote"> [?] <br />how ? i have read that if we create PK then by default it creates a Clustered Index … unless we mention nonclusterd isn’t it ?<br /><br /><br />[<img src=’/community/emoticons/emotion-1.gif’ alt=’:)‘ />]<br />Regards.<br /><br /><br /><br /><br />hsGoswami<br />[email protected]<br />"Humans don’t have Caliber to PASS TIME , Time it self Pass or Fail Humans" – by Hemant Goswami<br />
Yes, SQL Server has this behaviour to make the PRIMARY KEY CLUSTERED unless you state otherwise. But that’s exactly what Adriaan said. So I don’t understand your question here.
??? —
Frank Kalis
Microsoft SQL Server MVP
Ich unterstütze PASS Deutschland e.V.

If there is already a clustered index before you add a primary key, the new pk is created as not clustered — CREATE TABLE dbo.Test (IDcol INT IDENTITY(1, 1), VARCHARcol VARCHAR(100))
ADD CONSTRAINT a_Test PRIMARY KEY (IDCol) — Now show the PK details:
EXEC sp_helpconstraint ‘Test’