Storing Social Security Numbers
My recomendation: store your MySQL data on encrypted disks, so that in the event of laptop misplacement, etc, the data cannot be retrieved.
If the database application itself is compromised, of course, nothing can help, as the application itself uses the SSNs. Perhaps that is a design flaw you can correct. I would tend to think in terms of a small, limited application that maps SSN to a (non-SSN) key, and then using that new key as the "user ID" in your database rather than the SSN. I would avoid proliferation of the SSN itself at all costs.
The best method I've seen for storing sensitive data is public key encryption, and storing the private key somewhere other than the database (say, through an application only available to the head of HR and the CEO):
Then we started storing people’s credit cards…but out on the website we’d immediately encrypt them with a public key. ...
On the backend, we had the private key, and with the right pass-phrase we could temporarily decrypt [the private key], then use [the private key] to decrypt a credit card, and charge the card for a DVD.
Don't use the SSN as a primary key or otherwise proliferate their values any more than necessary. Use employee ID numbers or other unique-ID's generated. This will reduce the complexity of the problem.
If at all possible, keep the SSN's in a complete different database instance and do not allow it to be accessed by the day-to-day functions of the external application.
Once you've isolated the SSN, you can use any of the suggested methods to encrypt the data. Encrypting the physical tables and encrypting the stored-fields will make it harder for someone to steal the physical database files or to view SSN's using basic SQL access.
The main concern is to limit access to the SSN table through DB mechanisms, limit OS access, and secure the machine physically. Through the DB, use the most constrained permissions possible. Do not allow web, online, or other "shared" accounts access to the table if at all possible. On OS access, limit logins and directory access to a well known list of users. Turn on any and all auditing possible. As far as physical security, the machine should be in a locked/secured location.
Follow NSA guidelines on computer security where the SSN's are stored and any machine that has access to that machine.
Since you are just a small company, you don't need to worry too much about keeping mailing supplies and funds/insurance for identity monitoring in the event of a breach. Organizations with large numbers of employees and/or customers have faced significant challenges in meeting the legal requirements for breach notification. Finding 26 million envelopes on short notice isn't easy.
I didn't see it mentioned anywhere, but is it necessary for this information to be online? If not, then you've secured one major avenue of attack by simply having this info stored in a database on a computer that's not connected to the internet. Or, if you can get away with having it stored on your LAN somewhere (so HR can have access to it, or whatever), as opposed to production servers, that's still a step in the right direction.
You mentioned that you're at a relatively small company, but it seems like an investment in some cheap hardware wouldn't be too difficult a thing to convince the decision makers of, given the benefits of storing this kind of sensitive info offline. And barring a massive hiring spree in the near future, you don't need a server class computer for storing personal info on ~30 employees by any means.
Wherever you store it, I'd still consider some kind of encryption. AES 256 is the standard for secure these days in most applications and is pretty widely supported. It doesn't sound like it's the sort of application to be under any kind of load, so again, there's no harm in going for a larger key size along with the cheap hardware, from the sounds of it.
As far as implementation goes, if you're comfortable with MySQL - stick with that, they've got the tools you need to do what you want: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html
In the end, security is all about layers, no single solution is going to be the silver bullet, but you can go a long way by adding some pretty simple, common sense security measures.
Edit: after reading what Graeme said, I feel I should add that most security breaches are an inside job - make sure to protect your data at the disk level, through the database, and over the wire.