Because you almost always leverage MySQL across a network, you need to protect the 1s and 0s the database is exchanging with other applications. The simplest form of network security is, of course, to disable network access to the MySQL server. In general, this solution is impractical; it means all applications that need to talk to MySQL have to run on the same box as the database. Such an architecture is impossible for client/server applications in which the client is almost always running on some desktop machine. Though in a multitier application, you can stick in the middle tier on the same server as the database, you give up scalability and accomplish nothing more than shifting the security burden from the database to the middle tier.
To fully appreciate the network security needs of MySQL, it is helpful to know how different applications talk to it. All applications talk to MySQL in one of two ways:
Using the MySQL C libraries
Using the MySQL network protocol
Your application may use one of the many meta-APIs such as ODBC, JDBC, DB-API, etc. Under the hood, however, these APIs all use one of the two methods listed above. As a matter of fact, even the MySQL C library technically uses the network protocol. In situations where the client and server are on the same machine, however, it uses Unix sockets or Windows pipes instead of TCP/IP sockets.
Until MySQL 4.0, no support existed to encrypt this network protocol. In other words, all data exchanged between a client ...