I haven't seen your script, but I have to assume it is mainly a delete statement with some conditions to try to detect spam users. In general, running UPDATE and DELETE statements against the framework is a bad practice. If my assumption was accurate, this case is not an exception.
The reason for this is that there is a significant amount of cached information in Q2A. If you want to run DML against the database, you will need to make sure you're leaving the rest of Q2A consistent. This means: checking the PHP code and extracting all SQL (which in many cases is generating dynamically). Even if you manage to do so, after each Q2A upgrade you will have to check for changes in that logic and apply the differences.
In order to avoid all this, several functions have been added to the core that would take care of everything. In this case you should be using qa_delete_user($userid). So keep the conditions from your DELETE statement and turn it into a SELECT statement that return user IDs in a PHP array. Then just iterate one by one and execute that function for each of them.
Extra comment. Now you should have deleted users that require firing some additional updates. In order to fix that, just reverse the logic and take all user IDs present in the ^userpoints table that are not in the ^users table and then try to delete them with the function above (I took a glance at the code and it seems it should work without throwing warnings). Take into account all this makes sense if you are not sharing the ^users table between two or more Q2A sites!
