Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<ol> <li>make sure you have suitable/appropriate indexes</li> <li>make sure you have a good index maintenance strategy (e.g. rebuild/defrag/keep statistics up to date to ensure indexes stay performing well)</li> <li>identify poorly performing queries and optimise them (may have been written/tested against small data volumes when performance issues would not have shown up)</li> <li>consider partitioning your data (e.g. SQL 2005 and onwards has built in support for partitioning if you have Enterprise Edition). <strong>Edit: to elaborate on SQL Server partitioning, I full recommend a read through <a href="http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx" rel="nofollow noreferrer">this</a> MSDN article on the whys and the hows. On a general note, there was also a good talk at QCon 2008 by Randy Shoup (eBay architect) on scalability, of which one of the key points on scaling a system in general is to partition. It's summarised <a href="http://www.infoq.com/articles/ebay-scalability-best-practices" rel="nofollow noreferrer">here</a>.</strong></li> <li>is your db server hardware sufficient? could it benefit from more memory? <strong>Edit: looking at your comment with your hardware info, I think you could do with (at least) throwing more RAM in it</strong></li> <li>you may benefit from some denormalisation. Difficult to be specific without knowing exact db structure, but denormalising may improve certain queries at the expense of data duplication/disk space</li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload