1 - Never said this was a security issue. This issue is a memory one. You are grabbing more memory than you actually need.
2 - This script proves otherwise (run it via command line with arguments):
$bar = htmlentities(strip_tags($argv));
$query = "SELECT * FROM foo WHERE bar = '$bar'";
SQL injection in it's simplest form.
$ php test.php "asdf' OR 1=1"
SELECT * FROM foo WHERE bar = 'asdf' OR 1=1
3. "Deal with it when it comes up, instead of now while still in development"? In a development environment, you will never have half as many posts or anything as you do in a production environment. So you would never be able to reproduce it there. Why not just do it right the first time especially in stuff which could be such core functionality. Going in later on to optimize is just asking for new bugs.
4. Then why are you overwriting it in your while loop later on.
This will just cause a headache when debugging anything.
user3 = $row['user'];
$user2 = strip_tags($user3);
$user = htmlentities($user2);
5. The first query you run isn't limited. So yes it would have to go through everything (assuming that the table is properly indexed), it would have to go and do an index scan to grab all relevant rows. And then you are selecting the data right out of it, so forcing it to not only find the data, but actually grab the values for it. Whereas if you just did a COUNT on the key column on the table, then it could happen a whole heck of a lot faster.
6. No matter how miniscule things may look / seem in execution time, they add up. Just say you have 3 things that slow down execution of a script by even 5 milliseconds (you have some that do it by more). Each time that snippet of code is executed, you are essentially throwing away 15 milliseconds of execution time. It may seem small, but every millisecond counts when optimizing websites.
9 - Never said anything was wrong, but just more clear for any developer going in there.
10 - But yet you decided to go with the less efficient route. http://maniapets.com/ = 22 characters = 22 * 1 byte (if ASCII (VARCHAR)) or = 22 * 2 bytes (if UNICODE (NVARCHAR)). This adds up. And quickly! Especially for such a frequently used table such as 'player updates'.
These ones here don't call for huge changes ... but multiply that through each and every one of the scripts that you currently have on the site. And remember, I had only gone through 39% of the code when I stopped. There are likely more. So the "one or two lines that need to be changed" is actually a lot higher than that.
"Which in fact it doesn't in the result, because there isn't enough to slow anything down." - Key words here ... ."isn't enough to slow anything down" ... meaning you are anticipating at one point in time yes, it WILL slow down when there is enough 'stuff'.
That right there is how application are made. Not fine tuning. If you consider optimizations, readability and poor decisions fine tuning there are bigger issues.