Under the covers clustered and nonclustered indexes are the same. The clustered index just has the additional property that is is guaranteed to INCLUDE all columns. Therefore the data does not need to be maintained somewhere else. So, a clustered index and a nonclustered index that INCLUDEs all columns are virtually the same from an update cost perspective.
However, every index needs to be maintained if it contains a column that was changed during an updated. That means, the more indexes you have, the more expensive updates get.
So in your situation, I would try to keep the number of indexes to a minimum. That will help update performance more than worrying about if a particular index is better clustered or covering.
That all being said, your updates still need to find the row(s) to update as quickly as possible. Because you have two orders of magnitude more updates then select, updates should be looked at first when designing the indexing strategy. After they are taken care of, look at providing the minimal number of appropriate indexes for the read queries.
Does Clustered index exist in Oracle database? since I read in some blogs
Yes there is.
It is called "index organized table" (IOT) - which in my opinion is the better name as it makes it absolutely clear that the index and the table are the same physical thing (which is the reason why we can have only one clustered index in SQL Server)
If yes, please let me know the SQL statement to create a cluster index.
There is no such thing as create clustered index
in Oracle.
To create an index organized table, you use the create table
statement with the organization index
option.
In Oracle you usually use IOTs for very narrow tables. Very often for tables that only consist of the primary key columns (e.g. m:n mapping tables), e.g.
create table assignment
(
person_id integer not null,
job_id integer not null,
primary key (person_id, job_id)
)
organization index;
You can create IOTs with more column, in that case the you need to define the non-pk columns as "included" columns. E.g. if the assignment table should have additional columns, like start and end date that are not part of the primary key:
create table assignment
(
person_id integer not null,
job_id integer not null,
start_date date,
end_date date,
primary key (person_id, job_id)
)
organization index
including start_date
overflow storage (initial 4k);
See the manual for more details and examples: https://docs.oracle.com/database/121/SQLRF/statements_7002.htm#i2153235
Somewhat unrelated, but maybe interesting anyway:
An interesting blog post that questions SQL Server's (and MySQL's) behaviour of using a clustered index as the default when creating a table:
Unreasonable Defaults: Primary Key as Clustering Key
Coming from an Oracle background I wholeheartedly agree with that.
Best Answer
As the other answers already indicate SQL Server may or may not explicitly ensure that the rows are sorted in clustered index order prior to the
insert
.This is dependant upon whether or not the clustered index operator in the plan has the
DMLRequestSort
property set (which in turn depends upon the estimated number of rows that are inserted).If you find that SQL Server is underestimating this for whatever reason you might benefit from adding an explicit
ORDER BY
to theSELECT
query to minimize page splits and ensuing fragmentation from theINSERT
operationExample:
Shows that
T
is massively fragmentedBut for
T2
fragmentation is minimalConversely sometimes you might want to force SQL Server to underestimate the row count when you know the data is already pre-sorted and wish to avoid an unnecessary sort. One notable example is when inserting a large number of rows into a table with a
newsequentialid
clustered index key. In versions of SQL Server prior to Denali SQL Server adds an unnecessary and potentially expensive sort operation. This can be avoided bySQL Server will then estimate that 100 rows will be inserted irrespective of the size of
Bar
which is below the threshold at which a sort is added to the plan. However as pointed out in the comments below this does mean that the insert will unfortunately not be able to take advantage of minimal logging.