Imagine a 1 Million row table with no indexes. Now do a simple “select … from table where columnx=’value’”.
With no indexes on the where clause column(s), that query will require the database engine to physically read EVERY row of the table every time the query is executed. That will result in huge disk, memory, and paging overhead.
Now create an index on the column. Thereafter, each query will have to look at the index (generally a logN function, so maybe 10 reads of index pages) and then only physically access a couple of records from the main table. Result = disk reads drop by about 10000:1, paging vanishes, and memory is free for other queries.

As Sibir1us notes, you can use common Profiler reports (or other tools) to look at your queries that are being run and see which ones are the most resource-intensive. Start with the ones with the most disk reads and work down from there. If you can take a query that is averaging say 100,000 disk reads and cut that down to 1-10 reads, you will find a lot of system performance numbers will get better fast.