Nils Gustav Stråbø (9/23/2012)

---

If so I wonder why not hearing much complain of the query running slow?

As Gail said; fragmented indexes will usually not slow down that much, not like out of date statistics causing non-optimal plans.

So does that mean the indexes never been rebuilt?

Yes. Are rows in these tables modified after the import? If not, then the indexes won't get fragmented, and there is no need to run any index or statistics maintenance.

You also say " import data into tables, then add indexes, pks, fks, then restore the database on another sever B"

Do I understand correctly if you drop all constraints prior to the import, then import and the recreate the constraints? And are you doing it in the sequence you mention? Unless your PK is non-clustered, then you really should create it before the other indexes. Rows in index leaf pages use the RID of the row in the heap as the pointer back to the row in the heap, while when the table has a clustered index it uses the cluster key columns as a reference instead.

So if you first create the indexes when there is no clustered index, the index leaf pages will use the RID, and then when you add a clustered index (the PK) all your newly created non-clustered indexes will have to be rebuilt again with the clustering key.

Back to you question