Execution of flush TABLE with READ lock in long time DDL causes database to not service __ database

Xtrabackup is used in a project to back up the MySQL database. The DDL statement with two exceptions was executed too long, causing the flush table with read lock lock to be unable to be released when the morning backup. Subsequent additions and deletions to the operation block.

The official explanation of flush table with read lock is as follows

FLUSH TABLES with READ Lock acquires a global READ lock and don't table locks, so it's not
subject to the same behavior As LOCK tables and UNLOCK tables with respect to table locking and
implicit commits. For example, START TRANSACTION does not release the global read lock.

Then the database show Processlist entered as follows

| 388671 | XXX | 000:000 | xxx |   Query | 85945 | Sending Data | CREATE TABLE test_xx2 as SELECT * from test_xx1 a WHERE id = 10000 | 388716 | XXX | 0007:0007 | NULL |   Query | 85787 | Waiting for table Metadata Lock | Show create TABLE ' XXX '. ' Test_xx2 ' | | 389593 | XXX | 00032:600,063 | NULL |   Query | 82644 | Waiting for table Metadata Lock | Show create TABLE ' XXX '. ' Test_xx2 ' 

| 404002 | xxx | 000019:40,003 | NULL |   Query | 29001 | Waiting for global read lock | FLUSH TABLES with READ LOCK |
| 404221 | xxx |  10002:0 |       XXX |   Query | 28939 | Waiting for global read lock | UPDATE USERS A SET ....

Try to convert the long DDL into a DML statement, and execute the failed DDL in time to kill. There's no time. Later, add