I have a table that serves as a foreign key lookup from another table. The table is very simple, containing a ID column with is the primary key and a JSON column. I wish to remove abandoned entries from this table.
I tried running this script:
DELETE
FROM `ate`.`test_configuration`
WHERE `ate`.`test_configuration`.`ID` NOT IN (SELECT DISTINCT `ate`.`index`.`TestID` from `ate`.`index`);
But encountered an error stating my I wasn't using a where clause that uses the key column:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
This is confusing as my where clause does use the primary key column. I am aware that I can disable safe mode as part of my script as a workaround, but would still like to understand why I'm getting this error. I'd like to avoid unsafe updates if possible.
I believe Optimizer just unable to use index effectively for such query - so it does full table scan.
How many rows are in the test_configuration and how many of them will be deleted?
(You might try to use index hints to force optimizer to use index for the query, just not sure if they are supported in your version of mysql).
Related
Please consider the following scenario:
I have a MySQL table called actor. (Yes, it's from the Sakila sample DB).
In the table there's a varchar column called last_name.
There is a (non-PRIMARY) KEY on the column.
MySQL safe update mode is turned on.
When I run this query, it works:
DELETE FROM actor WHERE last_name = 'foo';
When I run this query:
DELETE FROM actor WHERE last_name LIKE '%fo' OR last_name LIKE 'fo%';
It fails with this error message:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column. To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
Why does safe update mode stop the second command and allow the first command?
According to the documentation:
It is possible for UPDATE and DELETE statements to produce an error in safe-updates mode even with a key specified in the WHERE clause, if the optimizer decides not to use the index on the key column.
A test like LIKE 'fo%' will normally use the index (the index can be used to match the beginning of a column), so it shouldn't cause the error. But a test like LIKE '%fo' cannot be indexed (it doesn't specify the beginning of the column, so a full scan is necessary), so you get an error.
If I try to update or delete one of my tables in my database (and only that table), I cannot do so without enabling safe mode.
Query:
UPDATE booking SET bookingDate='2017-09-20' WHERE id=123456;
Error:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
The problem with that error message is that I do actually have a primary key which is an index and I was trying to use it to update the row, but for some reason my database just doesn't recognise it. I only have that problem on one specific table as well.
I understand that I could turn off safe updates every time that I want to run an update or delete a row, but that isn't what I want to do as I shouldn't have to do that with a primary key present.
I have tried dropping the table and rebuilding it, but that didn't work either.
My table is created like this:
CREATE TABLE test(
num1 INT,
num2 INT,
PRIMARY KEY(num1, num2)
);
what should my delete query look like?
using
DELETE FROM test WHERE num1=1 AND num2=2;
only result in this error message:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
Also, before you ask, I do know how to turn safe update mode off, but that does not answer my question.
I've seen some other Stack Overflow posts where people complain that MySQL Workbench is blocking them from performing safe updates inappropriately.
But I just tried it with your table, both with the PK columns and with a non-key column. When safe mode is enabled, it blocks me from doing updates via non-key column, as it should. But I don't get the error you described.
I'm using MySQL Workbench 6.3.8 and MySQL Server 8.0.0-dmr.
Perhaps this is a bug in an old version of MySQL or an old version of MySQL Workbench.
Updated mysql and the error is gone.
what a waste of my time.
Hopefully a very quick question: I'm having some trouble getting the following
index creation statement to work. I'm using MySQL Workbench.
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate)
WHERE hiredate > '2001-01-01';
I'm trying to get the following index creation to work, however regardless of what I look up online the following is listed as the proper syntax but for some reason that is unfathomable at this point, the index is specifically saying that the where clause is in the incorrect place.
I'm clearly missing something in the examples.
(Context, just trying to create a filtered index only interested in dates greater then).
It looks like this should be easy as hell, what am I missing here?
You don't need the WHERE clause. But MySQL doesn't support filtered index. (Reference here)
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate);
Also that command doesn't work if you try to create a primary key. If that's the case, you need to use ALTER TABLE command.
Is there a performance difference between using unique constraint and trigger to prevent duplicated rows in MySQL?
Monitor it. But well, the outcome should be obvious.
As the unique index exists specifically to enforce this constraint, it should be the first choice.
By using the trigger you would have to do additional operations to even check if there is the dataset (tablescan vs index lookup, or you set an index without constraint on the column but...), then react to it accordingly. So if there is nothing else you are trying to do (logging the failed attempt maybe), this would be unnecessary steps.