In MySQL we can use the REPLACE statement to replace data in an existing table without inserting a new row. When we do this, we have a choice of syntax when it comes to selecting the row to replace.
One option (and probably the most common option) is to use the VALUES clause. Another option is to use the SET clause.
Below is an example of using the SET clause when using MySQL’s REPLACE statement.
If you’re getting an error in MySQL that reads something like “Duplicate entry ‘1’ for key ‘person.PRIMARY’” when trying to add a primary key to an existing table, it’s probably because the table already contains duplicate values in the column you’re trying to add the primary key to.
When we add a primary key to an existing table, we need to make sure that the column/s that we’re adding the primary key to contains unique values across all of its rows.
One way to fix this issue is to create a composite primary key (one that’s defined across multiple columns). Another way to fix it is to change the values so that they’re all unique. Another option is to apply the primary key to a different column altogether (i.e. one that contains unique values).
Continue readingWhen we use the REPLACE statement in MySQL, we have the option of replacing the values of all columns in the row or just certain columns.
If we choose to replace just certain columns, we need to be aware of how this will affect the outcome. The “missing columns” in the title of this article refers to when we specify a value for just some, but not all columns.
Continue readingIf you’ve ever tried to copy a table with invisible columns in MySQL, you may have been baffled when you realised that none of the invisible columns were copied. Or, you may have copied them, but they ended up VISIBLE instead of INVISIBLE on the new table.
Fortunately, there’s an easy fix to this issue. Actually, there are at least a couple of ways we can approach it.
Continue readingIn MySQL, we can use the REPLACE statement to insert data if we think that some rows need to replace existing rows.
The REPLACE statement works just like the INSERT statement, except that if it contains rows with the same PRIMARY KEY or UNIQUE index as those in the table, then it replaces those rows in the table. It does this by deleting the old row and then inserting the new row.
To use the REPLACE statement, we must have both the INSERT and DELETE privileges for the table.
From MySQL 8.0.23 we’ve had the ability to create invisible columns. But with that comes a potential “gotcha” with our existing queries, and even with new queries we write, depending on how we write them.
The issue is that invisible columns are not returned whenever we use the asterisk wildcard (*) to select data. One of the most common ways to start a query is with SELECT *. This typically selects all columns from the table.
But it doesn’t select invisible columns.
So if we want to include invisible columns, we need to explicitly include them in our SELECT list.
If you’re getting an error that reads “A table must have at least one visible column” in MySQL, it could be that you’re trying to create a table with nothing but invisible columns. Or you could be altering an existing column to be invisible, but it would leave the table with nothing but invisible columns.
To fix this issue, be sure to have at least one visible column in the table.
Continue readingMySQL 8.0.32 introduced the explain_format system variable, which can be used to provide a default output format when using the EXPLAIN statement, or its synonyms DESCRIBE and DESC.
More specifically, it determines the default output format used by this statement in the absence of a FORMAT option when displaying a query execution plan.
If you’ve been using EXPLAIN ANALYZE to analyse your MySQL queries, you may have encountered a little quirk regarding the output format: When we explicitly use FORMAT=TRADITIONAL in our EXPLAIN ANALYZE statement, we get an error. But when our explain_format system variable is set to TRADITIONAL we don’t get an error.
What’s going on with that? Is this a bug?
First up, no it’s not a bug. It can all be explained by the way EXPLAIN ANALYZE handles our explain_format setting.