Depends on the number of changes which happen per time-unit. Sometimes, you cannot take the database offline, because you would miss many queries, and you might run into some bad problems if you try to just run them on the corrected database later on. So here are your options, imho:

• Make a backup and hot-fix the problem. RISKY, might lead to an unplanned downtime
• Make the changes on a local copy and upload it. Save, but does not work in all situations
• Use the next planned downtime to fix the problem or make a request for a planned downtime. Save and the thing I would do. Come up with a little game or something to pass the time for your users while they cannot access the site, so you will not take a too huge hit on visitor counts

It's called a data migration (look it up). Basically, you will:

• Download the database to your local machine
• Create a script that will fix your problem
• Test it locally and verify if everything went ok
• Execute the script on the server. Homologation server first, if you have such a thing (you should), and then production.

Some frameworks often offer "features" to help you with data migrations. There are tools to help you execute the code remotely (like fabric in python, or capistrano in ruby), but you could do it manually via ssh as well.

It's probably good practice you commit those data migrations (to have a history of them), but beware they will "rot" in no time, and could be dangerous if executed twice. So, this is a personal opinion: after everything went ok, you should delete them.

I tend to "live on the edge" and apply a hot fix directly in the database, assuming it's a simple fix. This isn't because of ego or anything, but because I'm confident in my skills to be careful in the database and time is usually of the essence.

if it's a more complicated solution, I'll mimic the data in my dev environment, create my solution, test the hell out of it, then apply it to production

We once had a db table that had thousands of records and it was already in prod when we realised, after testing, that some of the entries were strange upper/lowercase combos, e.g. sTranGe... So we implemented a JS 'toupper' method for that field on the form instead of making changes to the db.