clustered-index

I am using Fluent-NHibernate (with automapping) to generate my tables but would like to choose a different clustered index than the ID field which is used by default. How can you create clustered indexes with Fluent NHibernate on a field other than the default Primary Key field? The primary reasoning behind this is simple. I am using Guids for my primary key fields. By default, NHibernate creates clustered indexes on the primary key fields. Since Guids are usually not sequential, clustering on the primary key field causes a performance issue. As we all know, appending records at the end of a

IMO, please correct me... the leaf of clustered index contains the real table row, so full clustered index, with intermediate leaves, contain much more data than the full table(?) Why/when/how is ever whole clustered index scan chosen over the full table scan? How is clustered index on CUSTOMER_ID column used in SELECT query which does not contain it in either SELECT list or in WHERE condition [1]? Update: Should I understand that full clustered scan is faster than full table scan because "Each data page contains pointers to the next and previous leaf node page so the scan does not need to use

My two questions are: Can I use clustered indexes to speed up bulk inserts in big tables? Can I then still efficiently use foreign key relationships if my IDENTITY column is not the clustered index anymore? To elaborate, I have a database with a couple of very big (between 100-1000 mln rows) tables containing company data. Typically there is data about 20-40 companies in such a table, each as their own "chunk" marked by "CompanyIdentifier" (INT). Also, every company has about 20 departments, each with their own "subchunk" marked by "DepartmentIdentifier" (INT). It frequently happens that a

Part-time reluctant DBA here. I want to change an existing primary key index from clustered to non-clustered. And the syntax is escaping me. This is how it's scripted out right now. ALTER TABLE [dbo].[Config] WITH NOCHECK ADD CONSTRAINT [PK_Config] PRIMARY KEY CLUSTERED ( [ConfigID] ) ON [PRIMARY] I am not seeing an ALTER CONSTRAINT statement in the online docs. Drop the clustered index, then recreate the primary key as non-clustered: ALTER TABLE dbo.Config DROP CONSTRAINT PK_Config go ALTER TABLE dbo.Config ADD CONSTRAINT PK_Config PRIMARY KEY NONCLUSTERED (ConfigID) 来源： https://stackoverflow

I've inherited some database creation scripts for a SQL SERVER 2005 database. One thing I've noticed is that all primary keys are created as NON CLUSTERED indexes as opposed to clustered. I know that you can only have one clustered index per table and that you may want to have it on a non primary key column for query performance of searches etc. However there are no other CLUSTERED indexes on the tables in questions. So my question is are there any technical reasons not to have clustered indexes on a primary key column apart from the above. On any "normal" data or lookup table: no, I don't see

I have a very large database with hundreds of tables, and after many, many product upgrades, I'm sure half of them aren't being used anymore. How can I tell if a table is is actively being selected from? I can't just use Profiler - not only do I want to watch for more than a few days, but there are thousands of stored procedures as well, and profiler won't translate the SP calls into table access calls. The only thing I can think of is to create a clustered index on the tables of interest, and then monitor the sys.dm_db_index_usage_stats to see if there are any seeks or scans on the clustered