You can do some load balancing; but it quickly gets tricky.
I've found the most useful thing to know is what kind of operations your database does normally. If you've got a website; usually its reads. For tracking apps (as an example) you'll have lots of writes.
If you have lots of reads you can make lots of read-only mirrors, chuck a load balancer in front and you're done. Each request is balanced so each request gets the maximum amount of resourcing.
For write heavy systems it's a bit harder because as you add a new server, they need to be aware of what the other is doing - this is where locking comes in. If you have servers A and B; A gets an update or insert request, before it can modify the table it has to say "hey B, make sure you don't change this table, I'm about to change it" (locking) and then commits the change across. This all happens over the network (usually) which means it can be slow (ms not usec) which can hurt performance. As you add servers the performance degrades. With A,B and C; A must talk to both B and C before committing.
Hope this serves as an introduction to db scaling. I'm currently looking into Citrix Netscalers DB load balancing offerings that can help with these questions; I'd recommend looking at least at the docs they have on the topic :)