If you're using a recent version of PHP, the mysql_real_escape_string will no longer be available (though mysqli::escape_string is a modern equivalent). These days the mysql_real_escape_string option would only make sense for legacy code on an old version of PHP. Using MYSQLI or PDO prepare statements will do this for you instead.

htmlspecialchars (and also filter_var(), strip_tags() and the like).
Folks. It's HTML encoding, if you didn't notice yet. It has absolutely nothing to do with SQL. It helps nothing in the matter, and should never be used in context of SQL injection protection. It's absolutely inapplicable for SQL, and cannot protect your query even if used as a string escaping function. Leave it for other parts of your application.
Also, please understand, that SQL formatting should never ever touch the data. Then you put your jewelery in a safe, you want it back intact, not some parts amended or replaced "for your own safety!". Same here. A database is intended to store your data, not to "protect" it. And it is essential to store the exact data you want back (means your silly base64 attempt is wrong as well, by the way).

Universal "clean'em all" sanitization functon.
Such a function just should have never exists. Beside the fact that each context we are going to use our data in (SQL query, HTML code, JS code, JSON string, etc. etc. etc.) require different formatting, there are even distinct sub-types of data literals in all these mediums - each require it's own formatting too. Which makes it's just impossible to create a single all-embracing function to format 'em all in once, without spoiling the source data yet leaving huge security holes at the same time.

Filtering out malicious characters and sentences.
This one is simple - it's absolutely imaginary measure. It fails reality check a big one. Nobody ever used it on a more-or-less viable site. Just because it will spoil user experience.

Separate DB accounts for running SELECT and DML queries. Again not a protection measure, but a just a [worthless] attempt to soften the consequences of already preformed attack. Worthless because SELECT-based injection as a disaster alone. And of course useless because we are protected already by formatting our queries properly.