Features Added in MySQL 8.0 database administrators to control where tablespace data files are created and ensures that the data files can be found during recovery. General and file-per-table tablespaces data files ( .ibd  files) can no longer be created in the undo tablespace directory ( innodb_undo_directory ) unless that directly is known to  InnoDB . Known directories are those defined by the  datadir ,  innodb_data_home_dir , and innodb_directories  variables. Truncating an  InnoDB  table that resides in a file-per-table tablespace drops the existing tablespace and creates a new one. As of MySQL 8.0.21,  InnoDB  creates the new tablespace in the default location and writes a warning to the error log if the current tablespace directory is unknown. To have  TRUNCATE TABLE  create the tablespace in its current location, add the directory to the innodb_directories  setting before running  TRUNCATE TABLE . •As of MySQL 8.0.21, redo logging can be enabled and disabled using  ALTER INSTANCE {ENABLE| DISABLE} INNODB REDO_LOG  syntax. This functionality is intended for loading data into a new MySQL instance. Disabling redo logging helps speed up data loading by avoiding redo log writes. The new  INNODB_REDO_LOG_ENABLE  privilege permits enabling and disabling redo logging. The new  Innodb_redo_log_enabled  status variable permits monitoring redo logging status. See Disabling Redo Logging. •At startup,  InnoDB  validates the paths of known tablespace files against tablespace file paths stored in the data dictionary in case tablespace files have been moved to a different location. The new innodb_validate_tablespace_paths  variable, introduced in MySQL 8.0.21, permits disabling tablespace path validation. This feature is intended for environments where tablespaces files are not moved. Disabling tablespace path validation improves startup time on systems with a large number of tablespace files. •As of MySQL 8.0.21, on storage engines that support atomic DDL, the  CREATE TABLE ... SELECT statement is logged as one transaction in the binary log when row-based replication is in use. Previously, it was logged as two transactions, one to create the table, and the other to insert data. With this change,  CREATE TABLE ... SELECT  statements are now safe for row-based replication and permitted for use with GTID-based replication. For more information, see Section 13.1.1, “Atomic Data Definition Statement Support” . •Truncating an undo tablespace on a busy system could affect performance due to associated flushing operations that remove old undo tablespace pages from the buffer pool and flush the initial pages of the new undo tablespace to disk. To address this issue, the flushing operations are removed as of MySQL 8.0.21. To prevent potential issues caused by an excessive number of undo tablespace truncate operations, truncate operations on the same undo tablespace between checkpoints are now limited to 64. If the Old undo tablespace pages are released passively as they become least recently used, or are removed at the next full checkpoint. The initial pages of the new undo tablespace are now redo logged instead of flushed to disk during the truncate operation, which also improves durability of the undo tablespace truncate operation. 20 For more information, see Section 15.6.3.7, “Disabling Tablespace Path Validation” .