Fix MySQL Error 1175: How to Disable Safe Update Mode

The Problem

It happens to the best of us. You're trying to clean up a dataset in MySQL Workbench—perhaps flagging 1,500 inactive users—but your UPDATE statement hits a brick wall. Instead of modified rows, you get a frustrating rejection notice:

Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column.

This isn't a bug. It is a built-in safety net. By default, MySQL Workbench prevents you from running queries that might accidentally wipe out an entire table. It requires you to either target a specific primary key or explicitly confirm that you intend to perform a bulk operation.

Why This Error Occurs

The Safe Updates feature is a guardian for your data. When active, it blocks any UPDATE or DELETE statement that fails to meet these specific requirements:

The query must include a WHERE clause referencing a Key Column (like an id or uuid).
The query must include a LIMIT clause to restrict the impact.

If you try to update records using a non-indexed column—like a 'category' or 'status' field—the safety check triggers. It assumes you might have forgotten your filter entirely.

Solution 1: The Quick SQL Fix (Session-based)

Need to run a one-time bulk update? You can temporarily disable the restriction for your current connection. This is the cleanest approach because it doesn't change your global security settings.

Step 1: Lower the Shield

SET SQL_SAFE_UPDATES = 0;

Step 2: Execute Your Query

Now, MySQL will allow the operation. For example, updating users who haven't logged in since the start of 2024:

UPDATE users 
SET status = 'archived' 
WHERE last_login < '2024-01-01';

Step 3: Restore the Safety Net

Don't leave the door open. Once your task is finished, turn the protection back on:

SET SQL_SAFE_UPDATES = 1;

Solution 2: Disable Safe Updates in the Workbench GUI

If you frequently work with large analytical datasets, this feature might feel more like a hurdle than a help. You can disable it permanently in your local settings.

Launch MySQL Workbench.
Navigate to Edit > Preferences (macOS users: MySQL Workbench > Settings).
Select SQL Editor from the left-hand sidebar.
Look at the bottom of the right pane for: "Safe Updates" (rejects UPDATEs and DELETEs with no restrictions).
Uncheck the box and click OK.

Note: This change won't apply immediately. You must restart your connection. Close your current SQL tab and reconnect to the server for the new settings to load.

Solution 3: The Primary Key "Trick"

Sometimes you can't change server variables or settings. In these cases, you can satisfy the safety check by adding a primary key reference that technically does nothing but fulfills the "use a key" requirement.

If your table uses an auto-incrementing id, add AND id > 0 to your query:

UPDATE products 
SET price = price * 1.05 
WHERE category = 'Software' 
AND id > 0;

Since every valid row has an ID greater than zero, the logic remains the same, but the database's security filter stays happy.

Verification Steps

To ensure your changes took effect, follow these steps:

Run a small test update on a single row using a non-key column.
Monitor the Action Output at the bottom of the screen.
A green checkmark with x row(s) affected means you are successful.
If Error 1175 persists, verify that SET SQL_SAFE_UPDATES = 0; was run in the active tab, as the setting is lost if you switch windows.

Best Practices for Bulk Updates

Disabling safe mode is incredibly useful for large-scale changes, but it does mean you're working without a safety net. Use these habits to stay safe:

Preview your impact: Always run a SELECT with the exact same WHERE clause first. If you expect 50 rows but see 50,000, you've saved yourself from a disaster.
Use Transactions: Wrap your logic in a safety block. This allows you to inspect the results before making them permanent.

START TRANSACTION; UPDATE inventory SET stock = 0 WHERE expiration_date < NOW(); -- Check your work... -- Success? Use: COMMIT; -- Error? Use: ROLLBACK;

  
  - **Keep Backups:** Before modifying large production tables, export a quick SQL dump. It's much faster to restore a backup than to manually undo a botched bulk update.