OK...
Things that will slow down a query-based operation:
1. Not having an index on a field that the query uses. (This leads to a big "uh-oh" called a "relation scan".) Help topic: Indexes
2. Having multiple tables in a query but having no formal relationship between them. (This leads to an even BIGGER "uh-oh" called a "Cartesian JOIN" or a "permutation join.") Help topic: Relationships
3. Defining the relationship in the "wrong" direction. (This gives you more records than you need to get the job done, sometimes.) Help topic: Relationships, one/many or many/one relationships
4. Having a lot of indexes on a table that is updated frequently. Help topics: Indexes, updates.
5. Doing a lot of updates, inserts, and deletes without a regular regimen of setting time aside to do repair and compress operations. Help topics: Repair, Compaction
6. For databases being shared, failing to appropriately split the front-end from the back-end, particularly for an application with a very complex front end. Help topics: Splitting a database
Things that don't matter:
1. Having the same table used in multiple different queries. (Query definitions are passive. If the query isn't active, that query has no effect on anything at all.)
2. Having more than one index on a table used in a SELECT query. (Access will only use the indexes it wants to use. If you aren't updating the indexes, the ones you don't use have no "drag" factor on your operation.)
3. Having multiple relationships to a given table. (Access only consults the relationships pertaining to any participants of a currently-active JOIN clause in your query. If any other relationships exist, they are passive at best.)
Things outside of Access to watch out for:
1. Failing to have enough virtual memory defined for your system. (I.e. page files or swap files.)
2. Allowing your disk to get low on free space.
3. Allowing your network to run at a lower speed than it is currently rated for. (I.e. if you have a 10/100 interface, run it at 100 if at all possible.)
