Depending in your perspective, the preferable approach would be to continue doing it the way you're doing it, but to use SSL to encrypt communications between the application server and the database -- because if you don't, then not only are you sending the encryption key in the clear, you're also sending the decrypted data in the clear.
It seems a little bit pointless to protect the encryption key from packet sniffer snooping, while continuing to transmit the data you're trying to protect, over the same channel, also in the clear.
Granted, the exposure would theoretically be less, since you wouldn't be giving away the key, itself, but you're still exposing the "secure" data.
You could avoid passing the key over the wire by declaring a stored function that returns the key, and using a call to the stored function in place of the constant in the queries, but that creates what is arguably a worse scenario, because a breach of your database's security exposes both the encrypted data and the keys necessary for decryption. But, this would avoid the specific issue that you're intending to avoid.
mysql> CREATE FUNCTION aes_key () RETURNS TINYTEXT DETERMINISTIC NO SQL RETURN 'usa2010';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT aes_key();
+-----------+
| aes_key() |
+-----------+
| usa2010 |
+-----------+
Now, your queries look like AES_ENCRYPT('nebraska', aes_key()). As I say, this does accomplish the direct purpose you intend, and the permissions on the stored function would serve to keep honest people honest, but putting it right out there on the server along with the data seems like a particularly bad idea.
Perhaps slightly more orthodox would be to compile a simple User Defined Function (UDF) in C, which would return a constant string -- the decryption key -- when called, and reference that function in the queries. The only advantage of this approach is that the UDF wouldn't be returned if an attacker did a full database dump to extract the data. One potentially significant disadvantage is that user-defined functions are global and are not controlled by permissions -- they are accessible to any user who can connect to the database server.
And, of course, either of these alternatives, like the mechanism you proposed in the question, involves storing the encryption key on the hard drive of the database server, where it is more vulnerable if the database server is breached. If the key is stored with the application code, then both platforms have to be breached for your sensitive data to be effectively stolen.
So, no... I would suggest that the appropriate place for storing the encryption key would be somewhere other than the database server itself, specifically in the application server, and using SSL to connect from the application to MySQL if data on the wire between the two systems is a security concern.
Best Answer
MySQL doesn't support data file encryption natively, but there are ways to do it. There is a product called Vormetric Transparent Encryption. Read info about it here: http://www.vormetric.com/data-security-solutions/use-cases/database-encryption But if you want to actually use SQL for this purpose, newer versions support AES_ENCRYPT() and AES_DECRYPT() (the official AES standard). You can read about the two functions here, in the mysql 5.x manual: https://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-encrypt
So basically you can encrypt the data prior to the insert query. MySql wont know the difference. also, you will have to decrypt it when extracting any data.