Sort operation taking most of the query cost [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 4 months ago.

Improve this question

Please see below query and execution plan - Any advice on how to get rid of SORT operator cost (nothing coming on missing indexes recommendation)

Answer 1

Your plan is an image and this is bad.

Your tables are heaps and this is worse.

With knowing nothing about uniqueness in your tables and deducing it only from table names, I suggest you to add PK clustered to your DimCorp:

alter table DimCorp
add constraint PK_DimCorp primary key clustered(DimCorpId)

And clustered (I don't think it is unique) on your FactCallDetail:

create clustered index ix_cl_DimCorpId on FactCallDetail(DimCorpId)

Answer 2

As sepupic's answer points out, the reason you're getting a sort operator (and poor performance) is because you're missing clustered indexes on your tables, and therefore their underlying data structure is a heap.

In order for SQL to be able to "efficiently" join them together with the nested loop operator, it first sorts one of the heaps, which in this case has millions of rows causing the sort to be extra heavy of an operation.

If you add clustered indexes on the DimCorpId field in the FactCallDetail and DimCorp tables, then the data will be saved to disk pre-sorted by DimCorpId in a B-Tree data structure. Not only will this eliminate the sort operator from that part of the execution plan, it'll tremendously increase performance of the join between both tables on DimCorpId.