Introduction

MySQL error code 1175 means you tried to run an UPDATE or DELETE statement without a WHERE clause that references a KEY column while safe update mode is active. This is a safety feature, not a bug. You can fix it by adding a key column to your WHERE clause, temporarily disabling safe updates with SET SQL_SAFE_UPDATES = 0, or turning off safe updates in MySQL Workbench preferences.

What Triggers Error Code 1175?

The full error message reads:

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

MySQL's safe update mode (sql_safe_updates) prevents UPDATE and DELETE statements that could accidentally modify every row in a table. It is enabled by default in MySQL Workbench's interactive SQL editor.

The mode blocks a query when any of these conditions are true:

• The statement has no WHERE clause at all
• The WHERE clause does not reference a column with a primary key or unique index
• The WHERE clause references only non-indexed columns
• The UPDATE uses a LIMIT but still has no key-based WHERE

1-- This triggers error 1175 (no WHERE clause)
2UPDATE customers SET status = 'inactive';
3
4-- This also triggers error 1175 (name is not a key column)
5UPDATE customers SET status = 'inactive' WHERE name = 'John';
6
7-- This works (customer_id is the primary key)
8UPDATE customers SET status = 'inactive' WHERE customer_id = 42;

Three Ways to Fix Error 1175

Fix 1: Add a Key Column to Your WHERE Clause (Recommended)

The safest fix is to rewrite your query so the WHERE clause references a primary key or indexed column:

1-- Update a single row using the primary key
2UPDATE orders SET status = 'shipped' WHERE order_id = 1001;
3
4-- Update multiple specific rows
5UPDATE orders SET status = 'shipped' WHERE order_id IN (1001, 1002, 1003);
6
7-- Update rows matching a condition, but include a key column
8UPDATE orders SET status = 'cancelled'
9WHERE order_id > 0 AND created_at < '2024-01-01';

The WHERE order_id > 0 trick satisfies the safe update check while still applying your actual filter. Use this when you genuinely need to update many rows but want to keep safe mode active.

Fix 2: Temporarily Disable Safe Updates in Your Session

If you need to run a bulk update and adding a key column is impractical, disable safe updates for the duration of your operation:

1-- Disable safe updates
2SET SQL_SAFE_UPDATES = 0;
3
4-- Run your update
5UPDATE customers SET status = 'inactive'
6WHERE last_login < '2023-01-01';
7
8-- Re-enable safe updates immediately
9SET SQL_SAFE_UPDATES = 1;

This change only affects your current session and resets when you disconnect.

Fix 3: Disable Safe Updates in MySQL Workbench Preferences

To permanently disable safe updates in MySQL Workbench:

1. Go to Edit then Preferences (or MySQLWorkbench then Preferences on macOS)
2. Select SQL Editor in the left panel
3. Scroll to the bottom and uncheck Safe Updates (rejects UPDATEs and DELETEs with no restrictions)
4. Click OK
5. Close and reopen your connection tab (the setting takes effect on new connections)

This disables safe mode for all future sessions in Workbench.

Which Fix Should You Choose?

How Safe Update Mode Works Internally

The sql_safe_updates system variable controls this behavior. When enabled, MySQL checks the query plan before execution. It specifically looks for whether the optimizer can use an index to limit the affected rows.

You can check the current state of this variable:

1-- Check if safe updates is enabled
2SHOW VARIABLES LIKE 'sql_safe_updates';
3
4-- Check it via SELECT
5SELECT @@sql_safe_updates;

The variable works in conjunction with two other variables that limit potentially dangerous queries:

1-- Maximum rows an UPDATE/DELETE can examine (default: 1000 in Workbench)
2SHOW VARIABLES LIKE 'sql_select_limit';
3
4-- Maximum join size
5SHOW VARIABLES LIKE 'max_join_size';

Safe Updates with JOINs and Subqueries

Error 1175 also affects UPDATE and DELETE statements that use JOINs or subqueries. The key column requirement applies to the table being modified:

1-- This may trigger error 1175
2UPDATE orders o
3JOIN customers c ON o.customer_id = c.id
4SET o.status = 'review'
5WHERE c.country = 'US';
6
7-- This works (o.order_id is the primary key of the updated table)
8UPDATE orders o
9JOIN customers c ON o.customer_id = c.id
10SET o.status = 'review'
11WHERE o.order_id > 0 AND c.country = 'US';

For DELETE with JOINs:

1-- This triggers error 1175
2DELETE o FROM orders o
3JOIN customers c ON o.customer_id = c.id
4WHERE c.status = 'deleted';
5
6-- This works
7DELETE o FROM orders o
8WHERE o.order_id IN (
9    SELECT order_id FROM (
10        SELECT o2.order_id FROM orders o2
11        JOIN customers c ON o2.customer_id = c.id
12        WHERE c.status = 'deleted'
13    ) AS subquery
14);

Error 1175 in Other MySQL Clients

Safe update mode is not exclusive to MySQL Workbench. Other clients and connection methods may also enable it:

1# MySQL CLI with safe updates enabled
2mysql --safe-updates -u root -p
3
4# MySQL CLI with safe updates disabled
5mysql --no-safe-updates -u root -p

In application code, you can control it per connection:

1# Python (mysql-connector-python)
2import mysql.connector
3
4conn = mysql.connector.connect(
5    host='localhost',
6    user='root',
7    password='password',
8    database='mydb'
9)
10cursor = conn.cursor()
11cursor.execute("SET SQL_SAFE_UPDATES = 0")
12cursor.execute("UPDATE customers SET status = 'inactive' WHERE last_login < '2023-01-01'")
13cursor.execute("SET SQL_SAFE_UPDATES = 1")
14conn.commit()

Common Pitfalls

• Forgetting to reconnect after changing Workbench preferences: The preference change only applies to new connections. You must close and reopen the query tab.
• Leaving safe updates permanently disabled in production: This removes a safety net that prevents accidental mass updates. Only disable it in development environments.
• Using WHERE 1=1 as a workaround: This does not satisfy the safe update check because 1=1 does not reference a key column. Use WHERE primary_key > 0 instead.
• Confusing sql_safe_updates with read_only: sql_safe_updates only blocks unqualified UPDATE/DELETE. It does not prevent all writes. read_only prevents all write operations from non-SUPER users.
• Ignoring the LIMIT interaction: When sql_safe_updates is on, MySQL also limits SELECT results via sql_select_limit. This can cause unexpected result truncation in Workbench queries.

Summary

• Error 1175 fires when UPDATE or DELETE lacks a WHERE clause referencing a KEY column while sql_safe_updates is enabled.
• The safest fix is adding a primary key or indexed column to your WHERE clause.
• Use SET SQL_SAFE_UPDATES = 0 for temporary bulk operations, and always re-enable it with SET SQL_SAFE_UPDATES = 1.
• Permanently disabling safe updates in Workbench preferences is suitable for development but risky for production.
• The WHERE primary_key > 0 pattern satisfies the safe update check when you need to affect many rows.
• Safe update mode also applies to JOINs and subqueries. The key column must reference the table being modified.