问题
I am creating a multi tenant db for an application. I have gone with the TenantID in every table approach and it works very well. I am at the performance tuning stage.
My question is should each TenantID in every table be indexed for optimized searching as every query on the db will filter on this column?
Look forward to any advice.
Thanks
回答1:
Although there are many considerations you need to make when indexing, In my experience, the (unique) clustered index works well as tenantId + PK All PK queries can seek on the composite key.
This has the added advantage of putting the tenantID in your nonclustered indexes as SQL Server uses the clustered key as the reference back to the table from the nonclustered indexes.
Watch out for page splits though, since inserts will almost always be mid page, this approach definitely optimizes for reads. Consider a fill factor of 70 and watch your fragmentation, be sure to have regular index maintenance in place (you want this anyway)
Best of luck.
回答2:
For every query that makes use of the multi-tenant nature of your design you will want to have an index that includes the tenantId. The question is, where in the index structure should tenantId occur? Of course the answer is it depends. Try to build the index so the field with the greatest selectivity comes first.
For example assuming a table with an even distribution across states (50) and with 10 tenants I would build the index as State, then TenantId; for the same table with 1000 tenants I would build the index TenantId, then State.
In practice, both indexes would probable come in handy (let the optimizer sort it out).
来源：https://stackoverflow.com/questions/8144933/indexing-tenantid-in-multi-tenant-db