79246777

Date: 2024-12-03 08:24:11
Score: 0.5
Natty:
Report link

In case someone is still wondering about this. Adding index to every foreign key is considered a bad practice.

  1. Don’t index every column of the table.
  2. Don’t create more than 7 indexes per table (clustered and non-clustered)
  3. Don’t leave a table as Heap (create a clustered index).
  4. Don’t create an index on every column involved in every foreign key
  5. Don’t rebuild an index too frequently (monthly once is good enough)
  6. Don’t create an index with more than 5 to 7 key columns
  7. Don’t create an index with more than 5 to 7 included columns
  8. Don’t add your clustered index key in your non-clustered index
  9. Don’t change server fill factor, change it at an index level (as needed)
  10. Don’t ignore index maintenance

https://blog.sqlauthority.com/2020/02/13/sql-server-poor-indexing-strategies-10-donts-for-indexes/

Having too many nonclustered indexes can cause numerous problems. First, unneeded indexes take up space. This impacts storage costs, backup and recovery times, and index maintenance times. Indexes must be kept up to date whenever data changes. The performance of inserts, updates, and deletes is impacted by nonclustered indexes. Have you ever heard of a SELECT query that runs more slowly because there are too many indexes on a table? I have seen it happen. When the optimizer comes up with a plan for a query, it must consider the available indexes, three types of joining, order of joins, etc. The number of plan choices increases exponentially. The optimizer won’t take long to come up with a plan, however, and will sometimes stop with a “good enough plan”. It’s possible that the optimizer didn’t have enough time to figure out the best index because there were too many to consider.

https://blog.sqlauthority.com/2015/03/26/sql-server-mistake-to-avoid-duplicate-and-overlapping-indexes-notes-from-the-field-073

SQL Server Indexes are not always as much as helpful as we like to think. Often they work against our overall server performance. In this session, we will see some troublemaking scenarios and their workarounds. Slow Running Queries are the most common problem that developers face while working with SQL Server. While it is easy to blame SQL Server for unsatisfactory performance, the issue often persists with the way queries have been written, and how Indexes has been set up. The session will focus on the ways of identifying problems that slow down SQL Server, and Indexing tricks to fix them. We will see a few different scenarios where indexes will actually negatively affect the performance of queries. By removing some of the indexes, we can easily improve the performance of overall system. This is a very unique session and will explore the dark side of indexes and its resolutions. Developers will walk out with scripts and knowledge that can be applied to their servers, immediately.

https://www.youtube.com/watch?v=pdS7UZ-mAnA

This issue is inbaked in every relational database. It's just inside the fundamentals how they work. Choose your battles, you cannot make every query fast.

Starting from EF Core 7 here's how you remove this feature.

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
  configurationBuilder.Conventions.Remove(typeof(ForeignKeyIndexConvention));
}

Or by using generics

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
  configurationBuilder.Conventions.Remove<ForeignKeyIndexConvention>();
}

https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/whatsnew#example-dont-create-indexes-for-foreign-key-columns

Reasons:
  • Blacklisted phrase (1): youtube.com
  • Long answer (-1):
  • Has code block (-0.5):
  • Contains question mark (0.5):
  • Low reputation (0.5):
Posted by: Mika Karjunen