In a few of the previous places I've worked, it was common practice to use transactions whenever we needed to run queries on production environments. What this does is give you the chance to verify that what you did was "correct". In mysql, entering transaction mode is pretty straight forward:
Even when working in a developer environment, it's sometimes useful to have the ability to undo your work, so that you don't taint your data (which often takes a long time to reload if it's derived from a subset of production data).
Here at thredUP, I tend to use rails console for prototyping a lot of the code I write (I know, I know, that's what tests are for) to validate that it's working as expected. Recently, I ran into a situation where I needed to perform a destructive operation over a subset of data. It becomes difficult to iteratively tweak or improve such code when the subset you're operating on is no longer there! So I discovered a sweet flag when starting rails console that allows you to essentially make your entire session a transaction.
So now you can do any anything to your data and undo it by simply exiting rails console. It appears this is done behind the scenes (watch the logs, to see how) by enclosing any queries called inside a begin/rollback block in mysql. Interestingly, when you perform a save operation, rails saves the state prior to the write operation and then reverts back to it after the write.
For example, the following commands run on the console (in sandbox mode):
Produces the following log entries on the development log:
Notice the 2nd and 4th lines in the log, where it's saving its spot before the db write and restoring it after, respectively. Finally, when you exit out of rails console, rails issues a ROLLBACK on the entire session. You're back to where you started, which can sometimes be a godsend (especially in production :)).