Generally speaking, data doesn't just randomly modify itself. Someone or something must be changing it. Since it's stored in a database it would be changed via a sql statement. That makes "update" statements the obvious culprit here, though depending on your db and code it could also be a "replace", "insert" or "delete" statement causing the problem.
As a simple example, a badly written update statement like this could cause the problem:
UPDATE user_account SET balance = balance - 3 WHERE user_id = '172' OR balance > 3
The OR in this statement should have been an AND. This will subtract $3 from the user with id 172 as well as all users with more than $3 in their account. Even though the user with id 10 hasn't logged in, he or she may still have $3 deducted from their account.
In a production environment it is fairly common to have a line like this in your mysql configuration:
log-bin = /var/log/mysql/mysql-bin.log
This would save a binary log in the file listed. This is basically all sql statements which modified any data in the database. You can then read the log file using a command like this:
mysqlbinlog -d mydatabasename /var/log/mysql/mysql-bin.log > mysql_log.txt
So this shows you the actual sql used, and the timestamp, among other things.
So say if you review your sql statements and find there is no way it was some simple slipup and if it was changed it had to have referenced the actual user identifier, then you can search the sql log for any statements affecting that user. The structure of the sql may help you narrow it down, but you also get the timestamp from that, which you can match against your weblogs.
Oh, there's also a log directive in mysql which saves a plaintext log of all sql statements run, including select statements. This is normally disabled in production. Its just "log = /path/to/file".
