Feed: MariaDB Knowledge Base Article Feed.
Author: .
Column Operations
ALTER TABLE ... ADD COLUMN
InnoDB supports adding columns to a table with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
With the exception of adding an auto-increment column, this operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD COLUMN c varchar(50);
Query OK, 0 rows affected (0.006 sec)
This applies to ALTER TABLE ... ADD COLUMN for InnoDB tables.
ALTER TABLE ... DROP COLUMN
InnoDB supports dropping columns from a table with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP COLUMN c;
Query OK, 0 rows affected (0.021 sec)
This applies to ALTER TABLE ... DROP COLUMN for InnoDB tables.
ALTER TABLE ... MODIFY COLUMN
This applies to ALTER TABLE ... MODIFY COLUMN for InnoDB tables.
Reordering Columns
InnoDB supports reordering columns within a table with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c varchar(50) AFTER a;
Query OK, 0 rows affected (0.022 sec)
Changing the Data Type of a Column
InnoDB does not support modifying a column’s data type with ALGORITHM set to INPLACE in most cases.
In MariaDB 10.2.2 and later, the only exception is that increasing the size of a VARCHAR column, which is performed as an instantaneous metadata update.
For example, this fails:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c int;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY
But this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c varchar(100);
Query OK, 0 rows affected (0.005 sec)
Changing a Column to NULL
InnoDB supports modifying a column to allow NULL values with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50) NOT NULL
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c varchar(50) NULL;
Query OK, 0 rows affected (0.021 sec)
Changing a Column to NOT NULL
InnoDB supports modifying a column to not allow NULL values with ALGORITHM set to INPLACE. It is required for strict mode to be enabled in SQL_MODE. The operation will fail if the column contains any NULL values. Changes that would interfere with referential integrity are also not permitted.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c varchar(50) NOT NULL;
Query OK, 0 rows affected (0.021 sec)
Adding a New ENUM Option
InnoDB supports adding a new ENUM option to a column with ALGORITHM set to INPLACE. In order to add a new ENUM option with ALGORITHM set to INPLACE, the following requirements must be met:
- It must be added to the end of the list.
- The storage requirements must not change.
This operation only changes the table’s metadata, so the table does not have to be rebuilt..
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c ENUM('red', 'green')
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c ENUM('red', 'green', 'blue');
Query OK, 0 rows affected (0.004 sec)
But this fails:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c ENUM('red', 'green')
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c ENUM('red', 'blue', 'green');
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY
Adding a New SET Option
InnoDB supports adding a new SET option to a column with ALGORITHM set to INPLACE. In order to add a new SET option with ALGORITHM set to INPLACE, the following requirements must be met:
- It must be added to the end of the list.
- The storage requirements must not change.
This operation only changes the table’s metadata, so the table does not have to be rebuilt..
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c SET('red', 'green')
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c SET('red', 'green', 'blue');
Query OK, 0 rows affected (0.004 sec)
But this fails:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c SET('red', 'green')
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c SET('red', 'blue', 'green');
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY
Removing System Versioning from a Column
In MariaDB 10.3.8 and later, InnoDB supports removing system versioning from a column with ALGORITHM set to INPLACE. In order for this to work, the system_versioning_alter_history system variable must be set to KEEP. See MDEV-16330 for more information.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50) WITH SYSTEM VERSIONING
);
SET SESSION system_versioning_alter_history='KEEP';
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab MODIFY COLUMN c varchar(50) WITHOUT SYSTEM VERSIONING;
Query OK, 0 rows affected (0.005 sec)
ALTER TABLE ... ALTER COLUMN
This applies to ALTER TABLE ... ALTER COLUMN for InnoDB tables.
Setting a Column’s Default Value
InnoDB supports modifying a column’s DEFAULT value with ALGORITHM set to INPLACE.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ALTER COLUMN c SET DEFAULT 'No value explicitly provided.';
Query OK, 0 rows affected (0.005 sec)
Removing a Column’s Default Value
InnoDB supports removing a column’s DEFAULT value with ALGORITHM set to INPLACE.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50) DEFAULT 'No value explicitly provided.'
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ALTER COLUMN c DROP DEFAULT;
Query OK, 0 rows affected (0.005 sec)
ALTER TABLE ... CHANGE COLUMN
InnoDB supports renaming a column with ALGORITHM set to INPLACE, unless the column’s data type or attributes changed in addition to the name.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab CHANGE COLUMN c str varchar(50);
Query OK, 0 rows affected (0.006 sec)
But this fails:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab CHANGE COLUMN c num int;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY
This applies to ALTER TABLE ... CHANGE COLUMN for InnoDB tables.
Generated Columns
Generated columns do not currently support online DDL for all of the same operations that are supported for “real” columns.
See Generated (Virtual and Persistent/Stored) Columns: Statement Support for more information on the limitations.
Index Operations
ALTER TABLE ... ADD PRIMARY KEY
InnoDB supports adding a primary key to a table with ALGORITHM set to INPLACE.
If the new primary key column is not defined as NOT NULL, then it is highly recommended for strict mode to be enabled in SQL_MODE. Otherwise, NULL values will be silently converted to the default value for the given data type, which is probably not the desired behavior in this scenario.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int,
b varchar(50),
c varchar(50)
);
SET SESSION sql_mode='STRICT_TRANS_TABLES';
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD PRIMARY KEY (a);
Query OK, 0 rows affected (0.021 sec)
But this fails:
CREATE OR REPLACE TABLE tab (
a int,
b varchar(50),
c varchar(50)
);
INSERT INTO tab VALUES (NULL, NULL, NULL);
SET SESSION sql_mode='STRICT_TRANS_TABLES';
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD PRIMARY KEY (a);
ERROR 1265 (01000): Data truncated for column 'a' at row 1
And this fails:
CREATE OR REPLACE TABLE tab (
a int,
b varchar(50),
c varchar(50)
);
INSERT INTO tab VALUES (1, NULL, NULL);
INSERT INTO tab VALUES (1, NULL, NULL);
SET SESSION sql_mode='STRICT_TRANS_TABLES';
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD PRIMARY KEY (a);
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'
This applies to ALTER TABLE ... ADD PRIMARY KEY for InnoDB tables.
ALTER TABLE ... DROP PRIMARY KEY
InnoDB does not support dropping a primary key with ALGORITHM set to INPLACE in most cases.
If you try to do so, then you will see an error. InnoDB only supports this operation with ALGORITHM set to COPY. Concurrent DML is *not* permitted.
However, there is an exception. If you are dropping a primary key, and adding a new one at the same time, then that operation can be performed with ALGORITHM set to INPLACE. This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this fails:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP PRIMARY KEY;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Dropping a primary key is not allowed without also adding a new primary key. Try ALGORITHM=COPY
But this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION sql_mode='STRICT_TRANS_TABLES';
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP PRIMARY KEY, ADD PRIMARY KEY (b);
Query OK, 0 rows affected (0.020 sec)
This applies to ALTER TABLE ... DROP PRIMARY KEY for InnoDB tables.
ALTER TABLE ... ADD INDEX and CREATE INDEX
InnoDB supports adding an index to a table with ALGORITHM set to INPLACE. The table is not rebuilt. This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
However, there is an exception. Adding a FULLTEXT index to a table that does not have a user-defined FTS_DOC_ID column will require the table to be rebuilt once. When the table is rebuilt, the system adds a hidden FTS_DOC_ID column. From that point forward, adding additional FULLTEXT indexes to the same table will not require the table to be rebuilt. In this scenario, this operation supports a read-only locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to SHARED. When this strategy is used, read-only concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD INDEX b_index (b);
Query OK, 0 rows affected (0.010 sec)
And this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
CREATE INDEX b_index ON tab (b);
Query OK, 0 rows affected (0.011 sec)
And this succeeds, but requires the table to be rebuilt:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ADD FULLTEXT INDEX b_index (b);
Query OK, 0 rows affected (0.055 sec)
This applies to ALTER TABLE ... ADD INDEX and CREATE INDEX for InnoDB tables.
ALTER TABLE ... DROP INDEX and DROP INDEX
InnoDB supports dropping indexes from a table with ALGORITHM set to INPLACE.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
INDEX b_index (b)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP INDEX b_index;
And this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
INDEX b_index (b)
);
SET SESSION alter_algorithm='INPLACE';
DROP INDEX b_index ON tab;
This applies to ALTER TABLE ... DROP INDEX and DROP INDEX for InnoDB tables.
ALTER TABLE ... ADD FOREIGN KEY
InnoDB supports adding foreign key constraints to a table with ALGORITHM set to INPLACE. In order to add a new foreign key constraint to a table with ALGORITHM set to INPLACE, the foreign_key_checks system variable needs to be set to OFF. If it is set to ON, then ALGORITHM=COPY is required.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example, this fails:
CREATE OR REPLACE TABLE tab1 (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
d int
);
CREATE OR REPLACE TABLE tab2 (
a int PRIMARY KEY,
b varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab1 ADD FOREIGN KEY tab2_fk (d) REFERENCES tab2 (a);
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Adding foreign keys needs foreign_key_checks=OFF. Try ALGORITHM=COPY
But this succeeds:
CREATE OR REPLACE TABLE tab1 (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
d int
);
CREATE OR REPLACE TABLE tab2 (
a int PRIMARY KEY,
b varchar(50)
);
SET SESSION foreign_key_checks=OFF;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab1 ADD FOREIGN KEY tab2_fk (d) REFERENCES tab2 (a);
Query OK, 0 rows affected (0.011 sec)
This applies to ALTER TABLE ... ADD FOREIGN KEY for InnoDB tables.
ALTER TABLE ... DROP FOREIGN KEY
InnoDB supports dropping foreign key constraints from a table with ALGORITHM set to INPLACE.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab2 (
a int PRIMARY KEY,
b varchar(50)
);
CREATE OR REPLACE TABLE tab1 (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
d int,
FOREIGN KEY tab2_fk (d) REFERENCES tab2 (a)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab1 DROP FOREIGN KEY tab2_fk;
Query OK, 0 rows affected (0.005 sec)
This applies to ALTER TABLE ... DROP FOREIGN KEY for InnoDB tables.
Table Operations
ALTER TABLE ... AUTO_INCREMENT=...
InnoDB supports changing a table’s AUTO_INCREMENT value with ALGORITHM set to INPLACE. This operation should finish instantly. The table is not rebuilt.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab AUTO_INCREMENT=100;
Query OK, 0 rows affected (0.004 sec)
This applies to ALTER TABLE ... AUTO_INCREMENT=... for InnoDB tables.
InnoDB supports changing a table’s row format with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
) ROW_FORMAT=DYNAMIC;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ROW_FORMAT=COMPRESSED;
Query OK, 0 rows affected (0.025 sec)
This applies to ALTER TABLE ... ROW_FORMAT=... for InnoDB tables.
ALTER TABLE ... KEY_BLOCK_SIZE=...
InnoDB supports changing a table’s KEY_BLOCK_SIZE with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
) ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=4;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab KEY_BLOCK_SIZE=2;
Query OK, 0 rows affected (0.021 sec)
This applies to KEY_BLOCK_SIZE=... for InnoDB tables.
ALTER TABLE ... PAGE_COMPRESSED=... and ALTER TABLE ... PAGE_COMPRESSION_LEVEL=...
In MariaDB 10.3.10 and later, InnoDB supports setting a table’s PAGE_COMPRESSED value to 1 with ALGORITHM set to INPLACE. InnoDB also supports changing a table’s PAGE_COMPRESSED value from 1 to 0 with ALGORITHM set to INPLACE.
In these versions, InnoDB also supports changing a table’s PAGE_COMPRESSION_LEVEL value with ALGORITHM set to INPLACE.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
See MDEV-16328 for more information.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab PAGE_COMPRESSED=1;
Query OK, 0 rows affected (0.006 sec)
And this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
) PAGE_COMPRESSED=1;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab PAGE_COMPRESSED=0;
Query OK, 0 rows affected (0.020 sec)
And this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
) PAGE_COMPRESSED=1
PAGE_COMPRESSION_LEVEL=5;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab PAGE_COMPRESSION_LEVEL=4;
Query OK, 0 rows affected (0.006 sec)
This applies to PAGE_COMPRESSED=... and PAGE_COMPRESSION_LEVEL=... for InnoDB tables.
ALTER TABLE ... DROP SYSTEM VERSIONING
InnoDB supports dropping system versioning from a table with ALGORITHM set to INPLACE.
This operation supports the read-only locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to SHARED. When this strategy is used, read-only concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
) WITH SYSTEM VERSIONING;
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP SYSTEM VERSIONING;
This applies to ALTER TABLE ... DROP SYSTEM VERSIONING for InnoDB tables.
ALTER TABLE ... DROP CONSTRAINT
In MariaDB 10.3.6 and later, InnoDB supports dropping a CHECK constraint from a table with ALGORITHM set to INPLACE. See MDEV-16331 for more information.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50),
CONSTRAINT b_not_empty CHECK (b != '')
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab DROP CONSTRAINT b_not_empty;
Query OK, 0 rows affected (0.004 sec)
This applies to ALTER TABLE ... DROP CONSTRAINT for InnoDB tables.
ALTER TABLE ... FORCE
InnoDB supports forcing a table rebuild with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab FORCE;
Query OK, 0 rows affected (0.022 sec)
This applies to ALTER TABLE ... FORCE for InnoDB tables.
ALTER TABLE ... ENGINE=InnoDB
InnoDB supports forcing a table rebuild with ALGORITHM set to INPLACE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
This operation supports the non-locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to NONE. When this strategy is used, all concurrent DML is permitted.
For example:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab ENGINE=InnoDB;
Query OK, 0 rows affected (0.022 sec)
This applies to ALTER TABLE ... ENGINE=InnoDB for InnoDB tables.
OPTIMIZE TABLE ...
InnoDB supports optimizing a table with with ALGORITHM set to INPLACE.
If the innodb_defragment system variable is set to OFF, and if the innodb_optimize_fulltext_only system variable is also set to OFF, then OPTIMIZE TABLE will be equivalent to ALTER TABLE … FORCE.
The table is rebuilt, which means that all of the data is reorganized substantially, and the indexes are rebuilt. As a result, the operation is quite expensive.
If either of the previously mentioned system variables is set to ON, then OPTIMIZE TABLE will optimize some data without rebuilding the table. However, the file size will not be reduced.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SHOW GLOBAL VARIABLES WHERE Variable_name IN('innodb_defragment', 'innodb_optimize_fulltext_only');
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| innodb_defragment | OFF |
| innodb_optimize_fulltext_only | OFF |
+-------------------------------+-------+
SET SESSION alter_algorithm='INPLACE';
OPTIMIZE TABLE tab;
+---------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------+----------+----------+-------------------------------------------------------------------+
| db1.tab | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| db1.tab | optimize | status | OK |
+---------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.026 sec)
And this succeeds, but the table is not rebuilt:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET GLOBAL innodb_defragment=ON;
SHOW GLOBAL VARIABLES WHERE Variable_name IN('innodb_defragment', 'innodb_optimize_fulltext_only');
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| innodb_defragment | ON |
| innodb_optimize_fulltext_only | OFF |
+-------------------------------+-------+
SET SESSION alter_algorithm='INPLACE';
OPTIMIZE TABLE tab;
+---------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------+----------+----------+----------+
| db1.tab | optimize | status | OK |
+---------+----------+----------+----------+
1 row in set (0.004 sec)
This applies to OPTIMIZE TABLE for InnoDB tables.
ALTER TABLE ... RENAME TO and RENAME TABLE ...
InnoDB supports renaming a table with ALGORITHM set to INPLACE.
This operation only changes the table’s metadata, so the table does not have to be rebuilt.
This operation supports the exclusive locking strategy. This strategy can be explicitly chosen by setting the LOCK clause to EXCLUSIVE. When this strategy is used, concurrent DML is not permitted.
For example, this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
ALTER TABLE tab RENAME TO old_tab;
Query OK, 0 rows affected (0.011 sec)
And this succeeds:
CREATE OR REPLACE TABLE tab (
a int PRIMARY KEY,
b varchar(50),
c varchar(50)
);
SET SESSION alter_algorithm='INPLACE';
RENAME TABLE tab TO old_tab;
This applies to ALTER TABLE ... RENAME TO and RENAME TABLE for InnoDB tables.
Why Attend Conferences?
