I have a table Employees(Id,CompanyId,Name,Status....)
I have an index Ix_CompanyId_Status(CompanyId,Status)
looking on the dm_db_missing_index_details, I see that sql server wants an index on CompanyId in equality columns without any inequality columns or included columns.
why is this index needed if it's data is already included in the index mentioned above?
If CompanyID is a foreign key you may get it as a suggested index from
dm_db_missing_index_details.
Related
I did many searchs to find answer for my specific issue but didn't manage to find one..
Here is my problem:
I created a filtered index on a table (SQLServer) :
CREATE NONCLUSTERED INDEX [IDX_FilteredIdx] ON [dbo].[MyTable]
(
[Type] ASC,
[CreationDate] ASC
)
WHERE ([Statut]=N'CREATED'
What i see is that SQL requests such as :
select Id, CreationDate, [An other field not in the index] from MyTable
where Type='XXX' and CreationDate<'YYYY'
and Statut=N'CREATED'
use the filtered index (and a key lookup for other field) if 'XXX' is an existing value in the index OR a not existing value in the table (yes sounds very weird..)
If XXX does not exist in the index (no value with CREATED statut for example), but exists in the table, the execution plan turns to a 'clustered index scan' with awful performances (the table is big > 600 M rows) and finally returns empty result as expected...
(The total number of row with statut CREATED is very small compared to the whole table).
I saw that including the column used for filtering was recommended by microsoft :
"A column in the filtered index expression should be a key or included column in the filtered index definition if the column is in the query result set."
but i get the same issue with the column included in the index (and it seems very counter intuitive to add it when the filter criteria is a literal fixed value..).
The only way i found for this request to use the filtered index and get decent performance was to add the Statut column in the second position of the index...
(I also understand than depending on the selected fields and the cardinality of the result the engine may choose to use a clustered index scan to prevent a costly key lookup step.)
Does someone have an explanation for this behavior .. ?
Regards.
I just created a table with TWO primary keys in SQL Server. One column is age, another is ID number and I set the option to CLUSTER INDEX, so it automatically creates a cluster index on both columns. However, when I query the table, the results only seem to sort the ID and completely disregard/ignore the AGE (other PK and other Cluster index column). Why is this? Why is it only sorting based on the first cluster index column?
The query optimizer may decide to use the physical ordering of the rows in the table if there is no advantage in ordering any other way. So, when you select from the table using a simple query, it may be ordered this way. It is very easy to assume that the rows are physically stored in the order specified within the definition of your clustered index. But this turns out to be a false assumption.
Please view the following article for more details: Clustered Index do “NOT” guarantee Physically Ordering or Sorting of Rows
I have a SQL Server 2012 database. My table called REFERENCE has a column called LOCATOR.
My users are entering data but sometimes they enter two different rows with the same LOCATOR. Is there a way I can make this create an error that appears only if the LOCATOR is not null ?
This is what a UNIQUE constraint does (in most DBMS), not allow 2 rows with same value in a column - while ignoring NULL values.
The problem is that SQL-Server has implemented unique constraints differently than other DBMS and does not allow more than one rows with NULL when a unique constraint or index is defined on a column.
The solution is to use a partial index:
CREATE UNIQUE INDEX Locator_UQ -- name of the index
ON Reference (Locator)
WHERE Locator IS NOT NULL ;
Minimal test at: SQL-Fiddle
What is the diffrence between composite index and covering index in Sql Server ?
A covering index is a composite index that contains every column you are currently retrieving with your select statement and that participates in the where clause. It is one of the best ways to improve query performance substantially.
A covering index is a composite index that covers (hence the name) all columns that are necessary to fulfill a query or a join condition.
There is nothing special about SQL server here, these are generic designations.
A composite index is also a covering index when the index contains your search criteria and all the data your query is attempting to retrieve. In this example:
SELECT a,b,c FROM Foo WHERE a = 'FooFoo'
A covering index would contain column a (your search predicate) as well as the columns b and c.
In this case SQL Server is optimized to return those values found in the index and does not need to make an additional look up in the actual table. If b and c are frequently returned but rarely searched on then the index might be set up such that b and c are included in the index but not indexed.
Before SQL Server 2005 DBA's would add additional 'covering' columns to their indexes to achieve this optimization. In SQL Server 2005 an additional feature was added that allowed you to include covering columns in the leaf nodes of the index that were not part of the index tree. When creating an index you can specify additional 'covering' columns in the include clause. These columns will not be indexed but added to the leaf node of the index saving SQL Server from looking up the additional data in the main table. Adding the data to the include clause saves SQL Server the overhead of adding the additional data to the search tree while gaining the optimization that a covering index brings.
I am using SQL Server 2008, had a table with an id (numeric) column as the primary key. Also had a unique index on three varchar columns. I was able to add a row with the exact same set of the three columns. I verified it with a simple query on the values and 2 rows were returned.
I edited the index and added the id column. When I tried to edit it again and remove the id column it complained that there were duplicate rows, it deleted the index but couldn't create it.
I then clean the database of the duplicated, recreated the index with the same 3 varchars as unique and nonclustered and now it works properly, not allowing duplicates.
Does anyone know why the uniqueness of this index was ignored?
The index could had been disabled (see Disabling Indexes), your 'duplicate' values may had been different (trailing spaces for example), or your test may be incorrect.
For sure you did not insert a duplicate in a enforced unique index.
I'm not a pro on this subject, but the 'is unique'-setting of the index probably refers to the way the index is build/stored, not that it is a constraint. This probably also means the performance of the index is sub-optimal.
When creating the index, the DBMS might check this.