Identify candidates for and add SQL indices

[Piedone]

Let's add some SQL indices where the most common queries would need it.

We had discussions about this before that adding such indices is up to who operates the site since suitable indices depend on typical usage. This is partially true, as for the existing queries of built-in modules we can safely assume that for most of the time suitable indices will be needed.

Furthermore modules could add indices to tables of modules they depend on just for their own queries if there are no suitable ones already. Not sure about this as this would probably add a lot of coupling.

It would be great if people with big databases and high load would share what SQL Server's Missing Indexes feature suggests.

[dcinzona]

+1

[MpDzik]

+1

[pszmyd]

+1, but it highly depends on a scenario. Too many indices is not good either.
Right now we have indices on columns Orchard queries on by default, afaik.

[Piedone]

There are a few indices but we don't remotely have one for every suitable scenerio. E.g. there is no index on UserPartRecord.NormalizedUserName though this is directly queried in Orchard.Users.

[ASADeveloper]

+1

[sebastienros]

-10

Ha ha, I win

[sebastienros]

We must have missed some obvious one, right. We already have all the common ones taken care of. For instance we did the changes so that we could handle millions of content items. Users might be missing, you are right. It should be tactical ones though, not all, as @pszmyd is suggesting.

[Piedone]

IdentityPart.Identifier would also need an index.