Techniques for troubleshooting an unexpected mysql query
I am debugging an issue in a legacy PHP application where a certain column in a table is updated without a constraint setting all rows in the table to a value. This behavior is unexpected so I've spent a fair amount of time trying to track down the cause of the error.
The background:
- It's an intermittent problem.
- We can't reproduce it in our development en开发者_如何转开发vironment (which is identical to the production environment)
- The application is using an ORM
What we've tried:
- Reviewing the source code
- Reviewing the mysql bin logs. This allowed us to see that it was a single UPDATE query without a clause that was actually causing the incorrect data to appear.
- Adding additional application-level logging. This has given us a better understanding of the application but we haven't been able to spot the error as it occurs.
My question:
When faced with a seemingly rogue query in an unfamiliar application, what techniques do you use to find the source of that query?
With intermittent problems, I suggest extremely detailed logging in the PHP code. This will allow you to see what is happening when the change happens and what query(ies) are actually being run. If it can't be manually reproduced, there is no real way to track it down without some sort of debug output/logging.
If, even after adding the extra logging, you can't spot the problem, use a test environment and work the application without queries that involve the table in question.
Last, but not least, check the triggers in mySQL. I'm not sure what mySQL logs for triggers, but it makes sense that it would just do an update without giving you specifics in the bin logs.
I don't if it is possible with ORM, but include the __FILE__
and __LINE__
constants in a comment as part of the sql. That way, you can know the file and line of the code from mysql logs.
精彩评论