1

I have a fact table which is partitioned along the PeriodDate column.

CREATE TABLE MyFactTable
(
    PeriodDate DATE,
    OrderID INT 
         CONSTRAINT MyFk FOREIGN KEY (OrderID) REFERENCES DimOrder(ID)
)

I'd like create a partition aligned index on the OrderID column, and as I understood from BOL, I need to include the partitioning key (PeriodDate) in order to have the index aligned.

Like this:

CREATE NONCLUSTERED INDEX MyAlignedOrderIdIndex 
ON MyFactTable (OrderID, PeriodDate);

My question is: in what order should I put the two columns in the index above?

  1. ON MyFactTable (OrderID, PeriodDate);

or

  1. ON MyFactTable (PeriodDate, OrderID);

As I read on BOL as well the order matters in composite indexes, and my queries will usually use OrderID to lookup Dim table data.

First OrderID, PeriodDate order seems logical choice, but since I am not familiar with partitioning I don't know how it will "like it" when the tables has millions of rows.

What does the best practices dictates here?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Avi
  • 1,066
  • 1
  • 15
  • 37

1 Answers1

2

My question is: In what order should I put the two columns in the index above?:

(OrderID,PeriodDate) The index is there to enable retrieval of all the facts for a given set of OrderIDs, and if your partitions have multiple PeriodDate's in them, having the index with PeriodDate first, wouldn't be as helpful.

The general rule of thumb here is that you don't partition by the leading column. That way you get partition elimination and the index order as fully independent access paths.

My dimension will have a dozen or maximum a hundred rows. The fact table will have millions of rows. Does it worth to create this index?

You'll have to test. It really depends on the queries. However if your fact table is a clustered columnstore (which a fact table with millions of rows typically should be), you'll probably find that the index is not used much for the query workload. Ie it may be used for queries for a single product, but not for queries that filter by non-key product attributes.

David Browne - Microsoft
  • 80,331
  • 6
  • 39
  • 67
  • Thank you. Yes my fact table is indeed a clustered columnstore index. So if I understood correctly this "index on foreign key" best practice doesn't really stand on CCSI tables. Right, I think I need to test. – Avi Jan 17 '20 at 16:09
  • Yes. The "index on foreign key" best-practice actually only applies to OLTP systems, and strictly-speaking only where there are deletes or key-updates on the PK table. Otherwise it's just an optional index, useful only in case it improves performance. It just happens that OLTP systems also have a high frequency of single-value lookups, and put a premium on avoiding scans. – David Browne - Microsoft Jan 17 '20 at 16:12
  • 1
    Thanks, make sense. Unfortunately my fact table will regularly have deletes/updates due to the merges (i know CSI doesn't like that much) but that's my reality. So I will see if that index is ever get touched and if so how much it burdens my inserts. – Avi Jan 17 '20 at 16:17