When discussing database performance with developers, it is too easy to start getting into the fine details of diagnosing query plans, studying wait stats and such before discussing the first principles. Here are my eleven favorite first principles:

1. Focus only on routines or batches whose poor performance is effecting the system. This usually means queries with a high cost in terms of CPU or elapsed time, or which run very frequently.
2. Be very wary of any routines or batches that leave transactions open for anything other than the bare minimum necessary.
3. Avoid the mindset that SQL queries always intrinsically 'take time'. Ten trivial queries run in succession can take far less time than one complex one to do the same task.
4. TempDB is there to be used. If people advise you to avoid using temporary tables, nod politely, but laugh behind their backs. Play nicely with TempDB, however, as with any shared resource.
5. Always run regular automated performance tests (timings and CPU) on all SQL-based processes that you develop for a production environment. Just because something works doesn't mean it is serviceable.
6. Test with realistic data. SQL statements that work well in one size and distribution of data can run like a fly in treacle if the size and distribution of data changes radically.
7. A silly question is likely to get a silly answer. Likewise, a silly SQL Statement is likely to get a silly Execution plan. Poorly-written SQL statements or ill-conceived algorithms, rather than missing indexes, are the greatest performance killers.
8. Always develop on the slowest possible SQL Server with data that matches the character, distribution and size of the production system in its prime. This allows you to detect those SQL Turkeys as you write them, without even having to measure them. Production is where you open the wallet for fast hardware or resources.
9. In SQL, you are merely stating to the system what you want as a result, not how to get it. The Query Optimizer is good at working out the best way of getting what you want, far better than you. It works out the best plan, based on what you want, the distribution and size of the data, and the indexes it can use for your query.
10. Elegant SQL often boils down to the same query plan as awkward-looking SQL. Don't be fooled into believing you can make SQL queries run faster by making them more elegant. There is a lot of syntactic sugar in SQL recipes.
11. A well-normalized database will always perform better. Make sure yours have all the appropriate key, foreign key and check constraints in place.

Disagree, or have others? I'd love to hear from you.

Phil Factor.