This [answer to a stackoverflow question][1] does a great job at explaining the attack that can get around mysqli_real_escape_string() using multi-byte character sets.

I've concluded that when running Drupal 6, we do **not** have to set the charset at the server level in order to be safe from the attack.

Drupal always sets the client to UTF8 (and not the GBK or BIG-5 charsets that are required for the exploit). Newer versions MySQL (> 5.1) are also not vulnerable.

HOWEVER, although Drupal is safe from this exploit, we should still follow the installation documentation which states, "The database should be created with UTF-8 (Unicode) encoding, for example utf8_general_ci.".

[One helpful comment][2] on the installation docs outlines *how* to create your database with UTF8 encoding, and how to ensure that UTF8 is used when performing a backup/restore:

> To achieve this by the mysql command line interface use the following commands:<br>
> `$ mysql -u root -p # Login`<br>
> `mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8`
>
> When using mysqldump/mysql for backup/restore also force both server and client to utf8 by inserting into */etc/mysql/my.cnf*:<br>
> `default-character-set = utf8 # Server`<br>
> `skip-character-set-client-handshake # Force client`


  [1]: http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602
  [2]: https://drupal.org/comment/6851624#comment-6851624