INSERT INTO `help_topic` (`help_topic_id`, `name`, `help_category_id`, `description`, `example`, `url`) VALUES
(484, 'GROUPING', 39, 'GROUPING(expr [, expr] ...)\n\nFor GROUP BY queries that include a WITH ROLLUP modifier, the ROLLUP\noperation produces super-aggregate output rows where NULL represents\nthe set of all values. The GROUPING() function enables you to\ndistinguish NULL values for super-aggregate rows from NULL values in\nregular grouped rows.\n\nGROUPING() is permitted in the select list, HAVING clause, and (as of\nMySQL 8.0.12) ORDER BY clause.\n\nEach argument to GROUPING() must be an expression that exactly matches\nan expression in the GROUP BY clause. The expression cannot be a\npositional specifier. For each expression, GROUPING() produces 1 if the\nexpression value in the current row is a NULL representing a\nsuper-aggregate value. Otherwise, GROUPING() produces 0, indicating\nthat the expression value is a NULL for a regular result row or is not\nNULL.\n\nSuppose that table t1 contains these rows, where NULL indicates\nsomething like \"other\" or \"unknown\":\n\nmysql> SELECT * FROM t1;\n+------+-------+----------+\n| name | size  | quantity |\n+------+-------+----------+\n| ball | small |       10 |\n| ball | large |       20 |\n| ball | NULL  |        5 |\n| hoop | small |       15 |\n| hoop | large |        5 |\n| hoop | NULL  |        3 |\n+------+-------+----------+\n\nA summary of the table without WITH ROLLUP looks like this:\n\nmysql> SELECT name, size, SUM(quantity) AS quantity\n       FROM t1\n       GROUP BY name, size;\n+------+-------+----------+\n| name | size  | quantity |\n+------+-------+----------+\n| ball | small |       10 |\n| ball | large |       20 |\n| ball | NULL  |        5 |\n| hoop | small |       15 |\n| hoop | large |        5 |\n| hoop | NULL  |        3 |\n+------+-------+----------+\n\nThe result contains NULL values, but those do not represent\nsuper-aggregate rows because the query does not include WITH ROLLUP.\n\nAdding WITH ROLLUP produces super-aggregate summary rows containing\nadditional NULL values. However, without comparing this result to the\nprevious one, it is not easy to see which NULL values occur in\nsuper-aggregate rows and which occur in regular grouped rows:\n\nmysql> SELECT name, size, SUM(quantity) AS quantity\n       FROM t1\n       GROUP BY name, size WITH ROLLUP;\n+------+-------+----------+\n| name | size  | quantity |\n+------+-------+----------+\n| ball | NULL  |        5 |\n| ball | large |       20 |\n| ball | small |       10 |\n| ball | NULL  |       35 |\n| hoop | NULL  |        3 |\n| hoop | large |        5 |\n| hoop | small |       15 |\n| hoop | NULL  |       23 |\n| NULL | NULL  |       58 |\n+------+-------+----------+\n\nTo distinguish NULL values in super-aggregate rows from those in\nregular grouped rows, use GROUPING(), which returns 1 only for\nsuper-aggregate NULL values:\n\nmysql> SELECT\n         name, size, SUM(quantity) AS quantity,\n         GROUPING(name) AS grp_name,\n         GROUPING(size) AS grp_size\n       FROM t1\n       GROUP BY name, size WITH ROLLUP;\n+------+-------+----------+----------+----------+\n| name | size  | quantity | grp_name | grp_size |\n+------+-------+----------+----------+----------+\n| ball | NULL  |        5 |        0 |        0 |\n| ball | large |       20 |        0 |        0 |\n| ball | small |       10 |        0 |        0 |\n| ball | NULL  |       35 |        0 |        1 |\n| hoop | NULL  |        3 |        0 |        0 |\n| hoop | large |        5 |        0 |        0 |\n| hoop | small |       15 |        0 |        0 |\n| hoop | NULL  |       23 |        0 |        1 |\n| NULL | NULL  |       58 |        1 |        1 |\n+------+-------+----------+----------+----------+\n\nCommon uses for GROUPING():\n\no Substitute a label for super-aggregate NULL values:\n\nmysql> SELECT\n         IF(GROUPING(name) = 1, \'All items\', name) AS name,\n         IF(GROUPING(size) = 1, \'All sizes\', size) AS size,\n         SUM(quantity) AS quantity\n       FROM t1\n       GROUP BY name, size WITH ROLLUP;\n+-----------+-----------+----------+\n| name      | size      | quantity |\n+-----------+-----------+----------+\n| ball      | NULL      |        5 |\n| ball      | large     |       20 |\n| ball      | small     |       10 |\n| ball      | All sizes |       35 |\n| hoop      | NULL      |        3 |\n| hoop      | large     |        5 |\n| hoop      | small     |       15 |\n| hoop      | All sizes |       23 |\n| All items | All sizes |       58 |\n+-----------+-----------+----------+\n\no Return only super-aggregate lines by filtering out the regular\n  grouped lines:\n\nmysql> SELECT name, size, SUM(quantity) AS quantity\n       FROM t1\n       GROUP BY name, size WITH ROLLUP\n       HAVING GROUPING(name) = 1 OR GROUPING(size) = 1;\n+------+------+----------+\n| name | size | quantity |\n+------+------+----------+\n| ball | NULL |       35 |\n| hoop | NULL |       23 |\n| NULL | NULL |       58 |\n+------+------+----------+\n\nGROUPING() permits multiple expression arguments. In this case, the\nGROUPING() return value represents a bitmask combined from the results\nfor each expression, where the lowest-order bit corresponds to the\nresult for the rightmost expression. For example, with three expression\narguments, GROUPING(expr1, expr2, expr3) is evaluated like this:\n\n  result for GROUPING(expr3)\n+ result for GROUPING(expr2) << 1\n+ result for GROUPING(expr1) << 2\n\nThe following query shows how GROUPING() results for single arguments\ncombine for a multiple-argument call to produce a bitmask value:\n\nmysql> SELECT\n         name, size, SUM(quantity) AS quantity,\n         GROUPING(name) AS grp_name,\n         GROUPING(size) AS grp_size,\n       GROUPING(name, size) AS grp_all\n       FROM t1\n       GROUP BY name, size WITH ROLLUP;\n+------+-------+----------+----------+----------+---------+\n| name | size  | quantity | grp_name | grp_size | grp_all |\n+------+-------+----------+----------+----------+---------+\n| ball | NULL  |        5 |        0 |        0 |       0 |\n| ball | large |       20 |        0 |        0 |       0 |\n| ball | small |       10 |        0 |        0 |       0 |\n| ball | NULL  |       35 |        0 |        1 |       1 |\n| hoop | NULL  |        3 |        0 |        0 |       0 |\n| hoop | large |        5 |        0 |        0 |       0 |\n| hoop | small |       15 |        0 |        0 |       0 |\n| hoop | NULL  |       23 |        0 |        1 |       1 |\n| NULL | NULL  |       58 |        1 |        1 |       3 |\n+------+-------+----------+----------+----------+---------+\n\nWith multiple expression arguments, the GROUPING() return value is\nnonzero if any expression represents a super-aggregate value.\nMultiple-argument GROUPING() syntax thus provides a simpler way to\nwrite the earlier query that returned only super-aggregate rows, by\nusing a single multiple-argument GROUPING() call rather than multiple\nsingle-argument calls:\n\nmysql> SELECT name, size, SUM(quantity) AS quantity\n       FROM t1\n       GROUP BY name, size WITH ROLLUP\n       HAVING GROUPING(name, size) <> 0;\n+------+------+----------+\n| name | size | quantity |\n+------+------+----------+\n| ball | NULL |       35 |\n| hoop | NULL |       23 |\n| NULL | NULL |       58 |\n+------+------+----------+\n\nUse of GROUPING() is subject to these limitations:\n\no Do not use subquery GROUP BY expressions as GROUPING() arguments\n  because matching might fail. For example, matching fails for this\n  query:\n\nmysql> SELECT GROUPING((SELECT MAX(name) FROM t1))\n       FROM t1\n       GROUP BY (SELECT MAX(name) FROM t1) WITH ROLLUP;\nERROR 3580 (HY000): Argument #1 of GROUPING function is not in GROUP BY\n\no GROUP BY literal expressions should not be used within a HAVING\n  clause as GROUPING() arguments. Due to differences between when the\n  optimizer evaluates GROUP BY and HAVING, matching may succeed but\n  GROUPING() evaluation does not produce the expected result. Consider\n  this query:\n\nSELECT a AS f1, \'w\' AS f2\nFROM t\nGROUP BY f1, f2 WITH ROLLUP\nHAVING GROUPING(f2) = 1;\n\n  GROUPING() is evaluated earlier for the literal constant expression\n  than for the HAVING clause as a whole and returns 0. To check whether\n  a query such as this is affected, use EXPLAIN and look for Impossible\n  having in the Extra column.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(485, 'INET_ATON', 39, 'Syntax:\nINET_ATON(expr)\n\nGiven the dotted-quad representation of an IPv4 network address as a\nstring, returns an integer that represents the numeric value of the\naddress in network byte order (big endian). INET_ATON() returns NULL if\nit does not understand its argument, or if expr is NULL.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT INET_ATON(\'10.0.5.9\');\n        -> 167773449\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(486, 'INET_NTOA', 39, 'Syntax:\nINET_NTOA(expr)\n\nGiven a numeric IPv4 network address in network byte order, returns the\ndotted-quad string representation of the address as a string in the\nconnection character set. INET_NTOA() returns NULL if it does not\nunderstand its argument.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT INET_NTOA(167773449);\n        -> \'10.0.5.9\'\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(487, 'INET6_ATON', 39, 'Syntax:\nINET6_ATON(expr)\n\nGiven an IPv6 or IPv4 network address as a string, returns a binary\nstring that represents the numeric value of the address in network byte\norder (big endian). Because numeric-format IPv6 addresses require more\nbytes than the largest integer type, the representation returned by\nthis function has the VARBINARY data type: VARBINARY(16) for IPv6\naddresses and VARBINARY(4) for IPv4 addresses. If the argument is not a\nvalid address, or if it is NULL, INET6_ATON() returns NULL.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT HEX(INET6_ATON(\'fdfe::5a55:caff:fefa:9089\'));\n        -> \'FDFE0000000000005A55CAFFFEFA9089\'\nmysql> SELECT HEX(INET6_ATON(\'10.0.5.9\'));\n        -> \'0A000509\'\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(488, 'INET6_NTOA', 39, 'Syntax:\nINET6_NTOA(expr)\n\nGiven an IPv6 or IPv4 network address represented in numeric form as a\nbinary string, returns the string representation of the address as a\nstring in the connection character set. If the argument is not a valid\naddress, or if it is NULL, INET6_NTOA() returns NULL.\n\nINET6_NTOA() has these properties:\n\no It does not use operating system functions to perform conversions,\n  thus the output string is platform independent.\n\no The return string has a maximum length of 39 (4 x 8 + 7). Given this\n  statement:\n\nCREATE TABLE t AS SELECT INET6_NTOA(expr) AS c1;\n\n  The resulting table would have this definition:\n\nCREATE TABLE t (c1 VARCHAR(39) CHARACTER SET utf8mb3 DEFAULT NULL);\n\no The return string uses lowercase letters for IPv6 addresses.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT INET6_NTOA(INET6_ATON(\'fdfe::5a55:caff:fefa:9089\'));\n        -> \'fdfe::5a55:caff:fefa:9089\'\nmysql> SELECT INET6_NTOA(INET6_ATON(\'10.0.5.9\'));\n        -> \'10.0.5.9\'\n\nmysql> SELECT INET6_NTOA(UNHEX(\'FDFE0000000000005A55CAFFFEFA9089\'));\n        -> \'fdfe::5a55:caff:fefa:9089\'\nmysql> SELECT INET6_NTOA(UNHEX(\'0A000509\'));\n        -> \'10.0.5.9\'\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(489, 'IS_IPV4', 39, 'Syntax:\nIS_IPV4(expr)\n\nReturns 1 if the argument is a valid IPv4 address specified as a\nstring, 0 otherwise. Returns NULL if expr is NULL.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT IS_IPV4(\'10.0.5.9\'), IS_IPV4(\'10.0.5.256\');\n        -> 1, 0\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(490, 'IS_IPV4_COMPAT', 39, 'Syntax:\nIS_IPV4_COMPAT(expr)\n\nThis function takes an IPv6 address represented in numeric form as a\nbinary string, as returned by INET6_ATON(). It returns 1 if the\nargument is a valid IPv4-compatible IPv6 address, 0 otherwise (unless\nexpr is NULL, in which case the function returns NULL). IPv4-compatible\naddresses have the form ::ipv4_address.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT IS_IPV4_COMPAT(INET6_ATON(\'::10.0.5.9\'));\n        -> 1\nmysql> SELECT IS_IPV4_COMPAT(INET6_ATON(\'::ffff:10.0.5.9\'));\n        -> 0\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(491, 'IS_IPV4_MAPPED', 39, 'Syntax:\nIS_IPV4_MAPPED(expr)\n\nThis function takes an IPv6 address represented in numeric form as a\nbinary string, as returned by INET6_ATON(). It returns 1 if the\nargument is a valid IPv4-mapped IPv6 address, 0 otherwise, unless expr\nis NULL, in which case the function returns NULL. IPv4-mapped addresses\nhave the form ::ffff:ipv4_address.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT IS_IPV4_MAPPED(INET6_ATON(\'::10.0.5.9\'));\n        -> 0\nmysql> SELECT IS_IPV4_MAPPED(INET6_ATON(\'::ffff:10.0.5.9\'));\n        -> 1\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(492, 'IS_IPV6', 39, 'Syntax:\nIS_IPV6(expr)\n\nReturns 1 if the argument is a valid IPv6 address specified as a\nstring, 0 otherwise, unless expr is NULL, in which case the function\nreturns NULL. This function does not consider IPv4 addresses to be\nvalid IPv6 addresses.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT IS_IPV6(\'10.0.5.9\'), IS_IPV6(\'::1\');\n        -> 0, 1\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(493, 'IS_UUID', 39, 'IS_UUID(string_uuid)\n\nReturns 1 if the argument is a valid string-format UUID, 0 if the\nargument is not a valid UUID, and NULL if the argument is NULL.\n\n\"Valid\" means that the value is in a format that can be parsed. That\nis, it has the correct length and contains only the permitted\ncharacters (hexadecimal digits in any lettercase and, optionally,\ndashes and curly braces). This format is most common:\n\naaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee\n\nThese other formats are also permitted:\n\naaaaaaaabbbbccccddddeeeeeeeeeeee\n{aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee}\n\nFor the meanings of fields within the value, see the UUID() function\ndescription.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT IS_UUID(\'6ccd780c-baba-1026-9564-5b8c656024db\');\n+-------------------------------------------------+\n| IS_UUID(\'6ccd780c-baba-1026-9564-5b8c656024db\') |\n+-------------------------------------------------+\n|                                               1 |\n+-------------------------------------------------+\nmysql> SELECT IS_UUID(\'6CCD780C-BABA-1026-9564-5B8C656024DB\');\n+-------------------------------------------------+\n| IS_UUID(\'6CCD780C-BABA-1026-9564-5B8C656024DB\') |\n+-------------------------------------------------+\n|                                               1 |\n+-------------------------------------------------+\nmysql> SELECT IS_UUID(\'6ccd780cbaba102695645b8c656024db\');\n+---------------------------------------------+\n| IS_UUID(\'6ccd780cbaba102695645b8c656024db\') |\n+---------------------------------------------+\n|                                           1 |\n+---------------------------------------------+\nmysql> SELECT IS_UUID(\'{6ccd780c-baba-1026-9564-5b8c656024db}\');\n+---------------------------------------------------+\n| IS_UUID(\'{6ccd780c-baba-1026-9564-5b8c656024db}\') |\n+---------------------------------------------------+\n|                                                 1 |\n+---------------------------------------------------+\nmysql> SELECT IS_UUID(\'6ccd780c-baba-1026-9564-5b8c6560\');\n+---------------------------------------------+\n| IS_UUID(\'6ccd780c-baba-1026-9564-5b8c6560\') |\n+---------------------------------------------+\n|                                           0 |\n+---------------------------------------------+\nmysql> SELECT IS_UUID(RAND());\n+-----------------+\n| IS_UUID(RAND()) |\n+-----------------+\n|               0 |\n+-----------------+\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(494, 'MASTER_POS_WAIT', 39, 'Syntax:\nMASTER_POS_WAIT(log_name,log_pos[,timeout][,channel])\n\nThis function is for control of source/replica synchronization. It\nblocks until the replica has read and applied all updates up to the\nspecified position in the source\'s binary log. From MySQL 8.0.26,\nMASTER_POS_WAIT() is deprecated and the alias SOURCE_POS_WAIT() should\nbe used instead. In releases before MySQL 8.0.26, use\nMASTER_POS_WAIT().\n\nThe return value is the number of log events the replica had to wait\nfor to advance to the specified position. The function returns NULL if\nthe replication SQL thread is not started, the replica\'s source\ninformation is not initialized, the arguments are incorrect, or an\nerror occurs. It returns -1 if the timeout has been exceeded. If the\nreplication SQL thread stops while MASTER_POS_WAIT() is waiting, the\nfunction returns NULL. If the replica is past the specified position,\nthe function returns immediately.\n\nIf the binary log file position has been marked as invalid, the\nfunction waits until a valid file position is known. The binary log\nfile position can be marked as invalid when the CHANGE REPLICATION\nSOURCE TO option GTID_ONLY is set for the replication channel, and the\nserver is restarted or replication is stopped. The file position\nbecomes valid after a transaction is successfully applied past the\ngiven file position. If the applier does not reach the stated position,\nthe function waits until the timeout. Use a SHOW REPLICA STATUS\nstatement to check if the binary log file position has been marked as\ninvalid.\n\nOn a multithreaded replica, the function waits until expiry of the\nlimit set by the replica_checkpoint_group, slave_checkpoint_group,\nreplica_checkpoint_period or slave_checkpoint_period system variable,\nwhen the checkpoint operation is called to update the status of the\nreplica. Depending on the setting for the system variables, the\nfunction might therefore return some time after the specified position\nwas reached.\n\nIf binary log transaction compression is in use and the transaction\npayload at the specified position is compressed (as a\nTransaction_payload_event), the function waits until the whole\ntransaction has been read and applied, and the positions have updated.\n\nIf a timeout value is specified, MASTER_POS_WAIT() stops waiting when\ntimeout seconds have elapsed. timeout must be greater than 0; a zero or\nnegative timeout means no timeout.\n\nThe optional channel value enables you to name which replication\nchannel the function applies to. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(495, 'NAME_CONST', 39, 'Syntax:\nNAME_CONST(name,value)\n\nReturns the given value. When used to produce a result set column,\nNAME_CONST() causes the column to have the given name. The arguments\nshould be constants.\n\nmysql> SELECT NAME_CONST(\'myname\', 14);\n+--------+\n| myname |\n+--------+\n|     14 |\n+--------+\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(496, 'SLEEP', 39, 'Syntax:\nSLEEP(duration)\n\nSleeps (pauses) for the number of seconds given by the duration\nargument, then returns 0. The duration may have a fractional part. If\nthe argument is NULL or negative, SLEEP() produces a warning, or an\nerror in strict SQL mode.\n\nWhen sleep returns normally (without interruption), it returns 0:\n\nmysql> SELECT SLEEP(1000);\n+-------------+\n| SLEEP(1000) |\n+-------------+\n|           0 |\n+-------------+\n\nWhen SLEEP() is the only thing invoked by a query that is interrupted,\nit returns 1 and the query itself returns no error. This is true\nwhether the query is killed or times out:\n\no This statement is interrupted using KILL QUERY from another session:\n\nmysql> SELECT SLEEP(1000);\n+-------------+\n| SLEEP(1000) |\n+-------------+\n|           1 |\n+-------------+\n\no This statement is interrupted by timing out:\n\nmysql> SELECT /*+ MAX_EXECUTION_TIME(1) */ SLEEP(1000);\n+-------------+\n| SLEEP(1000) |\n+-------------+\n|           1 |\n+-------------+\n\nWhen SLEEP() is only part of a query that is interrupted, the query\nreturns an error:\n\no This statement is interrupted using KILL QUERY from another session:\n\nmysql> SELECT 1 FROM t1 WHERE SLEEP(1000);\nERROR 1317 (70100): Query execution was interrupted\n\no This statement is interrupted by timing out:\n\nmysql> SELECT /*+ MAX_EXECUTION_TIME(1000) */ 1 FROM t1 WHERE SLEEP(1000);\nERROR 3024 (HY000): Query execution was interrupted, maximum statement\nexecution time exceeded\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(497, 'SOURCE_POS_WAIT', 39, 'Syntax:\nSOURCE_POS_WAIT(log_name,log_pos[,timeout][,channel])\n\nThis function is for control of source/replica synchronization. It\nblocks until the replica has read and applied all updates up to the\nspecified position in the source\'s binary log. From MySQL 8.0.26, use\nSOURCE_POS_WAIT() in place of MASTER_POS_WAIT(), which is deprecated\nfrom that release. In releases before MySQL 8.0.26, use\nMASTER_POS_WAIT().\n\nThe return value is the number of log events the replica had to wait\nfor to advance to the specified position. The function returns NULL if\nthe replication SQL thread is not started, the replica\'s source\ninformation is not initialized, the arguments are incorrect, or an\nerror occurs. It returns -1 if the timeout has been exceeded. If the\nreplication SQL thread stops while SOURCE_POS_WAIT() is waiting, the\nfunction returns NULL. If the replica is past the specified position,\nthe function returns immediately.\n\nIf the binary log file position has been marked as invalid, the\nfunction waits until a valid file position is known. The binary log\nfile position can be marked as invalid when the CHANGE REPLICATION\nSOURCE TO option GTID_ONLY is set for the replication channel, and the\nserver is restarted or replication is stopped. The file position\nbecomes valid after a transaction is successfully applied past the\ngiven file position. If the applier does not reach the stated position,\nthe function waits until the timeout. Use a SHOW REPLICA STATUS\nstatement to check if the binary log file position has been marked as\ninvalid.\n\nOn a multithreaded replica, the function waits until expiry of the\nlimit set by the replica_checkpoint_group or replica_checkpoint_period\nsystem variable, when the checkpoint operation is called to update the\nstatus of the replica. Depending on the setting for the system\nvariables, the function might therefore return some time after the\nspecified position was reached.\n\nIf binary log transaction compression is in use and the transaction\npayload at the specified position is compressed (as a\nTransaction_payload_event), the function waits until the whole\ntransaction has been read and applied, and the positions have updated.\n\nIf a timeout value is specified, SOURCE_POS_WAIT() stops waiting when\ntimeout seconds have elapsed. timeout must be greater than 0; a zero or\nnegative timeout means no timeout.\n\nThe optional channel value enables you to name which replication\nchannel the function applies to. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(498, 'UUID', 39, 'Syntax:\nUUID()\n\nReturns a Universal Unique Identifier (UUID) generated according to RFC\n4122, \"A Universally Unique IDentifier (UUID) URN Namespace\"\n(http://www.ietf.org/rfc/rfc4122.txt).\n\nA UUID is designed as a number that is globally unique in space and\ntime. Two calls to UUID() are expected to generate two different\nvalues, even if these calls are performed on two separate devices not\nconnected to each other.\n\n*Warning*:\n\nAlthough UUID() values are intended to be unique, they are not\nnecessarily unguessable or unpredictable. If unpredictability is\nrequired, UUID values should be generated some other way.\n\nUUID() returns a value that conforms to UUID version 1 as described in\nRFC 4122. The value is a 128-bit number represented as a utf8mb3 string\nof five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee\nformat:\n\no The first three numbers are generated from the low, middle, and high\n  parts of a timestamp. The high part also includes the UUID version\n  number.\n\no The fourth number preserves temporal uniqueness in case the timestamp\n  value loses monotonicity (for example, due to daylight saving time).\n\no The fifth number is an IEEE 802 node number that provides spatial\n  uniqueness. A random number is substituted if the latter is not\n  available (for example, because the host device has no Ethernet card,\n  or it is unknown how to find the hardware address of an interface on\n  the host operating system). In this case, spatial uniqueness cannot\n  be guaranteed. Nevertheless, a collision should have very low\n  probability.\n\n  The MAC address of an interface is taken into account only on\n  FreeBSD, Linux, and Windows. On other operating systems, MySQL uses a\n  randomly generated 48-bit number.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT UUID();\n        -> \'6ccd780c-baba-1026-9564-5b8c656024db\'\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(499, 'UUID_SHORT', 39, 'Syntax:\nUUID_SHORT()\n\nReturns a \"short\" universal identifier as a 64-bit unsigned integer.\nValues returned by UUID_SHORT() differ from the string-format 128-bit\nidentifiers returned by the UUID() function and have different\nuniqueness properties. The value of UUID_SHORT() is guaranteed to be\nunique if the following conditions hold:\n\no The server_id value of the current server is between 0 and 255 and is\n  unique among your set of source and replica servers\n\no You do not set back the system time for your server host between\n  mysqld restarts\n\no You invoke UUID_SHORT() on average fewer than 16 million times per\n  second between mysqld restarts\n\nThe UUID_SHORT() return value is constructed this way:\n\n  (server_id & 255) << 56\n+ (server_startup_time_in_seconds << 24)\n+ incremented_variable++;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> SELECT UUID_SHORT();\n        -> 92395783831158784\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html');

INSERT INTO `help_topic` (`help_topic_id`, `name`, `help_category_id`, `description`, `example`, `url`) VALUES
(500, 'UUID_TO_BIN', 39, 'Syntax:\nUUID_TO_BIN(string_uuid), UUID_TO_BIN(string_uuid, swap_flag)\n\nConverts a string UUID to a binary UUID and returns the result. (The\nIS_UUID() function description lists the permitted string UUID\nformats.) The return binary UUID is a VARBINARY(16) value. If the UUID\nargument is NULL, the return value is NULL. If any argument is invalid,\nan error occurs.\n\nUUID_TO_BIN() takes one or two arguments:\n\no The one-argument form takes a string UUID value. The binary result is\n  in the same order as the string argument.\n\no The two-argument form takes a string UUID value and a flag value:\n\n  o If swap_flag is 0, the two-argument form is equivalent to the\n    one-argument form. The binary result is in the same order as the\n    string argument.\n\n  o If swap_flag is 1, the format of the return value differs: The\n    time-low and time-high parts (the first and third groups of\n    hexadecimal digits, respectively) are swapped. This moves the more\n    rapidly varying part to the right and can improve indexing\n    efficiency if the result is stored in an indexed column.\n\nTime-part swapping assumes the use of UUID version 1 values, such as\nare generated by the UUID() function. For UUID values produced by other\nmeans that do not follow version 1 format, time-part swapping provides\nno benefit. For details about version 1 format, see the UUID() function\ndescription.\n\nSuppose that you have the following string UUID value:\n\nmysql> SET @uuid = \'6ccd780c-baba-1026-9564-5b8c656024db\';\n\nTo convert the string UUID to binary with or without time-part\nswapping, use UUID_TO_BIN():\n\nmysql> SELECT HEX(UUID_TO_BIN(@uuid));\n+----------------------------------+\n| HEX(UUID_TO_BIN(@uuid))          |\n+----------------------------------+\n| 6CCD780CBABA102695645B8C656024DB |\n+----------------------------------+\nmysql> SELECT HEX(UUID_TO_BIN(@uuid, 0));\n+----------------------------------+\n| HEX(UUID_TO_BIN(@uuid, 0))       |\n+----------------------------------+\n| 6CCD780CBABA102695645B8C656024DB |\n+----------------------------------+\nmysql> SELECT HEX(UUID_TO_BIN(@uuid, 1));\n+----------------------------------+\n| HEX(UUID_TO_BIN(@uuid, 1))       |\n+----------------------------------+\n| 1026BABA6CCD780C95645B8C656024DB |\n+----------------------------------+\n\nTo convert a binary UUID returned by UUID_TO_BIN() to a string UUID,\nuse BIN_TO_UUID(). If you produce a binary UUID by calling\nUUID_TO_BIN() with a second argument of 1 to swap time parts, you\nshould also pass a second argument of 1 to BIN_TO_UUID() to unswap the\ntime parts when converting the binary UUID back to a string UUID:\n\nmysql> SELECT BIN_TO_UUID(UUID_TO_BIN(@uuid));\n+--------------------------------------+\n| BIN_TO_UUID(UUID_TO_BIN(@uuid))      |\n+--------------------------------------+\n| 6ccd780c-baba-1026-9564-5b8c656024db |\n+--------------------------------------+\nmysql> SELECT BIN_TO_UUID(UUID_TO_BIN(@uuid,0),0);\n+--------------------------------------+\n| BIN_TO_UUID(UUID_TO_BIN(@uuid,0),0)  |\n+--------------------------------------+\n| 6ccd780c-baba-1026-9564-5b8c656024db |\n+--------------------------------------+\nmysql> SELECT BIN_TO_UUID(UUID_TO_BIN(@uuid,1),1);\n+--------------------------------------+\n| BIN_TO_UUID(UUID_TO_BIN(@uuid,1),1)  |\n+--------------------------------------+\n| 6ccd780c-baba-1026-9564-5b8c656024db |\n+--------------------------------------+\n\nIf the use of time-part swapping is not the same for the conversion in\nboth directions, the original UUID is not recovered properly:\n\nmysql> SELECT BIN_TO_UUID(UUID_TO_BIN(@uuid,0),1);\n+--------------------------------------+\n| BIN_TO_UUID(UUID_TO_BIN(@uuid,0),1)  |\n+--------------------------------------+\n| baba1026-780c-6ccd-9564-5b8c656024db |\n+--------------------------------------+\nmysql> SELECT BIN_TO_UUID(UUID_TO_BIN(@uuid,1),0);\n+--------------------------------------+\n| BIN_TO_UUID(UUID_TO_BIN(@uuid,1),0)  |\n+--------------------------------------+\n| 1026baba-6ccd-780c-9564-5b8c656024db |\n+--------------------------------------+\n\nIf UUID_TO_BIN() is invoked from within the mysql client, binary\nstrings display using hexadecimal notation, depending on the value of\nthe --binary-as-hex. For more information about that option, see\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(501, 'VALUES', 39, 'Syntax:\nVALUES(col_name)\n\nIn an INSERT ... ON DUPLICATE KEY UPDATE statement, you can use the\nVALUES(col_name) function in the UPDATE clause to refer to column\nvalues from the INSERT portion of the statement. In other words,\nVALUES(col_name) in the UPDATE clause refers to the value of col_name\nthat would be inserted, had no duplicate-key conflict occurred. This\nfunction is especially useful in multiple-row inserts. The VALUES()\nfunction is meaningful only in the ON DUPLICATE KEY UPDATE clause of\nINSERT statements and returns NULL otherwise. See\nhttps://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html\n\n', 'mysql> INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6)\n    -> ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);\n', 'https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html'),
(502, 'ALTER DATABASE', 40, 'Syntax:\nALTER {DATABASE | SCHEMA} [db_name]\n    alter_option ...\n\nalter_option: {\n    [DEFAULT] CHARACTER SET [=] charset_name\n  | [DEFAULT] COLLATE [=] collation_name\n  | [DEFAULT] ENCRYPTION [=] {\'Y\' | \'N\'}\n  | READ ONLY [=] {DEFAULT | 0 | 1}\n}\n\nALTER DATABASE enables you to change the overall characteristics of a\ndatabase. These characteristics are stored in the data dictionary. This\nstatement requires the ALTER privilege on the database. ALTER SCHEMA is\na synonym for ALTER DATABASE.\n\nIf the database name is omitted, the statement applies to the default\ndatabase. In that case, an error occurs if there is no default\ndatabase.\n\nFor any alter_option omitted from the statement, the database retains\nits current option value, with the exception that changing the\ncharacter set may change the collation and vice versa.\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-charset\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-encryption\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-read-only\n\nCharacter Set and Collation Options\n\nThe CHARACTER SET option changes the default database character set.\nThe COLLATE option changes the default database collation. For\ninformation about character set and collation names, see\nhttps://dev.mysql.com/doc/refman/8.0/en/charset.html.\n\nTo see the available character sets and collations, use the SHOW\nCHARACTER SET and SHOW COLLATION statements, respectively. See [HELP\nSHOW CHARACTER SET], and [HELP SHOW COLLATION].\n\nA stored routine that uses the database defaults when the routine is\ncreated includes those defaults as part of its definition. (In a stored\nroutine, variables with character data types use the database defaults\nif the character set or collation are not specified explicitly. See\n[HELP CREATE PROCEDURE].) If you change the default character set or\ncollation for a database, any stored routines that are to use the new\ndefaults must be dropped and recreated.\n\nEncryption Option\n\nThe ENCRYPTION option, introduced in MySQL 8.0.16, defines the default\ndatabase encryption, which is inherited by tables created in the\ndatabase. The permitted values are \'Y\' (encryption enabled) and \'N\'\n(encryption disabled).\n\nThe mysql system schema cannot be set to default encryption. The\nexisting tables within it are part of the general mysql tablespace,\nwhich may be encrypted. The information_schema contains only views. It\nis not possible to create any tables within it. There is nothing on the\ndisk to encrypt. All tables in the performance_schema use the\nPERFORMANCE_SCHEMA engine, which is purely in-memory. It is not\npossible to create any other tables in it. There is nothing on the disk\nto encrypt.\n\nOnly newly created tables inherit the default database encryption. For\nexisting tables associated with the database, their encryption remains\nunchanged. If the table_encryption_privilege_check system variable is\nenabled, the TABLE_ENCRYPTION_ADMIN privilege is required to specify a\ndefault encryption setting that differs from the value of the\ndefault_table_encryption system variable. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html#inn\nodb-schema-tablespace-encryption-default.\n\nRead Only Option\n\nThe READ ONLY option, introduced in MySQL 8.0.22, controls whether to\npermit modification of the database and objects within it. The\npermitted values are DEFAULT or 0 (not read only) and 1 (read only).\nThis option is useful for database migration because a database for\nwhich READ ONLY is enabled can be migrated to another MySQL instance\nwithout concern that the database might be changed during the\noperation.\n\nWith NDB Cluster, making a database read only on one mysqld server is\nsynchronized to other mysqld servers in the same cluster, so that the\ndatabase becomes read only on all mysqld servers.\n\nThe READ ONLY option, if enabled, is displayed in the\nINFORMATION_SCHEMA SCHEMATA_EXTENSIONS table. See\nhttps://dev.mysql.com/doc/refman/8.0/en/information-schema-schemata-ext\nensions-table.html.\n\nThe READ ONLY option cannot be enabled for these system schemas: mysql,\ninformation_schema, performance_schema.\n\nIn ALTER DATABASE statements, the READ ONLY option interacts with other\ninstances of itself and with other options as follows:\n\no An error occurs if multiple instances of READ ONLY conflict (for\n  example, READ ONLY = 1 READ ONLY = 0).\n\no An ALTER DATABASE statement that contains only (nonconflicting) READ\n  ONLY options is permitted even for a read-only database.\n\no A mix of (nonconflicting) READ ONLY options with other options is\n  permitted if the read-only state of the database either before or\n  after the statement permits modifications. If the read-only state\n  both before and after prohibits changes, an error occurs.\n\n  This statement succeeds whether or not the database is read only:\n\nALTER DATABASE mydb READ ONLY = 0 DEFAULT COLLATE utf8mb4_bin;\n\n  This statement succeeds if the database is not read only, but fails\n  if it is already read only:\n\nALTER DATABASE mydb READ ONLY = 1 DEFAULT COLLATE utf8mb4_bin;\n\nEnabling READ ONLY affects all users of the database, with these\nexceptions that are not subject to read-only checks:\n\no Statements executed by the server as part of server initialization,\n  restart, upgrade, or replication.\n\no Statements in a file named at server startup by the init_file system\n  variable.\n\no TEMPORARY tables; it is possible to create, alter, drop, and write to\n  TEMPORARY tables in a read-only database.\n\no NDB Cluster non-SQL inserts and updates.\n\nOther than for the excepted operations just listed, enabling READ ONLY\nprohibits write operations to the database and its objects, including\ntheir definitions, data, and metadata. The following list details\naffected SQL statements and operations:\n\no The database itself:\n\n  o CREATE DATABASE\n\n  o ALTER DATABASE (except to change the READ ONLY option)\n\n  o DROP DATABASE\n\no Views:\n\n  o CREATE VIEW\n\n  o ALTER VIEW\n\n  o DROP VIEW\n\n  o Selecting from views that invoke functions with side effects.\n\n  o Updating updatable views.\n\n  o Statements that create or drop objects in a writable database are\n    rejected if they affect metadata of a view in a read-only database\n    (for example, by making the view valid or invalid).\n\no Stored routines:\n\n  o CREATE PROCEDURE\n\n  o DROP PROCEDURE\n\n  o CALL (of procedures with side effects)\n\n  o CREATE FUNCTION\n\n  o DROP FUNCTION\n\n  o SELECT (of functions with side effects)\n\n  o For procedures and functions, read-only checks follow prelocking\n    behavior. For CALL statements, read-only checks are done on a\n    per-statement basis, so if some conditionally executed statement\n    writing to a read-only database does not actually execute, the call\n    still succeeds. On the other hand, for a function called within a\n    SELECT, execution of the function body happens in prelocked mode.\n    As long as a some statement within the function writes to a\n    read-only database, execution of the function fails with an error\n    regardless of whether the statement actually executes.\n\no Triggers:\n\n  o CREATE TRIGGER\n\n  o DROP TRIGGER\n\n  o Trigger invocation.\n\no Events:\n\n  o CREATE EVENT\n\n  o ALTER EVENT\n\n  o DROP EVENT\n\n  o Event execution:\n\n    o Executing an event in the database fails because that would\n      change the last-execution timestamp, which is event metadata\n      stored in the data dictionary. Failure of event execution also\n      has the effect of causing the event scheduler to stop.\n\n    o If an event writes to an object in a read-only database,\n      execution of the event fails with an error, but the event\n      scheduler is not stopped.\n\no Tables:\n\n  o CREATE TABLE\n\n  o ALTER TABLE\n\n  o CREATE INDEX\n\n  o DROP INDEX\n\n  o RENAME TABLE\n\n  o TRUNCATE TABLE\n\n  o DROP TABLE\n\n  o DELETE\n\n  o INSERT\n\n  o IMPORT TABLE\n\n  o LOAD DATA\n\n  o LOAD XML\n\n  o REPLACE\n\n  o UPDATE\n\n  o For cascading foreign keys where the child table is in a read-only\n    database, updates and deletes on the parent are rejected even if\n    the child table is not directly affected.\n\n  o For a MERGE table such as CREATE TABLE s1.t(i int) ENGINE MERGE\n    UNION (s2.t, s3.t), INSERT_METHOD=..., the following behavior\n    applies:\n\n    o Inserting into the MERGE table (INSERT into s1.t) fails if at\n      least one of s1, s2, s3 is read only, regardless of insert\n      method. The insert is refused even if it would actually end up in\n      a writable table.\n\n    o Dropping the MERGE table (DROP TABLE s1.t) succeeds as long as s1\n      is not read only. It is permitted to drop a MERGE table that\n      refers to a read-only database.\n\nAn ALTER DATABASE statement blocks until all concurrent transactions\nthat have already accessed an object in the database being altered have\ncommitted. Conversely, a write transaction accessing an object in a\ndatabase being altered in a concurrent ALTER DATABASE blocks until the\nALTER DATABASE has committed.\n\nIf the Clone plugin is used to clone a local or remote data directory,\nthe databases in the clone retain the read-only state they had in the\nsource data directory. The read-only state does not affect the cloning\nprocess itself. If it is not desirable to have the same database\nread-only state in the clone, the option must be changed explicitly for\nthe clone after the cloning process has finished, using ALTER DATABASE\noperations on the clone.\n\nWhen cloning from a donor to a recipient, if the recipient has a user\ndatabase that is read only, cloning fails with an error message.\nCloning may be retried after making the database writable.\n\nREAD ONLY is permitted for ALTER DATABASE, but not for CREATE DATABASE.\nHowever, for a read-only database, the statement produced by SHOW\nCREATE DATABASE does include READ ONLY=1 within a comment to indicate\nits read-only status:\n\nmysql> ALTER DATABASE mydb READ ONLY = 1;\nmysql> SHOW CREATE DATABASE mydb\\G\n*************************** 1. row ***************************\n       Database: mydb\nCreate Database: CREATE DATABASE `mydb`\n                 /*!40100 DEFAULT CHARACTER SET utf8mb4\n                          COLLATE utf8mb4_0900_ai_ci */\n                 /*!80016 DEFAULT ENCRYPTION=\'N\' */\n                 /* READ ONLY = 1 */\n\nIf the server executes a CREATE DATABASE statement containing such a\ncomment, the server ignores the comment and the READ ONLY option is not\nprocessed. This has implications for mysqldump and mysqlpump, which use\nSHOW CREATE DATABASE to produce CREATE DATABASE statements in dump\noutput:\n\no In a dump file, the CREATE DATABASE statement for a read-only\n  database contains the commented READ ONLY option.\n\no The dump file can be restored as usual, but because the server\n  ignores the commented READ ONLY option, the restored database is not\n  read only. If the database is to be read only after being restored,\n  you must execute ALTER DATABASE manually to make it so.\n\nSuppose that mydb is read only and you dump it as follows:\n\n$> mysqldump --databases mydb > mydb.sql\n\nA restore operation later must be followed by ALTER DATABASE if mydb\nshould still be read only:\n\n$> mysql\nmysql> SOURCE mydb.sql;\nmysql> ALTER DATABASE mydb READ ONLY = 1;\n\nMySQL Enterprise Backup is not subject to this issue. It backs up and\nrestores a read-only database like any other, but enables the READ ONLY\noption at restore time if it was enabled at backup time.\n\nALTER DATABASE is written to the binary log, so a change to the READ\nONLY option on a replication source server also affects replicas. To\nprevent this from happening, binary logging must be disabled prior to\nexecution of the ALTER DATABASE statement. For example, to prepare for\nmigrating a database without affecting replicas, perform these\noperations:\n\n1. Within a single session, disable binary logging and enable READ ONLY\n   for the database:\n\nmysql> SET sql_log_bin = OFF;\nmysql> ALTER DATABASE mydb READ ONLY = 1;\n\n2. Dump the database, for example, with mysqldump or mysqlpump:\n\n$> mysqldump --databases mydb > mydb.sql\n\n3. Within a single session, disable binary logging and disable READ\n   ONLY for the database:\n\nmysql> SET sql_log_bin = OFF;\nmysql> ALTER DATABASE mydb READ ONLY = 0;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-database.html'),
(503, 'ALTER SCHEMA', 40, 'Syntax:\nALTER {DATABASE | SCHEMA} [db_name]\n    alter_option ...\n\nalter_option: {\n    [DEFAULT] CHARACTER SET [=] charset_name\n  | [DEFAULT] COLLATE [=] collation_name\n  | [DEFAULT] ENCRYPTION [=] {\'Y\' | \'N\'}\n  | READ ONLY [=] {DEFAULT | 0 | 1}\n}\n\nALTER DATABASE enables you to change the overall characteristics of a\ndatabase. These characteristics are stored in the data dictionary. This\nstatement requires the ALTER privilege on the database. ALTER SCHEMA is\na synonym for ALTER DATABASE.\n\nIf the database name is omitted, the statement applies to the default\ndatabase. In that case, an error occurs if there is no default\ndatabase.\n\nFor any alter_option omitted from the statement, the database retains\nits current option value, with the exception that changing the\ncharacter set may change the collation and vice versa.\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-charset\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-encryption\n\no https://dev.mysql.com/doc/refman/8.0/en/alter-database.html#alter-dat\n  abase-read-only\n\nCharacter Set and Collation Options\n\nThe CHARACTER SET option changes the default database character set.\nThe COLLATE option changes the default database collation. For\ninformation about character set and collation names, see\nhttps://dev.mysql.com/doc/refman/8.0/en/charset.html.\n\nTo see the available character sets and collations, use the SHOW\nCHARACTER SET and SHOW COLLATION statements, respectively. See [HELP\nSHOW CHARACTER SET], and [HELP SHOW COLLATION].\n\nA stored routine that uses the database defaults when the routine is\ncreated includes those defaults as part of its definition. (In a stored\nroutine, variables with character data types use the database defaults\nif the character set or collation are not specified explicitly. See\n[HELP CREATE PROCEDURE].) If you change the default character set or\ncollation for a database, any stored routines that are to use the new\ndefaults must be dropped and recreated.\n\nEncryption Option\n\nThe ENCRYPTION option, introduced in MySQL 8.0.16, defines the default\ndatabase encryption, which is inherited by tables created in the\ndatabase. The permitted values are \'Y\' (encryption enabled) and \'N\'\n(encryption disabled).\n\nThe mysql system schema cannot be set to default encryption. The\nexisting tables within it are part of the general mysql tablespace,\nwhich may be encrypted. The information_schema contains only views. It\nis not possible to create any tables within it. There is nothing on the\ndisk to encrypt. All tables in the performance_schema use the\nPERFORMANCE_SCHEMA engine, which is purely in-memory. It is not\npossible to create any other tables in it. There is nothing on the disk\nto encrypt.\n\nOnly newly created tables inherit the default database encryption. For\nexisting tables associated with the database, their encryption remains\nunchanged. If the table_encryption_privilege_check system variable is\nenabled, the TABLE_ENCRYPTION_ADMIN privilege is required to specify a\ndefault encryption setting that differs from the value of the\ndefault_table_encryption system variable. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html#inn\nodb-schema-tablespace-encryption-default.\n\nRead Only Option\n\nThe READ ONLY option, introduced in MySQL 8.0.22, controls whether to\npermit modification of the database and objects within it. The\npermitted values are DEFAULT or 0 (not read only) and 1 (read only).\nThis option is useful for database migration because a database for\nwhich READ ONLY is enabled can be migrated to another MySQL instance\nwithout concern that the database might be changed during the\noperation.\n\nWith NDB Cluster, making a database read only on one mysqld server is\nsynchronized to other mysqld servers in the same cluster, so that the\ndatabase becomes read only on all mysqld servers.\n\nThe READ ONLY option, if enabled, is displayed in the\nINFORMATION_SCHEMA SCHEMATA_EXTENSIONS table. See\nhttps://dev.mysql.com/doc/refman/8.0/en/information-schema-schemata-ext\nensions-table.html.\n\nThe READ ONLY option cannot be enabled for these system schemas: mysql,\ninformation_schema, performance_schema.\n\nIn ALTER DATABASE statements, the READ ONLY option interacts with other\ninstances of itself and with other options as follows:\n\no An error occurs if multiple instances of READ ONLY conflict (for\n  example, READ ONLY = 1 READ ONLY = 0).\n\no An ALTER DATABASE statement that contains only (nonconflicting) READ\n  ONLY options is permitted even for a read-only database.\n\no A mix of (nonconflicting) READ ONLY options with other options is\n  permitted if the read-only state of the database either before or\n  after the statement permits modifications. If the read-only state\n  both before and after prohibits changes, an error occurs.\n\n  This statement succeeds whether or not the database is read only:\n\nALTER DATABASE mydb READ ONLY = 0 DEFAULT COLLATE utf8mb4_bin;\n\n  This statement succeeds if the database is not read only, but fails\n  if it is already read only:\n\nALTER DATABASE mydb READ ONLY = 1 DEFAULT COLLATE utf8mb4_bin;\n\nEnabling READ ONLY affects all users of the database, with these\nexceptions that are not subject to read-only checks:\n\no Statements executed by the server as part of server initialization,\n  restart, upgrade, or replication.\n\no Statements in a file named at server startup by the init_file system\n  variable.\n\no TEMPORARY tables; it is possible to create, alter, drop, and write to\n  TEMPORARY tables in a read-only database.\n\no NDB Cluster non-SQL inserts and updates.\n\nOther than for the excepted operations just listed, enabling READ ONLY\nprohibits write operations to the database and its objects, including\ntheir definitions, data, and metadata. The following list details\naffected SQL statements and operations:\n\no The database itself:\n\n  o CREATE DATABASE\n\n  o ALTER DATABASE (except to change the READ ONLY option)\n\n  o DROP DATABASE\n\no Views:\n\n  o CREATE VIEW\n\n  o ALTER VIEW\n\n  o DROP VIEW\n\n  o Selecting from views that invoke functions with side effects.\n\n  o Updating updatable views.\n\n  o Statements that create or drop objects in a writable database are\n    rejected if they affect metadata of a view in a read-only database\n    (for example, by making the view valid or invalid).\n\no Stored routines:\n\n  o CREATE PROCEDURE\n\n  o DROP PROCEDURE\n\n  o CALL (of procedures with side effects)\n\n  o CREATE FUNCTION\n\n  o DROP FUNCTION\n\n  o SELECT (of functions with side effects)\n\n  o For procedures and functions, read-only checks follow prelocking\n    behavior. For CALL statements, read-only checks are done on a\n    per-statement basis, so if some conditionally executed statement\n    writing to a read-only database does not actually execute, the call\n    still succeeds. On the other hand, for a function called within a\n    SELECT, execution of the function body happens in prelocked mode.\n    As long as a some statement within the function writes to a\n    read-only database, execution of the function fails with an error\n    regardless of whether the statement actually executes.\n\no Triggers:\n\n  o CREATE TRIGGER\n\n  o DROP TRIGGER\n\n  o Trigger invocation.\n\no Events:\n\n  o CREATE EVENT\n\n  o ALTER EVENT\n\n  o DROP EVENT\n\n  o Event execution:\n\n    o Executing an event in the database fails because that would\n      change the last-execution timestamp, which is event metadata\n      stored in the data dictionary. Failure of event execution also\n      has the effect of causing the event scheduler to stop.\n\n    o If an event writes to an object in a read-only database,\n      execution of the event fails with an error, but the event\n      scheduler is not stopped.\n\no Tables:\n\n  o CREATE TABLE\n\n  o ALTER TABLE\n\n  o CREATE INDEX\n\n  o DROP INDEX\n\n  o RENAME TABLE\n\n  o TRUNCATE TABLE\n\n  o DROP TABLE\n\n  o DELETE\n\n  o INSERT\n\n  o IMPORT TABLE\n\n  o LOAD DATA\n\n  o LOAD XML\n\n  o REPLACE\n\n  o UPDATE\n\n  o For cascading foreign keys where the child table is in a read-only\n    database, updates and deletes on the parent are rejected even if\n    the child table is not directly affected.\n\n  o For a MERGE table such as CREATE TABLE s1.t(i int) ENGINE MERGE\n    UNION (s2.t, s3.t), INSERT_METHOD=..., the following behavior\n    applies:\n\n    o Inserting into the MERGE table (INSERT into s1.t) fails if at\n      least one of s1, s2, s3 is read only, regardless of insert\n      method. The insert is refused even if it would actually end up in\n      a writable table.\n\n    o Dropping the MERGE table (DROP TABLE s1.t) succeeds as long as s1\n      is not read only. It is permitted to drop a MERGE table that\n      refers to a read-only database.\n\nAn ALTER DATABASE statement blocks until all concurrent transactions\nthat have already accessed an object in the database being altered have\ncommitted. Conversely, a write transaction accessing an object in a\ndatabase being altered in a concurrent ALTER DATABASE blocks until the\nALTER DATABASE has committed.\n\nIf the Clone plugin is used to clone a local or remote data directory,\nthe databases in the clone retain the read-only state they had in the\nsource data directory. The read-only state does not affect the cloning\nprocess itself. If it is not desirable to have the same database\nread-only state in the clone, the option must be changed explicitly for\nthe clone after the cloning process has finished, using ALTER DATABASE\noperations on the clone.\n\nWhen cloning from a donor to a recipient, if the recipient has a user\ndatabase that is read only, cloning fails with an error message.\nCloning may be retried after making the database writable.\n\nREAD ONLY is permitted for ALTER DATABASE, but not for CREATE DATABASE.\nHowever, for a read-only database, the statement produced by SHOW\nCREATE DATABASE does include READ ONLY=1 within a comment to indicate\nits read-only status:\n\nmysql> ALTER DATABASE mydb READ ONLY = 1;\nmysql> SHOW CREATE DATABASE mydb\\G\n*************************** 1. row ***************************\n       Database: mydb\nCreate Database: CREATE DATABASE `mydb`\n                 /*!40100 DEFAULT CHARACTER SET utf8mb4\n                          COLLATE utf8mb4_0900_ai_ci */\n                 /*!80016 DEFAULT ENCRYPTION=\'N\' */\n                 /* READ ONLY = 1 */\n\nIf the server executes a CREATE DATABASE statement containing such a\ncomment, the server ignores the comment and the READ ONLY option is not\nprocessed. This has implications for mysqldump and mysqlpump, which use\nSHOW CREATE DATABASE to produce CREATE DATABASE statements in dump\noutput:\n\no In a dump file, the CREATE DATABASE statement for a read-only\n  database contains the commented READ ONLY option.\n\no The dump file can be restored as usual, but because the server\n  ignores the commented READ ONLY option, the restored database is not\n  read only. If the database is to be read only after being restored,\n  you must execute ALTER DATABASE manually to make it so.\n\nSuppose that mydb is read only and you dump it as follows:\n\n$> mysqldump --databases mydb > mydb.sql\n\nA restore operation later must be followed by ALTER DATABASE if mydb\nshould still be read only:\n\n$> mysql\nmysql> SOURCE mydb.sql;\nmysql> ALTER DATABASE mydb READ ONLY = 1;\n\nMySQL Enterprise Backup is not subject to this issue. It backs up and\nrestores a read-only database like any other, but enables the READ ONLY\noption at restore time if it was enabled at backup time.\n\nALTER DATABASE is written to the binary log, so a change to the READ\nONLY option on a replication source server also affects replicas. To\nprevent this from happening, binary logging must be disabled prior to\nexecution of the ALTER DATABASE statement. For example, to prepare for\nmigrating a database without affecting replicas, perform these\noperations:\n\n1. Within a single session, disable binary logging and enable READ ONLY\n   for the database:\n\nmysql> SET sql_log_bin = OFF;\nmysql> ALTER DATABASE mydb READ ONLY = 1;\n\n2. Dump the database, for example, with mysqldump or mysqlpump:\n\n$> mysqldump --databases mydb > mydb.sql\n\n3. Within a single session, disable binary logging and disable READ\n   ONLY for the database:\n\nmysql> SET sql_log_bin = OFF;\nmysql> ALTER DATABASE mydb READ ONLY = 0;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-database.html'),
(504, 'ALTER EVENT', 40, 'Syntax:\nALTER\n    [DEFINER = user]\n    EVENT event_name\n    [ON SCHEDULE schedule]\n    [ON COMPLETION [NOT] PRESERVE]\n    [RENAME TO new_event_name]\n    [ENABLE | DISABLE | DISABLE ON SLAVE]\n    [COMMENT \'string\']\n    [DO event_body]\n\nThe ALTER EVENT statement changes one or more of the characteristics of\nan existing event without the need to drop and recreate it. The syntax\nfor each of the DEFINER, ON SCHEDULE, ON COMPLETION, COMMENT, ENABLE /\nDISABLE, and DO clauses is exactly the same as when used with CREATE\nEVENT. (See [HELP CREATE EVENT].)\n\nAny user can alter an event defined on a database for which that user\nhas the EVENT privilege. When a user executes a successful ALTER EVENT\nstatement, that user becomes the definer for the affected event.\n\nALTER EVENT works only with an existing event:\n\nmysql> ALTER EVENT no_such_event \n     >     ON SCHEDULE \n     >       EVERY \'2:3\' DAY_HOUR;\nERROR 1517 (HY000): Unknown event \'no_such_event\'\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-event.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-event.html'),
(505, 'ALTER FUNCTION', 40, 'Syntax:\nALTER FUNCTION func_name [characteristic ...]\n\ncharacteristic: {\n    COMMENT \'string\'\n  | LANGUAGE SQL\n  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }\n  | SQL SECURITY { DEFINER | INVOKER }\n}\n\nThis statement can be used to change the characteristics of a stored\nfunction. More than one change may be specified in an ALTER FUNCTION\nstatement. However, you cannot change the parameters or body of a\nstored function using this statement; to make such changes, you must\ndrop and re-create the function using DROP FUNCTION and CREATE\nFUNCTION.\n\nYou must have the ALTER ROUTINE privilege for the function. (That\nprivilege is granted automatically to the function creator.) If binary\nlogging is enabled, the ALTER FUNCTION statement might also require the\nSUPER privilege, as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-logging.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-function.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-function.html'),
(506, 'ALTER INSTANCE', 40, 'Syntax:\nALTER INSTANCE instance_action\n\ninstance_action: {\n  | {ENABLE|DISABLE} INNODB REDO_LOG\n  | ROTATE INNODB MASTER KEY\n  | ROTATE BINLOG MASTER KEY\n  | RELOAD TLS\n      [FOR CHANNEL {mysql_main | mysql_admin}]\n      [NO ROLLBACK ON ERROR]\n  | RELOAD KEYRING\n}\n\nALTER INSTANCE defines actions applicable to a MySQL server instance.\nThe statement supports these actions:\n\no ALTER INSTANCE {ENABLE | DISABLE} INNODB REDO_LOG\n\n  This action enables or disables InnoDB redo logging. Redo logging is\n  enabled by default. This feature is intended only for loading data\n  into a new MySQL instance. The statement is not written to the binary\n  log. This action was introduced in MySQL 8.0.21.\n\n  *Warning*:\n\n  Do not disable redo logging on a production system. While it is\n  permitted to shut down and restart the server while redo logging is\n  disabled, an unexpected server stoppage while redo logging is\n  disabled can cause data loss and instance corruption.\n\n  An ALTER INSTANCE [ENABLE|DISABLE] INNODB REDO_LOG operation requires\n  an exclusive backup lock, which prevents other ALTER INSTANCE\n  operations from executing concurrently. Other ALTER INSTANCE\n  operations must wait for the lock to be released before executing.\n\n  For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-d\n  isable-redo-logging.\n\no ALTER INSTANCE ROTATE INNODB MASTER KEY\n\n  This action rotates the master encryption key used for InnoDB\n  tablespace encryption. Key rotation requires the ENCRYPTION_KEY_ADMIN\n  or SUPER privilege. To perform this action, a keyring plugin must be\n  installed and configured. For instructions, see\n  https://dev.mysql.com/doc/refman/8.0/en/keyring.html.\n\n  ALTER INSTANCE ROTATE INNODB MASTER KEY supports concurrent DML.\n  However, it cannot be run concurrently with CREATE TABLE ...\n  ENCRYPTION or ALTER TABLE ... ENCRYPTION operations, and locks are\n  taken to prevent conflicts that could arise from concurrent execution\n  of these statements. If one of the conflicting statements is running,\n  it must complete before another can proceed.\n\n  ALTER INSTANCE ROTATE INNODB MASTER KEY statements are written to the\n  binary log so that they can be executed on replicated servers.\n\n  For additional ALTER INSTANCE ROTATE INNODB MASTER KEY usage\n  information, see\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html.\n\no ALTER INSTANCE ROTATE BINLOG MASTER KEY\n\n  This action rotates the binary log master key used for binary log\n  encryption. Key rotation for the binary log master key requires the\n  BINLOG_ENCRYPTION_ADMIN or SUPER privilege. The statement cannot be\n  used if the binlog_encryption system variable is set to OFF. To\n  perform this action, a keyring plugin must be installed and\n  configured. For instructions, see\n  https://dev.mysql.com/doc/refman/8.0/en/keyring.html.\n\n  ALTER INSTANCE ROTATE BINLOG MASTER KEY actions are not written to\n  the binary log and are not executed on replicas. Binary log master\n  key rotation can therefore be carried out in replication environments\n  including a mix of MySQL versions. To schedule regular rotation of\n  the binary log master key on all applicable source and replica\n  servers, you can enable the MySQL Event Scheduler on each server and\n  issue the ALTER INSTANCE ROTATE BINLOG MASTER KEY statement using a\n  CREATE EVENT statement. If you rotate the binary log master key\n  because you suspect that the current or any of the previous binary\n  log master keys might have been compromised, issue the statement on\n  every applicable source and replica server, which enables you to\n  verify immediate compliance.\n\n  For additional ALTER INSTANCE ROTATE BINLOG MASTER KEY usage\n  information, including what to do if the process does not complete\n  correctly or is interrupted by an unexpected server halt, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-binlog-encryption\n  .html.\n\no ALTER INSTANCE RELOAD TLS\n\n  This action reconfigures a TLS context from the current values of the\n  system variables that define the context. It also updates the status\n  variables that reflect the active context values. This action\n  requires the CONNECTION_ADMIN privilege. For additional information\n  about reconfiguring the TLS context, including which system and\n  status variables are context-related, see\n  https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.h\n  tml#using-encrypted-connections-server-side-runtime-configuration.\n\n  By default, the statement reloads the TLS context for the main\n  connection interface. If the FOR CHANNEL clause (available as of\n  MySQL 8.0.21) is given, the statement reloads the TLS context for the\n  named channel: mysql_main for the main connection interface,\n  mysql_admin for the administrative connection interface. For\n  information about the different interfaces, see\n  https://dev.mysql.com/doc/refman/8.0/en/connection-interfaces.html.\n  The updated TLS context properties are exposed in the Performance\n  Schema tls_channel_status table. See\n  https://dev.mysql.com/doc/refman/8.0/en/performance-schema-tls-channe\n  l-status-table.html.\n\n  Updating the TLS context for the main interface may also affect the\n  administrative interface because unless some nondefault TLS value is\n  configured for that interface, it uses the same TLS context as the\n  main interface.\n\n  *Note*:\n\n  When you reload the TLS context, OpenSSL reloads the file containing\n  the CRL (certificate revocation list) as part of the process. If the\n  CRL file is large, the server allocates a large chunk of memory (ten\n  times the file size), which is doubled while the new instance is\n  being loaded and the old one has not yet been released. The process\n  resident memory is not immediately reduced after a large allocation\n  is freed, so if you issue the ALTER INSTANCE RELOAD TLS statement\n  repeatedly with a large CRL file, the process resident memory usage\n  may grow as a result of this.\n\n  By default, the RELOAD TLS action rolls back with an error and has no\n  effect if the configuration values do not permit creation of the new\n  TLS context. The previous context values continue to be used for new\n  connections. If the optional NO ROLLBACK ON ERROR clause is given and\n  the new context cannot be created, rollback does not occur. Instead,\n  a warning is generated and encryption is disabled for new connections\n  on the interface to which the statement applies.\n\n  ALTER INSTANCE RELOAD TLS statements are not written to the binary\n  log (and thus are not replicated). TLS configuration is local and\n  depends on local files not necessarily present on all servers\n  involved.\n\no ALTER INSTANCE RELOAD KEYRING\n\n  If a keyring component is installed, this action tells the component\n  to re-read its configuration file and reinitialize any keyring\n  in-memory data. If you modify the component configuration at runtime,\n  the new configuration does not take effect until you perform this\n  action. Keyring reloading requires the ENCRYPTION_KEY_ADMIN\n  privilege. This action was added in MySQL 8.0.24.\n\n  This action enables reconfiguring only the currently installed\n  keyring component. It does not enable changing which component is\n  installed. For example, if you change the configuration for the\n  installed keyring component, ALTER INSTANCE RELOAD KEYRING causes the\n  new configuration to take effect. On the other hand, if you change\n  the keyring component named in the server manifest file, ALTER\n  INSTANCE RELOAD KEYRING has no effect and the current component\n  remains installed.\n\n  ALTER INSTANCE RELOAD KEYRING statements are not written to the\n  binary log (and thus are not replicated).\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-instance.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-instance.html'),
(507, 'ALTER LOGFILE GROUP', 40, 'Syntax:\nALTER LOGFILE GROUP logfile_group\n    ADD UNDOFILE \'file_name\'\n    [INITIAL_SIZE [=] size]\n    [WAIT]\n    ENGINE [=] engine_name\n\nThis statement adds an UNDO file named \'file_name\' to an existing log\nfile group logfile_group. An ALTER LOGFILE GROUP statement has one and\nonly one ADD UNDOFILE clause. No DROP UNDOFILE clause is currently\nsupported.\n\n*Note*:\n\nAll NDB Cluster Disk Data objects share the same namespace. This means\nthat each Disk Data object must be uniquely named (and not merely each\nDisk Data object of a given type). For example, you cannot have a\ntablespace and an undo log file with the same name, or an undo log file\nand a data file with the same name.\n\nThe optional INITIAL_SIZE parameter sets the UNDO file\'s initial size\nin bytes; if not specified, the initial size defaults to 134217728 (128\nMB). You may optionally follow size with a one-letter abbreviation for\nan order of magnitude, similar to those used in my.cnf. Generally, this\nis one of the letters M (megabytes) or G (gigabytes). (Bug #13116514,\nBug #16104705, Bug #62858)\n\nOn 32-bit systems, the maximum supported value for INITIAL_SIZE is\n4294967296 (4 GB). (Bug #29186)\n\nThe minimum allowed value for INITIAL_SIZE is 1048576 (1 MB). (Bug\n#29574)\n\n*Note*:\n\nWAIT is parsed but otherwise ignored. This keyword currently has no\neffect, and is intended for future expansion.\n\nThe ENGINE parameter (required) determines the storage engine which is\nused by this log file group, with engine_name being the name of the\nstorage engine. Currently, the only accepted values for engine_name are\n\"NDBCLUSTER\" and \"NDB\". The two values are equivalent.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-logfile-group.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-logfile-group.html'),
(508, 'ALTER PROCEDURE', 40, 'Syntax:\nALTER PROCEDURE proc_name [characteristic ...]\n\ncharacteristic: {\n    COMMENT \'string\'\n  | LANGUAGE SQL\n  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }\n  | SQL SECURITY { DEFINER | INVOKER }\n}\n\nThis statement can be used to change the characteristics of a stored\nprocedure. More than one change may be specified in an ALTER PROCEDURE\nstatement. However, you cannot change the parameters or body of a\nstored procedure using this statement; to make such changes, you must\ndrop and re-create the procedure using DROP PROCEDURE and CREATE\nPROCEDURE.\n\nYou must have the ALTER ROUTINE privilege for the procedure. By\ndefault, that privilege is granted automatically to the procedure\ncreator. This behavior can be changed by disabling the\nautomatic_sp_privileges system variable. See\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-routines-privileges.html\n.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-procedure.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-procedure.html'),
(509, 'ALTER SERVER', 40, 'Syntax:\nALTER SERVER  server_name\n    OPTIONS (option [, option] ...)\n\nAlters the server information for server_name, adjusting any of the\noptions permitted in the CREATE SERVER statement. The corresponding\nfields in the mysql.servers table are updated accordingly. This\nstatement requires the SUPER privilege.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-server.html\n\n', 'ALTER SERVER s OPTIONS (USER \'sally\');\n', 'https://dev.mysql.com/doc/refman/8.0/en/alter-server.html'),
(510, 'ALTER TABLE', 40, 'Syntax:\nALTER TABLE tbl_name\n    [alter_option [, alter_option] ...]\n    [partition_options]\n\nalter_option: {\n    table_options\n  | ADD [COLUMN] col_name column_definition\n        [FIRST | AFTER col_name]\n  | ADD [COLUMN] (col_name column_definition,...)\n  | ADD {INDEX | KEY} [index_name]\n        [index_type] (key_part,...) [index_option] ...\n  | ADD {FULLTEXT | SPATIAL} [INDEX | KEY] [index_name]\n        (key_part,...) [index_option] ...\n  | ADD [CONSTRAINT [symbol]] PRIMARY KEY\n        [index_type] (key_part,...)\n        [index_option] ...\n  | ADD [CONSTRAINT [symbol]] UNIQUE [INDEX | KEY]\n        [index_name] [index_type] (key_part,...)\n        [index_option] ...\n  | ADD [CONSTRAINT [symbol]] FOREIGN KEY\n        [index_name] (col_name,...)\n        reference_definition\n  | ADD [CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED]\n  | DROP {CHECK | CONSTRAINT} symbol\n  | ALTER {CHECK | CONSTRAINT} symbol [NOT] ENFORCED\n  | ALGORITHM [=] {DEFAULT | INSTANT | INPLACE | COPY}\n  | ALTER [COLUMN] col_name {\n        SET DEFAULT {literal | (expr)}\n      | SET {VISIBLE | INVISIBLE}\n      | DROP DEFAULT\n    }\n  | ALTER INDEX index_name {VISIBLE | INVISIBLE}\n  | CHANGE [COLUMN] old_col_name new_col_name column_definition\n        [FIRST | AFTER col_name]\n  | [DEFAULT] CHARACTER SET [=] charset_name [COLLATE [=] collation_name]\n  | CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]\n  | {DISABLE | ENABLE} KEYS\n  | {DISCARD | IMPORT} TABLESPACE\n  | DROP [COLUMN] col_name\n  | DROP {INDEX | KEY} index_name\n  | DROP PRIMARY KEY\n  | DROP FOREIGN KEY fk_symbol\n  | FORCE\n  | LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}\n  | MODIFY [COLUMN] col_name column_definition\n        [FIRST | AFTER col_name]\n  | ORDER BY col_name [, col_name] ...\n  | RENAME COLUMN old_col_name TO new_col_name\n  | RENAME {INDEX | KEY} old_index_name TO new_index_name\n  | RENAME [TO | AS] new_tbl_name\n  | {WITHOUT | WITH} VALIDATION\n}\n\npartition_options:\n    partition_option [partition_option] ...\n\npartition_option: {\n    ADD PARTITION (partition_definition)\n  | DROP PARTITION partition_names\n  | DISCARD PARTITION {partition_names | ALL} TABLESPACE\n  | IMPORT PARTITION {partition_names | ALL} TABLESPACE\n  | TRUNCATE PARTITION {partition_names | ALL}\n  | COALESCE PARTITION number\n  | REORGANIZE PARTITION partition_names INTO (partition_definitions)\n  | EXCHANGE PARTITION partition_name WITH TABLE tbl_name [{WITH | WITHOUT} VALIDATION]\n  | ANALYZE PARTITION {partition_names | ALL}\n  | CHECK PARTITION {partition_names | ALL}\n  | OPTIMIZE PARTITION {partition_names | ALL}\n  | REBUILD PARTITION {partition_names | ALL}\n  | REPAIR PARTITION {partition_names | ALL}\n  | REMOVE PARTITIONING\n}\n\nkey_part: {col_name [(length)] | (expr)} [ASC | DESC]\n\nindex_type:\n    USING {BTREE | HASH}\n\nindex_option: {\n    KEY_BLOCK_SIZE [=] value\n  | index_type\n  | WITH PARSER parser_name\n  | COMMENT \'string\'\n  | {VISIBLE | INVISIBLE}\n}\n\ntable_options:\n    table_option [[,] table_option] ...\n\ntable_option: {\n    AUTOEXTEND_SIZE [=] value\n  | AUTO_INCREMENT [=] value\n  | AVG_ROW_LENGTH [=] value\n  | [DEFAULT] CHARACTER SET [=] charset_name\n  | CHECKSUM [=] {0 | 1}\n  | [DEFAULT] COLLATE [=] collation_name\n  | COMMENT [=] \'string\'\n  | COMPRESSION [=] {\'ZLIB\' | \'LZ4\' | \'NONE\'}\n  | CONNECTION [=] \'connect_string\'\n  | {DATA | INDEX} DIRECTORY [=] \'absolute path to directory\'\n  | DELAY_KEY_WRITE [=] {0 | 1}\n  | ENCRYPTION [=] {\'Y\' | \'N\'}\n  | ENGINE [=] engine_name\n  | ENGINE_ATTRIBUTE [=] \'string\'\n  | INSERT_METHOD [=] { NO | FIRST | LAST }\n  | KEY_BLOCK_SIZE [=] value\n  | MAX_ROWS [=] value\n  | MIN_ROWS [=] value\n  | PACK_KEYS [=] {0 | 1 | DEFAULT}\n  | PASSWORD [=] \'string\'\n  | ROW_FORMAT [=] {DEFAULT | DYNAMIC | FIXED | COMPRESSED | REDUNDANT | COMPACT}\n  | SECONDARY_ENGINE_ATTRIBUTE [=] \'string\'\n  | STATS_AUTO_RECALC [=] {DEFAULT | 0 | 1}\n  | STATS_PERSISTENT [=] {DEFAULT | 0 | 1}\n  | STATS_SAMPLE_PAGES [=] value\n  | TABLESPACE tablespace_name [STORAGE {DISK | MEMORY}]\n  | UNION [=] (tbl_name[,tbl_name]...)\n}\n\npartition_options:\n    (see CREATE TABLE options)\n\nALTER TABLE changes the structure of a table. For example, you can add\nor delete columns, create or destroy indexes, change the type of\nexisting columns, or rename columns or the table itself. You can also\nchange characteristics such as the storage engine used for the table or\nthe table comment.\n\no To use ALTER TABLE, you need ALTER, CREATE, and INSERT privileges for\n  the table. Renaming a table requires ALTER and DROP on the old table,\n  ALTER, CREATE, and INSERT on the new table.\n\no Following the table name, specify the alterations to be made. If none\n  are given, ALTER TABLE does nothing.\n\no The syntax for many of the permissible alterations is similar to\n  clauses of the CREATE TABLE statement. column_definition clauses use\n  the same syntax for ADD and CHANGE as for CREATE TABLE. For more\n  information, see [HELP CREATE TABLE].\n\no The word COLUMN is optional and can be omitted, except for RENAME\n  COLUMN (to distinguish a column-renaming operation from the RENAME\n  table-renaming operation).\n\no Multiple ADD, ALTER, DROP, and CHANGE clauses are permitted in a\n  single ALTER TABLE statement, separated by commas. This is a MySQL\n  extension to standard SQL, which permits only one of each clause per\n  ALTER TABLE statement. For example, to drop multiple columns in a\n  single statement, do this:\n\nALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;\n\no If a storage engine does not support an attempted ALTER TABLE\n  operation, a warning may result. Such warnings can be displayed with\n  SHOW WARNINGS. See [HELP SHOW WARNINGS]. For information on\n  troubleshooting ALTER TABLE, see\n  https://dev.mysql.com/doc/refman/8.0/en/alter-table-problems.html.\n\no For information about generated columns, see\n  https://dev.mysql.com/doc/refman/8.0/en/alter-table-generated-columns\n  .html.\n\no For usage examples, see\n  https://dev.mysql.com/doc/refman/8.0/en/alter-table-examples.html.\n\no InnoDB in MySQL 8.0.17 and later supports addition of multi-valued\n  indexes on JSON columns using a key_part specification can take the\n  form (CAST json_path AS type ARRAY). See\n  https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-inde\n  x-multi-valued, for detailed information regarding multi-valued index\n  creation and usage of, as well as restrictions and limitations on\n  multi-valued indexes.\n\no With the mysql_info()\n  (https://dev.mysql.com/doc/c-api/8.0/en/mysql-info.html) C API\n  function, you can find out how many rows were copied by ALTER TABLE.\n  See mysql_info()\n  (https://dev.mysql.com/doc/c-api/8.0/en/mysql-info.html).\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-table.html'),
(511, 'ALTER TABLESPACE', 40, 'Syntax:\nALTER [UNDO] TABLESPACE tablespace_name\n  NDB only:\n    {ADD | DROP} DATAFILE \'file_name\'\n    [INITIAL_SIZE [=] size]\n    [WAIT]\n  InnoDB and NDB:\n    [RENAME TO tablespace_name]\n  InnoDB only:\n    [AUTOEXTEND_SIZE [=] \'value\']\n    [SET {ACTIVE | INACTIVE}]\n    [ENCRYPTION [=] {\'Y\' | \'N\'}]\n  InnoDB and NDB:\n    [ENGINE [=] engine_name]\n  Reserved for future use:\n    [ENGINE_ATTRIBUTE [=] \'string\']\n\nThis statement is used with NDB and InnoDB tablespaces. It can be used\nto add a new data file to, or to drop a data file from an NDB\ntablespace. It can also be used to rename an NDB Cluster Disk Data\ntablespace, rename an InnoDB general tablespace, encrypt an InnoDB\ngeneral tablespace, or mark an InnoDB undo tablespace as active or\ninactive.\n\nThe UNDO keyword, introduced in MySQL 8.0.14, is used with the SET\n{ACTIVE | INACTIVE} clause to mark an InnoDB undo tablespace as active\nor inactive. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html.\n\nThe ADD DATAFILE variant enables you to specify an initial size for an\nNDB Disk Data tablespace using an INITIAL_SIZE clause, where size is\nmeasured in bytes; the default value is 134217728 (128 MB). You may\noptionally follow size with a one-letter abbreviation for an order of\nmagnitude, similar to those used in my.cnf. Generally, this is one of\nthe letters M (megabytes) or G (gigabytes).\n\nOn 32-bit systems, the maximum supported value for INITIAL_SIZE is\n4294967296 (4 GB). (Bug #29186)\n\nINITIAL_SIZE is rounded, explicitly, as for CREATE TABLESPACE.\n\nOnce a data file has been created, its size cannot be changed; however,\nyou can add more data files to an NDB tablespace using additional ALTER\nTABLESPACE ... ADD DATAFILE statements.\n\nWhen ALTER TABLESPACE ... ADD DATAFILE is used with ENGINE = NDB, a\ndata file is created on each Cluster data node, but only one row is\ngenerated in the Information Schema FILES table. See the description of\nthis table, as well as\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-objects\n.html, for more information. ADD DATAFILE is not supported with InnoDB\ntablespaces.\n\nUsing DROP DATAFILE with ALTER TABLESPACE drops the data file\n\'file_name\' from an NDB tablespace. You cannot drop a data file from a\ntablespace which is in use by any table; in other words, the data file\nmust be empty (no extents used). See\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-objects\n.html. In addition, any data file to be dropped must previously have\nbeen added to the tablespace with CREATE TABLESPACE or ALTER\nTABLESPACE. DROP DATAFILE is not supported with InnoDB tablespaces.\n\nWAIT is parsed but otherwise ignored. It is intended for future\nexpansion.\n\nThe ENGINE clause, which specifies the storage engine used by the\ntablespace, is deprecated; expect it to be removed in a future release.\nThe tablespace storage engine is known by the data dictionary, making\nthe ENGINE clause obsolete. If the storage engine is specified, it must\nmatch the tablespace storage engine defined in the data dictionary. The\nonly values for engine_name compatible with NDB tablespaces are NDB and\nNDBCLUSTER.\n\nRENAME TO operations are implicitly performed in autocommit mode,\nregardless of the autocommit setting.\n\nA RENAME TO operation cannot be performed while LOCK TABLES or FLUSH\nTABLES WITH READ LOCK is in effect for tables that reside in the\ntablespace.\n\nExclusive metadata locks are taken on tables that reside in a general\ntablespace while the tablespace is renamed, which prevents concurrent\nDDL. Concurrent DML is supported.\n\nThe CREATE TABLESPACE privilege is required to rename an InnoDB general\ntablespace.\n\nThe AUTOEXTEND_SIZE option defines the amount by which InnoDB extends\nthe size of a tablespace when it becomes full. Introduced in MySQL\n8.0.23. The setting must be a multiple of 4MB. The default setting is\n0, which causes the tablespace to be extended according to the implicit\ndefault behavior. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-autoextend-si\nze.html.\n\nThe ENCRYPTION clause enables or disables page-level data encryption\nfor an InnoDB general tablespace or the mysql system tablespace.\nEncryption support for general tablespaces was introduced in MySQL\n8.0.13. Encryption support for the mysql system tablespace was\nintroduced in MySQL 8.0.16.\n\nA keyring plugin must be installed and configured before encryption can\nbe enabled.\n\nAs of MySQL 8.0.16, if the table_encryption_privilege_check variable is\nenabled, the TABLE_ENCRYPTION_ADMIN privilege is required to alter a\ngeneral tablespace with an ENCRYPTION clause setting that differs from\nthe default_table_encryption setting.\n\nEnabling encryption for a general tablespace fails if any table in the\ntablespace belongs to a schema defined with DEFAULT ENCRYPTION=\'N\'.\nSimilarly, disabling encryption fails if any table in the general\ntablespace belongs to a schema defined with DEFAULT ENCRYPTION=\'Y\'. The\nDEFAULT ENCRYPTION schema option was introduced in MySQL 8.0.16.\n\nIf an ALTER TABLESPACE statement executed on a general tablespace does\nnot include an ENCRYPTION clause, the tablespace retains its current\nencryption status, regardless of the default_table_encryption setting.\n\nWhen a general tablespace or the mysql system tablespace is encrypted,\nall tables residing in the tablespace are encrypted. Likewise, a table\ncreated in an encrypted tablespace is encrypted.\n\nThe INPLACE algorithm is used when altering the ENCRYPTION attribute of\na general tablespace or the mysql system tablespace. The INPLACE\nalgorithm permits concurrent DML on tables that reside in the\ntablespace. Concurrent DDL is blocked.\n\nFor more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html.\n\nThe ENGINE_ATTRIBUTE option (available as of MySQL 8.0.21) is used to\nspecify tablespace attributes for primary storage engines. The option\nis reserved for future use.\n\nPermitted values are a string literal containing a valid JSON document\nor an empty string (\'\'). Invalid JSON is rejected.\n\nALTER TABLESPACE ts1 ENGINE_ATTRIBUTE=\'{\"key\":\"value\"}\';\n\nENGINE_ATTRIBUTE values can be repeated without error. In this case,\nthe last specified value is used.\n\nENGINE_ATTRIBUTE values are not checked by the server, nor are they\ncleared when the table\'s storage engine is changed.\n\nIt is not permitted to alter an individual element of a JSON attribute\nvalue. You can only add or replace an attribute.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-tablespace.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-tablespace.html'),
(512, 'ALTER VIEW', 40, 'Syntax:\nALTER\n    [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]\n    [DEFINER = user]\n    [SQL SECURITY { DEFINER | INVOKER }]\n    VIEW view_name [(column_list)]\n    AS select_statement\n    [WITH [CASCADED | LOCAL] CHECK OPTION]\n\nThis statement changes the definition of a view, which must exist. The\nsyntax is similar to that for CREATE VIEW see [HELP CREATE VIEW]). This\nstatement requires the CREATE VIEW and DROP privileges for the view,\nand some privilege for each column referred to in the SELECT statement.\nALTER VIEW is permitted only to the definer or users with the\nSET_USER_ID privilege (or the deprecated SUPER privilege).\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/alter-view.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/alter-view.html'),
(513, 'CREATE DATABASE', 40, 'Syntax:\nCREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name\n    [create_option] ...\n\ncreate_option: [DEFAULT] {\n    CHARACTER SET [=] charset_name\n  | COLLATE [=] collation_name\n  | ENCRYPTION [=] {\'Y\' | \'N\'}\n}\n\nCREATE DATABASE creates a database with the given name. To use this\nstatement, you need the CREATE privilege for the database. CREATE\nSCHEMA is a synonym for CREATE DATABASE.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-database.html'),
(514, 'CREATE SCHEMA', 40, 'Syntax:\nCREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name\n    [create_option] ...\n\ncreate_option: [DEFAULT] {\n    CHARACTER SET [=] charset_name\n  | COLLATE [=] collation_name\n  | ENCRYPTION [=] {\'Y\' | \'N\'}\n}\n\nCREATE DATABASE creates a database with the given name. To use this\nstatement, you need the CREATE privilege for the database. CREATE\nSCHEMA is a synonym for CREATE DATABASE.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-database.html'),
(515, 'CREATE EVENT', 40, 'Syntax:\nCREATE\n    [DEFINER = user]\n    EVENT\n    [IF NOT EXISTS]\n    event_name\n    ON SCHEDULE schedule\n    [ON COMPLETION [NOT] PRESERVE]\n    [ENABLE | DISABLE | DISABLE ON SLAVE]\n    [COMMENT \'string\']\n    DO event_body;\n\nschedule: {\n    AT timestamp [+ INTERVAL interval] ...\n  | EVERY interval\n    [STARTS timestamp [+ INTERVAL interval] ...]\n    [ENDS timestamp [+ INTERVAL interval] ...]\n}\n\ninterval:\n    quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE |\n              WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE |\n              DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND}\n\nThis statement creates and schedules a new event. The event does not\nrun unless the Event Scheduler is enabled. For information about\nchecking Event Scheduler status and enabling it if necessary, see\nhttps://dev.mysql.com/doc/refman/8.0/en/events-configuration.html.\n\nCREATE EVENT requires the EVENT privilege for the schema in which the\nevent is to be created. If the DEFINER clause is present, the\nprivileges required depend on the user value, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\n\nThe minimum requirements for a valid CREATE EVENT statement are as\nfollows:\n\no The keywords CREATE EVENT plus an event name, which uniquely\n  identifies the event in a database schema.\n\no An ON SCHEDULE clause, which determines when and how often the event\n  executes.\n\no A DO clause, which contains the SQL statement to be executed by an\n  event.\n\nThis is an example of a minimal CREATE EVENT statement:\n\nCREATE EVENT myevent\n    ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR\n    DO\n      UPDATE myschema.mytable SET mycol = mycol + 1;\n\nThe previous statement creates an event named myevent. This event\nexecutes once---one hour following its creation---by running an SQL\nstatement that increments the value of the myschema.mytable table\'s\nmycol column by 1.\n\nThe event_name must be a valid MySQL identifier with a maximum length\nof 64 characters. Event names are not case-sensitive, so you cannot\nhave two events named myevent and MyEvent in the same schema. In\ngeneral, the rules governing event names are the same as those for\nnames of stored routines. See\nhttps://dev.mysql.com/doc/refman/8.0/en/identifiers.html.\n\nAn event is associated with a schema. If no schema is indicated as part\nof event_name, the default (current) schema is assumed. To create an\nevent in a specific schema, qualify the event name with a schema using\nschema_name.event_name syntax.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-event.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-event.html'),
(516, 'CREATE INDEX', 40, 'Syntax:\nCREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX index_name\n    [index_type]\n    ON tbl_name (key_part,...)\n    [index_option]\n    [algorithm_option | lock_option] ...\n\nkey_part: {col_name [(length)] | (expr)} [ASC | DESC]\n\nindex_option: {\n    KEY_BLOCK_SIZE [=] value\n  | index_type\n  | WITH PARSER parser_name\n  | COMMENT \'string\'\n  | {VISIBLE | INVISIBLE}\n  | ENGINE_ATTRIBUTE [=] \'string\'\n  | SECONDARY_ENGINE_ATTRIBUTE [=] \'string\'\n}\n\nindex_type:\n    USING {BTREE | HASH}\n\nalgorithm_option:\n    ALGORITHM [=] {DEFAULT | INPLACE | COPY}\n\nlock_option:\n    LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}\n\nNormally, you create all indexes on a table at the time the table\nitself is created with CREATE TABLE. See [HELP CREATE TABLE]. This\nguideline is especially important for InnoDB tables, where the primary\nkey determines the physical layout of rows in the data file. CREATE\nINDEX enables you to add indexes to existing tables.\n\nCREATE INDEX is mapped to an ALTER TABLE statement to create indexes.\nSee [HELP ALTER TABLE]. CREATE INDEX cannot be used to create a PRIMARY\nKEY; use ALTER TABLE instead. For more information about indexes, see\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-index.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-index.html'),
(517, 'CREATE LOGFILE GROUP', 40, 'Syntax:\nCREATE LOGFILE GROUP logfile_group\n    ADD UNDOFILE \'undo_file\'\n    [INITIAL_SIZE [=] initial_size]\n    [UNDO_BUFFER_SIZE [=] undo_buffer_size]\n    [REDO_BUFFER_SIZE [=] redo_buffer_size]\n    [NODEGROUP [=] nodegroup_id]\n    [WAIT]\n    [COMMENT [=] \'string\']\n    ENGINE [=] engine_name\n\nThis statement creates a new log file group named logfile_group having\na single UNDO file named \'undo_file\'. A CREATE LOGFILE GROUP statement\nhas one and only one ADD UNDOFILE clause. For rules covering the naming\nof log file groups, see\nhttps://dev.mysql.com/doc/refman/8.0/en/identifiers.html.\n\n*Note*:\n\nAll NDB Cluster Disk Data objects share the same namespace. This means\nthat each Disk Data object must be uniquely named (and not merely each\nDisk Data object of a given type). For example, you cannot have a\ntablespace and a log file group with the same name, or a tablespace and\na data file with the same name.\n\nThere can be only one log file group per NDB Cluster instance at any\ngiven time.\n\nThe optional INITIAL_SIZE parameter sets the UNDO file\'s initial size;\nif not specified, it defaults to 128M (128 megabytes). The optional\nUNDO_BUFFER_SIZE parameter sets the size used by the UNDO buffer for\nthe log file group; The default value for UNDO_BUFFER_SIZE is 8M (eight\nmegabytes); this value cannot exceed the amount of system memory\navailable. Both of these parameters are specified in bytes. You may\noptionally follow either or both of these with a one-letter\nabbreviation for an order of magnitude, similar to those used in\nmy.cnf. Generally, this is one of the letters M (for megabytes) or G\n(for gigabytes).\n\nMemory used for UNDO_BUFFER_SIZE comes from the global pool whose size\nis determined by the value of the SharedGlobalMemory data node\nconfiguration parameter. This includes any default value implied for\nthis option by the setting of the InitialLogFileGroup data node\nconfiguration parameter.\n\nThe maximum permitted for UNDO_BUFFER_SIZE is 629145600 (600 MB).\n\nOn 32-bit systems, the maximum supported value for INITIAL_SIZE is\n4294967296 (4 GB). (Bug #29186)\n\nThe minimum allowed value for INITIAL_SIZE is 1048576 (1 MB).\n\nThe ENGINE option determines the storage engine to be used by this log\nfile group, with engine_name being the name of the storage engine. In\nMySQL 8.0, this must be NDB (or NDBCLUSTER). If ENGINE is not set,\nMySQL tries to use the engine specified by the default_storage_engine\nserver system variable (formerly storage_engine). In any case, if the\nengine is not specified as NDB or NDBCLUSTER, the CREATE LOGFILE GROUP\nstatement appears to succeed but actually fails to create the log file\ngroup, as shown here:\n\nmysql> CREATE LOGFILE GROUP lg1\n    ->     ADD UNDOFILE \'undo.dat\' INITIAL_SIZE = 10M;\nQuery OK, 0 rows affected, 1 warning (0.00 sec)\n\nmysql> SHOW WARNINGS;\n+-------+------+------------------------------------------------------------------------------------------------+\n| Level | Code | Message                                                                                        |\n+-------+------+------------------------------------------------------------------------------------------------+\n| Error | 1478 | Table storage engine \'InnoDB\' does not support the create option \'TABLESPACE or LOGFILE GROUP\' |\n+-------+------+------------------------------------------------------------------------------------------------+\n1 row in set (0.00 sec)\n\nmysql> DROP LOGFILE GROUP lg1 ENGINE = NDB;\nERROR 1529 (HY000): Failed to drop LOGFILE GROUP\n\nmysql> CREATE LOGFILE GROUP lg1\n    ->     ADD UNDOFILE \'undo.dat\' INITIAL_SIZE = 10M\n    ->     ENGINE = NDB;\nQuery OK, 0 rows affected (2.97 sec)\n\nThe fact that the CREATE LOGFILE GROUP statement does not actually\nreturn an error when a non-NDB storage engine is named, but rather\nappears to succeed, is a known issue which we hope to address in a\nfuture release of NDB Cluster.\n\nREDO_BUFFER_SIZE, NODEGROUP, WAIT, and COMMENT are parsed but ignored,\nand so have no effect in MySQL 8.0. These options are intended for\nfuture expansion.\n\nWhen used with ENGINE [=] NDB, a log file group and associated UNDO log\nfile are created on each Cluster data node. You can verify that the\nUNDO files were created and obtain information about them by querying\nthe Information Schema FILES table. For example:\n\nmysql> SELECT LOGFILE_GROUP_NAME, LOGFILE_GROUP_NUMBER, EXTRA\n    -> FROM INFORMATION_SCHEMA.FILES\n    -> WHERE FILE_NAME = \'undo_10.dat\';\n+--------------------+----------------------+----------------+\n| LOGFILE_GROUP_NAME | LOGFILE_GROUP_NUMBER | EXTRA          |\n+--------------------+----------------------+----------------+\n| lg_3               |                   11 | CLUSTER_NODE=3 |\n| lg_3               |                   11 | CLUSTER_NODE=4 |\n+--------------------+----------------------+----------------+\n2 rows in set (0.06 sec)\n\nCREATE LOGFILE GROUP is useful only with Disk Data storage for NDB\nCluster. See\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-logfile-group.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-logfile-group.html'),
(518, 'CREATE PROCEDURE', 40, 'Syntax:\nCREATE\n    [DEFINER = user]\n    PROCEDURE [IF NOT EXISTS] sp_name ([proc_parameter[,...]])\n    [characteristic ...] routine_body\n\nCREATE\n    [DEFINER = user]\n    FUNCTION [IF NOT EXISTS] sp_name ([func_parameter[,...]])\n    RETURNS type\n    [characteristic ...] routine_body\n\nproc_parameter:\n    [ IN | OUT | INOUT ] param_name type\n\nfunc_parameter:\n    param_name type\n\ntype:\n    Any valid MySQL data type\n\ncharacteristic: {\n    COMMENT \'string\'\n  | LANGUAGE SQL\n  | [NOT] DETERMINISTIC\n  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }\n  | SQL SECURITY { DEFINER | INVOKER }\n}\n\nroutine_body:\n    Valid SQL routine statement\n\nThese statements are used to create a stored routine (a stored\nprocedure or function). That is, the specified routine becomes known to\nthe server. By default, a stored routine is associated with the default\ndatabase. To associate the routine explicitly with a given database,\nspecify the name as db_name.sp_name when you create it.\n\nThe CREATE FUNCTION statement is also used in MySQL to support loadable\nfunctions. See [HELP CREATE FUNCTION loadable function]. A loadable\nfunction can be regarded as an external stored function. Stored\nfunctions share their namespace with loadable functions. See\nhttps://dev.mysql.com/doc/refman/8.0/en/function-resolution.html, for\nthe rules describing how the server interprets references to different\nkinds of functions.\n\nTo invoke a stored procedure, use the CALL statement (see [HELP CALL]).\nTo invoke a stored function, refer to it in an expression. The function\nreturns a value during expression evaluation.\n\nCREATE PROCEDURE and CREATE FUNCTION require the CREATE ROUTINE\nprivilege. If the DEFINER clause is present, the privileges required\ndepend on the user value, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\nIf binary logging is enabled, CREATE FUNCTION might require the SUPER\nprivilege, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-logging.html.\n\nBy default, MySQL automatically grants the ALTER ROUTINE and EXECUTE\nprivileges to the routine creator. This behavior can be changed by\ndisabling the automatic_sp_privileges system variable. See\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-routines-privileges.html\n.\n\nThe DEFINER and SQL SECURITY clauses specify the security context to be\nused when checking access privileges at routine execution time, as\ndescribed later in this section.\n\nIf the routine name is the same as the name of a built-in SQL function,\na syntax error occurs unless you use a space between the name and the\nfollowing parenthesis when defining the routine or invoking it later.\nFor this reason, avoid using the names of existing SQL functions for\nyour own stored routines.\n\nThe IGNORE_SPACE SQL mode applies to built-in functions, not to stored\nroutines. It is always permissible to have spaces after a stored\nroutine name, regardless of whether IGNORE_SPACE is enabled.\n\nIF NOT EXISTS prevents an error from occurring if there already exists\na routine with the same name. This option is supported with both CREATE\nFUNCTION and CREATE PROCEDURE beginning with MySQL 8.0.29.\n\nIf a built-in function with the same name already exists, attempting to\ncreate a stored function with CREATE FUNCTION ... IF NOT EXISTS\nsucceeds with a warning indicating that it has the same name as a\nnative function; this is no different than when performing the same\nCREATE FUNCTION statement without specifying IF NOT EXISTS.\n\nIf a loadable function with the same name already exists, attempting to\ncreate a stored function using IF NOT EXISTS succeeds with a warning.\nThis is the same as without specifying IF NOT EXISTS.\n\nSee\nhttps://dev.mysql.com/doc/refman/8.0/en/function-resolution.html#functi\non-name-resolution, for more information.\n\nThe parameter list enclosed within parentheses must always be present.\nIf there are no parameters, an empty parameter list of () should be\nused. Parameter names are not case-sensitive.\n\nEach parameter is an IN parameter by default. To specify otherwise for\na parameter, use the keyword OUT or INOUT before the parameter name.\n\n*Note*:\n\nSpecifying a parameter as IN, OUT, or INOUT is valid only for a\nPROCEDURE. For a FUNCTION, parameters are always regarded as IN\nparameters.\n\nAn IN parameter passes a value into a procedure. The procedure might\nmodify the value, but the modification is not visible to the caller\nwhen the procedure returns. An OUT parameter passes a value from the\nprocedure back to the caller. Its initial value is NULL within the\nprocedure, and its value is visible to the caller when the procedure\nreturns. An INOUT parameter is initialized by the caller, can be\nmodified by the procedure, and any change made by the procedure is\nvisible to the caller when the procedure returns.\n\nFor each OUT or INOUT parameter, pass a user-defined variable in the\nCALL statement that invokes the procedure so that you can obtain its\nvalue when the procedure returns. If you are calling the procedure from\nwithin another stored procedure or function, you can also pass a\nroutine parameter or local routine variable as an OUT or INOUT\nparameter. If you are calling the procedure from within a trigger, you\ncan also pass NEW.col_name as an OUT or INOUT parameter.\n\nFor information about the effect of unhandled conditions on procedure\nparameters, see\nhttps://dev.mysql.com/doc/refman/8.0/en/conditions-and-parameters.html.\n\nRoutine parameters cannot be referenced in statements prepared within\nthe routine; see\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html\n.\n\nThe following example shows a simple stored procedure that, given a\ncountry code, counts the number of cities for that country that appear\nin the city table of the world database. The country code is passed\nusing an IN parameter, and the city count is returned using an OUT\nparameter:\n\nmysql> delimiter //\n\nmysql> CREATE PROCEDURE citycount (IN country CHAR(3), OUT cities INT)\n       BEGIN\n         SELECT COUNT(*) INTO cities FROM world.city\n         WHERE CountryCode = country;\n       END//\nQuery OK, 0 rows affected (0.01 sec)\n\nmysql> delimiter ;\n\nmysql> CALL citycount(\'JPN\', @cities); -- cities in Japan\nQuery OK, 1 row affected (0.00 sec)\n\nmysql> SELECT @cities;\n+---------+\n| @cities |\n+---------+\n|     248 |\n+---------+\n1 row in set (0.00 sec)\n\nmysql> CALL citycount(\'FRA\', @cities); -- cities in France\nQuery OK, 1 row affected (0.00 sec)\n\nmysql> SELECT @cities;\n+---------+\n| @cities |\n+---------+\n|      40 |\n+---------+\n1 row in set (0.00 sec)\n\nThe example uses the mysql client delimiter command to change the\nstatement delimiter from ; to // while the procedure is being defined.\nThis enables the ; delimiter used in the procedure body to be passed\nthrough to the server rather than being interpreted by mysql itself.\nSee\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-defining.html.\n\nThe RETURNS clause may be specified only for a FUNCTION, for which it\nis mandatory. It indicates the return type of the function, and the\nfunction body must contain a RETURN value statement. If the RETURN\nstatement returns a value of a different type, the value is coerced to\nthe proper type. For example, if a function specifies an ENUM or SET\nvalue in the RETURNS clause, but the RETURN statement returns an\ninteger, the value returned from the function is the string for the\ncorresponding ENUM member of set of SET members.\n\nThe following example function takes a parameter, performs an operation\nusing an SQL function, and returns the result. In this case, it is\nunnecessary to use delimiter because the function definition contains\nno internal ; statement delimiters:\n\nmysql> CREATE FUNCTION hello (s CHAR(20))\nmysql> RETURNS CHAR(50) DETERMINISTIC\n       RETURN CONCAT(\'Hello, \',s,\'!\');\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT hello(\'world\');\n+----------------+\n| hello(\'world\') |\n+----------------+\n| Hello, world!  |\n+----------------+\n1 row in set (0.00 sec)\n\nParameter types and function return types can be declared to use any\nvalid data type. The COLLATE attribute can be used if preceded by a\nCHARACTER SET specification.\n\nThe routine_body consists of a valid SQL routine statement. This can be\na simple statement such as SELECT or INSERT, or a compound statement\nwritten using BEGIN and END. Compound statements can contain\ndeclarations, loops, and other control structure statements. The syntax\nfor these statements is described in\nhttps://dev.mysql.com/doc/refman/8.0/en/sql-compound-statements.html.\nIn practice, stored functions tend to use compound statements, unless\nthe body consists of a single RETURN statement.\n\nMySQL permits routines to contain DDL statements, such as CREATE and\nDROP. MySQL also permits stored procedures (but not stored functions)\nto contain SQL transaction statements such as COMMIT. Stored functions\nmay not contain statements that perform explicit or implicit commit or\nrollback. Support for these statements is not required by the SQL\nstandard, which states that each DBMS vendor may decide whether to\npermit them.\n\nStatements that return a result set can be used within a stored\nprocedure but not within a stored function. This prohibition includes\nSELECT statements that do not have an INTO var_list clause and other\nstatements such as SHOW, EXPLAIN, and CHECK TABLE. For statements that\ncan be determined at function definition time to return a result set, a\nNot allowed to return a result set from a function error occurs\n(ER_SP_NO_RETSET\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_sp_no_retset)). For statements that can be determined only\nat runtime to return a result set, a PROCEDURE %s can\'t return a result\nset in the given context error occurs (ER_SP_BADSELECT\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_sp_badselect)).\n\nUSE statements within stored routines are not permitted. When a routine\nis invoked, an implicit USE db_name is performed (and undone when the\nroutine terminates). The causes the routine to have the given default\ndatabase while it executes. References to objects in databases other\nthan the routine default database should be qualified with the\nappropriate database name.\n\nFor additional information about statements that are not permitted in\nstored routines, see\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html\n.\n\nFor information about invoking stored procedures from within programs\nwritten in a language that has a MySQL interface, see [HELP CALL].\n\nMySQL stores the sql_mode system variable setting in effect when a\nroutine is created or altered, and always executes the routine with\nthis setting in force, regardless of the current server SQL mode when\nthe routine begins executing.\n\nThe switch from the SQL mode of the invoker to that of the routine\noccurs after evaluation of arguments and assignment of the resulting\nvalues to routine parameters. If you define a routine in strict SQL\nmode but invoke it in nonstrict mode, assignment of arguments to\nroutine parameters does not take place in strict mode. If you require\nthat expressions passed to a routine be assigned in strict SQL mode,\nyou should invoke the routine with strict mode in effect.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html'),
(519, 'CREATE FUNCTION', 40, 'Syntax:\nCREATE\n    [DEFINER = user]\n    PROCEDURE [IF NOT EXISTS] sp_name ([proc_parameter[,...]])\n    [characteristic ...] routine_body\n\nCREATE\n    [DEFINER = user]\n    FUNCTION [IF NOT EXISTS] sp_name ([func_parameter[,...]])\n    RETURNS type\n    [characteristic ...] routine_body\n\nproc_parameter:\n    [ IN | OUT | INOUT ] param_name type\n\nfunc_parameter:\n    param_name type\n\ntype:\n    Any valid MySQL data type\n\ncharacteristic: {\n    COMMENT \'string\'\n  | LANGUAGE SQL\n  | [NOT] DETERMINISTIC\n  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }\n  | SQL SECURITY { DEFINER | INVOKER }\n}\n\nroutine_body:\n    Valid SQL routine statement\n\nThese statements are used to create a stored routine (a stored\nprocedure or function). That is, the specified routine becomes known to\nthe server. By default, a stored routine is associated with the default\ndatabase. To associate the routine explicitly with a given database,\nspecify the name as db_name.sp_name when you create it.\n\nThe CREATE FUNCTION statement is also used in MySQL to support loadable\nfunctions. See [HELP CREATE FUNCTION loadable function]. A loadable\nfunction can be regarded as an external stored function. Stored\nfunctions share their namespace with loadable functions. See\nhttps://dev.mysql.com/doc/refman/8.0/en/function-resolution.html, for\nthe rules describing how the server interprets references to different\nkinds of functions.\n\nTo invoke a stored procedure, use the CALL statement (see [HELP CALL]).\nTo invoke a stored function, refer to it in an expression. The function\nreturns a value during expression evaluation.\n\nCREATE PROCEDURE and CREATE FUNCTION require the CREATE ROUTINE\nprivilege. If the DEFINER clause is present, the privileges required\ndepend on the user value, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\nIf binary logging is enabled, CREATE FUNCTION might require the SUPER\nprivilege, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-logging.html.\n\nBy default, MySQL automatically grants the ALTER ROUTINE and EXECUTE\nprivileges to the routine creator. This behavior can be changed by\ndisabling the automatic_sp_privileges system variable. See\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-routines-privileges.html\n.\n\nThe DEFINER and SQL SECURITY clauses specify the security context to be\nused when checking access privileges at routine execution time, as\ndescribed later in this section.\n\nIf the routine name is the same as the name of a built-in SQL function,\na syntax error occurs unless you use a space between the name and the\nfollowing parenthesis when defining the routine or invoking it later.\nFor this reason, avoid using the names of existing SQL functions for\nyour own stored routines.\n\nThe IGNORE_SPACE SQL mode applies to built-in functions, not to stored\nroutines. It is always permissible to have spaces after a stored\nroutine name, regardless of whether IGNORE_SPACE is enabled.\n\nIF NOT EXISTS prevents an error from occurring if there already exists\na routine with the same name. This option is supported with both CREATE\nFUNCTION and CREATE PROCEDURE beginning with MySQL 8.0.29.\n\nIf a built-in function with the same name already exists, attempting to\ncreate a stored function with CREATE FUNCTION ... IF NOT EXISTS\nsucceeds with a warning indicating that it has the same name as a\nnative function; this is no different than when performing the same\nCREATE FUNCTION statement without specifying IF NOT EXISTS.\n\nIf a loadable function with the same name already exists, attempting to\ncreate a stored function using IF NOT EXISTS succeeds with a warning.\nThis is the same as without specifying IF NOT EXISTS.\n\nSee\nhttps://dev.mysql.com/doc/refman/8.0/en/function-resolution.html#functi\non-name-resolution, for more information.\n\nThe parameter list enclosed within parentheses must always be present.\nIf there are no parameters, an empty parameter list of () should be\nused. Parameter names are not case-sensitive.\n\nEach parameter is an IN parameter by default. To specify otherwise for\na parameter, use the keyword OUT or INOUT before the parameter name.\n\n*Note*:\n\nSpecifying a parameter as IN, OUT, or INOUT is valid only for a\nPROCEDURE. For a FUNCTION, parameters are always regarded as IN\nparameters.\n\nAn IN parameter passes a value into a procedure. The procedure might\nmodify the value, but the modification is not visible to the caller\nwhen the procedure returns. An OUT parameter passes a value from the\nprocedure back to the caller. Its initial value is NULL within the\nprocedure, and its value is visible to the caller when the procedure\nreturns. An INOUT parameter is initialized by the caller, can be\nmodified by the procedure, and any change made by the procedure is\nvisible to the caller when the procedure returns.\n\nFor each OUT or INOUT parameter, pass a user-defined variable in the\nCALL statement that invokes the procedure so that you can obtain its\nvalue when the procedure returns. If you are calling the procedure from\nwithin another stored procedure or function, you can also pass a\nroutine parameter or local routine variable as an OUT or INOUT\nparameter. If you are calling the procedure from within a trigger, you\ncan also pass NEW.col_name as an OUT or INOUT parameter.\n\nFor information about the effect of unhandled conditions on procedure\nparameters, see\nhttps://dev.mysql.com/doc/refman/8.0/en/conditions-and-parameters.html.\n\nRoutine parameters cannot be referenced in statements prepared within\nthe routine; see\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html\n.\n\nThe following example shows a simple stored procedure that, given a\ncountry code, counts the number of cities for that country that appear\nin the city table of the world database. The country code is passed\nusing an IN parameter, and the city count is returned using an OUT\nparameter:\n\nmysql> delimiter //\n\nmysql> CREATE PROCEDURE citycount (IN country CHAR(3), OUT cities INT)\n       BEGIN\n         SELECT COUNT(*) INTO cities FROM world.city\n         WHERE CountryCode = country;\n       END//\nQuery OK, 0 rows affected (0.01 sec)\n\nmysql> delimiter ;\n\nmysql> CALL citycount(\'JPN\', @cities); -- cities in Japan\nQuery OK, 1 row affected (0.00 sec)\n\nmysql> SELECT @cities;\n+---------+\n| @cities |\n+---------+\n|     248 |\n+---------+\n1 row in set (0.00 sec)\n\nmysql> CALL citycount(\'FRA\', @cities); -- cities in France\nQuery OK, 1 row affected (0.00 sec)\n\nmysql> SELECT @cities;\n+---------+\n| @cities |\n+---------+\n|      40 |\n+---------+\n1 row in set (0.00 sec)\n\nThe example uses the mysql client delimiter command to change the\nstatement delimiter from ; to // while the procedure is being defined.\nThis enables the ; delimiter used in the procedure body to be passed\nthrough to the server rather than being interpreted by mysql itself.\nSee\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-defining.html.\n\nThe RETURNS clause may be specified only for a FUNCTION, for which it\nis mandatory. It indicates the return type of the function, and the\nfunction body must contain a RETURN value statement. If the RETURN\nstatement returns a value of a different type, the value is coerced to\nthe proper type. For example, if a function specifies an ENUM or SET\nvalue in the RETURNS clause, but the RETURN statement returns an\ninteger, the value returned from the function is the string for the\ncorresponding ENUM member of set of SET members.\n\nThe following example function takes a parameter, performs an operation\nusing an SQL function, and returns the result. In this case, it is\nunnecessary to use delimiter because the function definition contains\nno internal ; statement delimiters:\n\nmysql> CREATE FUNCTION hello (s CHAR(20))\nmysql> RETURNS CHAR(50) DETERMINISTIC\n       RETURN CONCAT(\'Hello, \',s,\'!\');\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT hello(\'world\');\n+----------------+\n| hello(\'world\') |\n+----------------+\n| Hello, world!  |\n+----------------+\n1 row in set (0.00 sec)\n\nParameter types and function return types can be declared to use any\nvalid data type. The COLLATE attribute can be used if preceded by a\nCHARACTER SET specification.\n\nThe routine_body consists of a valid SQL routine statement. This can be\na simple statement such as SELECT or INSERT, or a compound statement\nwritten using BEGIN and END. Compound statements can contain\ndeclarations, loops, and other control structure statements. The syntax\nfor these statements is described in\nhttps://dev.mysql.com/doc/refman/8.0/en/sql-compound-statements.html.\nIn practice, stored functions tend to use compound statements, unless\nthe body consists of a single RETURN statement.\n\nMySQL permits routines to contain DDL statements, such as CREATE and\nDROP. MySQL also permits stored procedures (but not stored functions)\nto contain SQL transaction statements such as COMMIT. Stored functions\nmay not contain statements that perform explicit or implicit commit or\nrollback. Support for these statements is not required by the SQL\nstandard, which states that each DBMS vendor may decide whether to\npermit them.\n\nStatements that return a result set can be used within a stored\nprocedure but not within a stored function. This prohibition includes\nSELECT statements that do not have an INTO var_list clause and other\nstatements such as SHOW, EXPLAIN, and CHECK TABLE. For statements that\ncan be determined at function definition time to return a result set, a\nNot allowed to return a result set from a function error occurs\n(ER_SP_NO_RETSET\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_sp_no_retset)). For statements that can be determined only\nat runtime to return a result set, a PROCEDURE %s can\'t return a result\nset in the given context error occurs (ER_SP_BADSELECT\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_sp_badselect)).\n\nUSE statements within stored routines are not permitted. When a routine\nis invoked, an implicit USE db_name is performed (and undone when the\nroutine terminates). The causes the routine to have the given default\ndatabase while it executes. References to objects in databases other\nthan the routine default database should be qualified with the\nappropriate database name.\n\nFor additional information about statements that are not permitted in\nstored routines, see\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-program-restrictions.html\n.\n\nFor information about invoking stored procedures from within programs\nwritten in a language that has a MySQL interface, see [HELP CALL].\n\nMySQL stores the sql_mode system variable setting in effect when a\nroutine is created or altered, and always executes the routine with\nthis setting in force, regardless of the current server SQL mode when\nthe routine begins executing.\n\nThe switch from the SQL mode of the invoker to that of the routine\noccurs after evaluation of arguments and assignment of the resulting\nvalues to routine parameters. If you define a routine in strict SQL\nmode but invoke it in nonstrict mode, assignment of arguments to\nroutine parameters does not take place in strict mode. If you require\nthat expressions passed to a routine be assigned in strict SQL mode,\nyou should invoke the routine with strict mode in effect.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html'),
(520, 'CREATE SERVER', 40, 'Syntax:\nCREATE SERVER server_name\n    FOREIGN DATA WRAPPER wrapper_name\n    OPTIONS (option [, option] ...)\n\noption: {\n    HOST character-literal\n  | DATABASE character-literal\n  | USER character-literal\n  | PASSWORD character-literal\n  | SOCKET character-literal\n  | OWNER character-literal\n  | PORT numeric-literal\n}\n\nThis statement creates the definition of a server for use with the\nFEDERATED storage engine. The CREATE SERVER statement creates a new row\nin the servers table in the mysql database. This statement requires the\nSUPER privilege.\n\nThe server_name should be a unique reference to the server. Server\ndefinitions are global within the scope of the server, it is not\npossible to qualify the server definition to a specific database.\nserver_name has a maximum length of 64 characters (names longer than 64\ncharacters are silently truncated), and is case-insensitive. You may\nspecify the name as a quoted string.\n\nThe wrapper_name is an identifier and may be quoted with single\nquotation marks.\n\nFor each option you must specify either a character literal or numeric\nliteral. Character literals are UTF-8, support a maximum length of 64\ncharacters and default to a blank (empty) string. String literals are\nsilently truncated to 64 characters. Numeric literals must be a number\nbetween 0 and 9999, default value is 0.\n\n*Note*:\n\nThe OWNER option is currently not applied, and has no effect on the\nownership or operation of the server connection that is created.\n\nThe CREATE SERVER statement creates an entry in the mysql.servers table\nthat can later be used with the CREATE TABLE statement when creating a\nFEDERATED table. The options that you specify are used to populate the\ncolumns in the mysql.servers table. The table columns are Server_name,\nHost, Db, Username, Password, Port and Socket.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-server.html\n\n', 'CREATE SERVER s\nFOREIGN DATA WRAPPER mysql\nOPTIONS (USER \'Remote\', HOST \'198.51.100.106\', DATABASE \'test\');\n', 'https://dev.mysql.com/doc/refman/8.0/en/create-server.html'),
(521, 'CREATE SPATIAL REFERENCE SYSTEM', 40, 'Syntax:\nCREATE OR REPLACE SPATIAL REFERENCE SYSTEM\n    srid srs_attribute ...\n\nCREATE SPATIAL REFERENCE SYSTEM\n    [IF NOT EXISTS]\n    srid srs_attribute ...\n\nsrs_attribute: {\n    NAME \'srs_name\'\n  | DEFINITION \'definition\'\n  | ORGANIZATION \'org_name\' IDENTIFIED BY org_id\n  | DESCRIPTION \'description\'\n}\n\nsrid, org_id: 32-bit unsigned integer\n\nThis statement creates a spatial reference system (SRS) definition and\nstores it in the data dictionary. It requires the SUPER privilege. The\nresulting data dictionary entry can be inspected using the\nINFORMATION_SCHEMA ST_SPATIAL_REFERENCE_SYSTEMS table.\n\nSRID values must be unique, so if neither OR REPLACE nor IF NOT EXISTS\nis specified, an error occurs if an SRS definition with the given srid\nvalue already exists.\n\nWith CREATE OR REPLACE syntax, any existing SRS definition with the\nsame SRID value is replaced, unless the SRID value is used by some\ncolumn in an existing table. In that case, an error occurs. For\nexample:\n\nmysql> CREATE OR REPLACE SPATIAL REFERENCE SYSTEM 4326 ...;\nERROR 3716 (SR005): Can\'t modify SRID 4326. There is at\nleast one column depending on it.\n\nTo identify which column or columns use the SRID, use this query,\nreplacing 4326 with the SRID of the definition you are trying to\ncreate:\n\nSELECT * FROM INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS WHERE SRS_ID=4326;\n\nWith CREATE ... IF NOT EXISTS syntax, any existing SRS definition with\nthe same SRID value causes the new definition to be ignored and a\nwarning occurs.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-spatial-reference-system.html\n\n', 'CREATE SPATIAL REFERENCE SYSTEM 4120\nNAME \'Greek\'\nORGANIZATION \'EPSG\' IDENTIFIED BY 4120\nDEFINITION\n  \'GEOGCS[\"Greek\",DATUM[\"Greek\",SPHEROID[\"Bessel 1841\",\n  6377397.155,299.1528128,AUTHORITY[\"EPSG\",\"7004\"]],\n  AUTHORITY[\"EPSG\",\"6120\"]],PRIMEM[\"Greenwich\",0,\n  AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.017453292519943278,\n  AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Lat\",NORTH],AXIS[\"Lon\",EAST],\n  AUTHORITY[\"EPSG\",\"4120\"]]\';\n', 'https://dev.mysql.com/doc/refman/8.0/en/create-spatial-reference-system.html'),
(522, 'CREATE TABLE', 40, 'Syntax:\nCREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name\n    (create_definition,...)\n    [table_options]\n    [partition_options]\n\nCREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name\n    [(create_definition,...)]\n    [table_options]\n    [partition_options]\n    [IGNORE | REPLACE]\n    [AS] query_expression\n\nCREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name\n    { LIKE old_tbl_name | (LIKE old_tbl_name) }\n\ncreate_definition: {\n    col_name column_definition\n  | {INDEX | KEY} [index_name] [index_type] (key_part,...)\n      [index_option] ...\n  | {FULLTEXT | SPATIAL} [INDEX | KEY] [index_name] (key_part,...)\n      [index_option] ...\n  | [CONSTRAINT [symbol]] PRIMARY KEY\n      [index_type] (key_part,...)\n      [index_option] ...\n  | [CONSTRAINT [symbol]] UNIQUE [INDEX | KEY]\n      [index_name] [index_type] (key_part,...)\n      [index_option] ...\n  | [CONSTRAINT [symbol]] FOREIGN KEY\n      [index_name] (col_name,...)\n      reference_definition\n  | check_constraint_definition\n}\n\ncolumn_definition: {\n    data_type [NOT NULL | NULL] [DEFAULT {literal | (expr)} ]\n      [VISIBLE | INVISIBLE]\n      [AUTO_INCREMENT] [UNIQUE [KEY]] [[PRIMARY] KEY]\n      [COMMENT \'string\']\n      [COLLATE collation_name]\n      [COLUMN_FORMAT {FIXED | DYNAMIC | DEFAULT}]\n      [ENGINE_ATTRIBUTE [=] \'string\']\n      [SECONDARY_ENGINE_ATTRIBUTE [=] \'string\']\n      [STORAGE {DISK | MEMORY}]\n      [reference_definition]\n      [check_constraint_definition]\n  | data_type\n      [COLLATE collation_name]\n      [GENERATED ALWAYS] AS (expr)\n      [VIRTUAL | STORED] [NOT NULL | NULL]\n      [VISIBLE | INVISIBLE]\n      [UNIQUE [KEY]] [[PRIMARY] KEY]\n      [COMMENT \'string\']\n      [reference_definition]\n      [check_constraint_definition]\n}\n\ndata_type:\n    (see https://dev.mysql.com/doc/refman/8.0/en/data-types.html)\n\nkey_part: {col_name [(length)] | (expr)} [ASC | DESC]\n\nindex_type:\n    USING {BTREE | HASH}\n\nindex_option: {\n    KEY_BLOCK_SIZE [=] value\n  | index_type\n  | WITH PARSER parser_name\n  | COMMENT \'string\'\n  | {VISIBLE | INVISIBLE}\n  |ENGINE_ATTRIBUTE [=] \'string\'\n  |SECONDARY_ENGINE_ATTRIBUTE [=] \'string\'\n}\n\ncheck_constraint_definition:\n    [CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED]\n\nreference_definition:\n    REFERENCES tbl_name (key_part,...)\n      [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]\n      [ON DELETE reference_option]\n      [ON UPDATE reference_option]\n\nreference_option:\n    RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT\n\ntable_options:\n    table_option [[,] table_option] ...\n\ntable_option: {\n    AUTOEXTEND_SIZE [=] value\n  | AUTO_INCREMENT [=] value\n  | AVG_ROW_LENGTH [=] value\n  | [DEFAULT] CHARACTER SET [=] charset_name\n  | CHECKSUM [=] {0 | 1}\n  | [DEFAULT] COLLATE [=] collation_name\n  | COMMENT [=] \'string\'\n  | COMPRESSION [=] {\'ZLIB\' | \'LZ4\' | \'NONE\'}\n  | CONNECTION [=] \'connect_string\'\n  | {DATA | INDEX} DIRECTORY [=] \'absolute path to directory\'\n  | DELAY_KEY_WRITE [=] {0 | 1}\n  | ENCRYPTION [=] {\'Y\' | \'N\'}\n  | ENGINE [=] engine_name\n  | ENGINE_ATTRIBUTE [=] \'string\'\n  | INSERT_METHOD [=] { NO | FIRST | LAST }\n  | KEY_BLOCK_SIZE [=] value\n  | MAX_ROWS [=] value\n  | MIN_ROWS [=] value\n  | PACK_KEYS [=] {0 | 1 | DEFAULT}\n  | PASSWORD [=] \'string\'\n  | ROW_FORMAT [=] {DEFAULT | DYNAMIC | FIXED | COMPRESSED | REDUNDANT | COMPACT}\n  | START TRANSACTION \n  | SECONDARY_ENGINE_ATTRIBUTE [=] \'string\'\n  | STATS_AUTO_RECALC [=] {DEFAULT | 0 | 1}\n  | STATS_PERSISTENT [=] {DEFAULT | 0 | 1}\n  | STATS_SAMPLE_PAGES [=] value\n  | tablespace_option\n  | UNION [=] (tbl_name[,tbl_name]...)\n}\n\npartition_options:\n    PARTITION BY\n        { [LINEAR] HASH(expr)\n        | [LINEAR] KEY [ALGORITHM={1 | 2}] (column_list)\n        | RANGE{(expr) | COLUMNS(column_list)}\n        | LIST{(expr) | COLUMNS(column_list)} }\n    [PARTITIONS num]\n    [SUBPARTITION BY\n        { [LINEAR] HASH(expr)\n        | [LINEAR] KEY [ALGORITHM={1 | 2}] (column_list) }\n      [SUBPARTITIONS num]\n    ]\n    [(partition_definition [, partition_definition] ...)]\n\npartition_definition:\n    PARTITION partition_name\n        [VALUES\n            {LESS THAN {(expr | value_list) | MAXVALUE}\n            |\n            IN (value_list)}]\n        [[STORAGE] ENGINE [=] engine_name]\n        [COMMENT [=] \'string\' ]\n        [DATA DIRECTORY [=] \'data_dir\']\n        [INDEX DIRECTORY [=] \'index_dir\']\n        [MAX_ROWS [=] max_number_of_rows]\n        [MIN_ROWS [=] min_number_of_rows]\n        [TABLESPACE [=] tablespace_name]\n        [(subpartition_definition [, subpartition_definition] ...)]\n\nsubpartition_definition:\n    SUBPARTITION logical_name\n        [[STORAGE] ENGINE [=] engine_name]\n        [COMMENT [=] \'string\' ]\n        [DATA DIRECTORY [=] \'data_dir\']\n        [INDEX DIRECTORY [=] \'index_dir\']\n        [MAX_ROWS [=] max_number_of_rows]\n        [MIN_ROWS [=] min_number_of_rows]\n        [TABLESPACE [=] tablespace_name]\n\ntablespace_option:\n    TABLESPACE tablespace_name [STORAGE DISK]\n  | [TABLESPACE tablespace_name] STORAGE MEMORY\n\nquery_expression:\n    SELECT ...   (Some valid select or union statement)\n\nCREATE TABLE creates a table with the given name. You must have the\nCREATE privilege for the table.\n\nBy default, tables are created in the default database, using the\nInnoDB storage engine. An error occurs if the table exists, if there is\nno default database, or if the database does not exist.\n\nMySQL has no limit on the number of tables. The underlying file system\nmay have a limit on the number of files that represent tables.\nIndividual storage engines may impose engine-specific constraints.\nInnoDB permits up to 4 billion tables.\n\nFor information about the physical representation of a table, see\nhttps://dev.mysql.com/doc/refman/8.0/en/create-table-files.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-table.html'),
(523, 'FOREIGN KEY', 40, 'MySQL supports foreign keys, which permit cross-referencing related\ndata across tables, and foreign key constraints, which help keep the\nrelated data consistent.\n\nA foreign key relationship involves a parent table that holds the\ninitial column values, and a child table with column values that\nreference the parent column values. A foreign key constraint is defined\non the child table.\n\nThe essential syntax for a defining a foreign key constraint in a\nCREATE TABLE or ALTER TABLE statement includes the following:\n\n[CONSTRAINT [symbol]] FOREIGN KEY\n    [index_name] (col_name, ...)\n    REFERENCES tbl_name (col_name,...)\n    [ON DELETE reference_option]\n    [ON UPDATE reference_option]\n\nreference_option:\n    RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html\n\n', 'CREATE TABLE product (\n    category INT NOT NULL, id INT NOT NULL,\n    price DECIMAL,\n    PRIMARY KEY(category, id)\n)   ENGINE=INNODB;\n\nCREATE TABLE customer (\n    id INT NOT NULL,\n    PRIMARY KEY (id)\n)   ENGINE=INNODB;\n\nCREATE TABLE product_order (\n    no INT NOT NULL AUTO_INCREMENT,\n    product_category INT NOT NULL,\n    product_id INT NOT NULL,\n    customer_id INT NOT NULL,\n\n    PRIMARY KEY(no),\n    INDEX (product_category, product_id),\n    INDEX (customer_id),\n\n    FOREIGN KEY (product_category, product_id)\n      REFERENCES product(category, id)\n      ON UPDATE CASCADE ON DELETE RESTRICT,\n\n    FOREIGN KEY (customer_id)\n      REFERENCES customer(id)\n)   ENGINE=INNODB;\n', 'https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html'),
(524, 'CREATE TABLESPACE', 40, 'Syntax:\nCREATE [UNDO] TABLESPACE tablespace_name\n\n  InnoDB and NDB:\n    [ADD DATAFILE \'file_name\']\n    [AUTOEXTEND_SIZE [=] value]\n\n  InnoDB only:\n    [FILE_BLOCK_SIZE = value]\n    [ENCRYPTION [=] {\'Y\' | \'N\'}]\n\n  NDB only:\n    USE LOGFILE GROUP logfile_group\n    [EXTENT_SIZE [=] extent_size]\n    [INITIAL_SIZE [=] initial_size]\n    [MAX_SIZE [=] max_size]\n    [NODEGROUP [=] nodegroup_id]\n    [WAIT]\n    [COMMENT [=] \'string\']\n\n  InnoDB and NDB:\n    [ENGINE [=] engine_name]\n\n  Reserved for future use:\n    [ENGINE_ATTRIBUTE [=] \'string\']\n\nThis statement is used to create a tablespace. The precise syntax and\nsemantics depend on the storage engine used. In standard MySQL\nreleases, this is always an InnoDB tablespace. MySQL NDB Cluster also\nsupports tablespaces using the NDB storage engine.\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-innodb\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-ndb\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-options\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-notes\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-innodb-examples\n\no https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html#create\n  -tablespace-ndb-examples\n\nConsiderations for InnoDB\n\nCREATE TABLESPACE syntax is used to create general tablespaces or undo\ntablespaces. The UNDO keyword, introduced in MySQL 8.0.14, must be\nspecified to create an undo tablespace.\n\nA general tablespace is a shared tablespace. It can hold multiple\ntables, and supports all table row formats. General tablespaces can be\ncreated in a location relative to or independent of the data directory.\n\nAfter creating an InnoDB general tablespace, use CREATE TABLE tbl_name\n... TABLESPACE [=] tablespace_name or ALTER TABLE tbl_name TABLESPACE\n[=] tablespace_name to add tables to the tablespace. For more\ninformation, see\nhttps://dev.mysql.com/doc/refman/8.0/en/general-tablespaces.html.\n\nUndo tablespaces contain undo logs. Undo tablespaces can be created in\na chosen location by specifying a fully qualified data file path. For\nmore information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html.\n\nConsiderations for NDB Cluster\n\nThis statement is used to create a tablespace, which can contain one or\nmore data files, providing storage space for NDB Cluster Disk Data\ntables (see\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data.html).\nOne data file is created and added to the tablespace using this\nstatement. Additional data files may be added to the tablespace by\nusing the ALTER TABLESPACE statement (see [HELP ALTER TABLESPACE]).\n\n*Note*:\n\nAll NDB Cluster Disk Data objects share the same namespace. This means\nthat each Disk Data object must be uniquely named (and not merely each\nDisk Data object of a given type). For example, you cannot have a\ntablespace and a log file group with the same name, or a tablespace and\na data file with the same name.\n\nA log file group of one or more UNDO log files must be assigned to the\ntablespace to be created with the USE LOGFILE GROUP clause.\nlogfile_group must be an existing log file group created with CREATE\nLOGFILE GROUP (see [HELP CREATE LOGFILE GROUP]). Multiple tablespaces\nmay use the same log file group for UNDO logging.\n\nWhen setting EXTENT_SIZE or INITIAL_SIZE, you may optionally follow the\nnumber with a one-letter abbreviation for an order of magnitude,\nsimilar to those used in my.cnf. Generally, this is one of the letters\nM (for megabytes) or G (for gigabytes).\n\nINITIAL_SIZE and EXTENT_SIZE are subject to rounding as follows:\n\no EXTENT_SIZE is rounded up to the nearest whole multiple of 32K.\n\no INITIAL_SIZE is rounded down to the nearest whole multiple of 32K;\n  this result is rounded up to the nearest whole multiple of\n  EXTENT_SIZE (after any rounding).\n\n*Note*:\n\nNDB reserves 4% of a tablespace for data node restart operations. This\nreserved space cannot be used for data storage.\n\nThe rounding just described is done explicitly, and a warning is issued\nby the MySQL Server when any such rounding is performed. The rounded\nvalues are also used by the NDB kernel for calculating\nINFORMATION_SCHEMA.FILES column values and other purposes. However, to\navoid an unexpected result, we suggest that you always use whole\nmultiples of 32K in specifying these options.\n\nWhen CREATE TABLESPACE is used with ENGINE [=] NDB, a tablespace and\nassociated data file are created on each Cluster data node. You can\nverify that the data files were created and obtain information about\nthem by querying the Information Schema FILES table. (See the example\nlater in this section.)\n\n(See\nhttps://dev.mysql.com/doc/refman/8.0/en/information-schema-files-table.\nhtml.)\n\nOptions\n\no ADD DATAFILE: Defines the name of a tablespace data file. This option\n  is always required when creating an NDB tablespace; for InnoDB in\n  MySQL 8.0.14 and later, it is required only when creating an undo\n  tablespace. The file_name, including any specified path, must be\n  quoted with single or double quotation marks. File names (not\n  counting the file extension) and directory names must be at least one\n  byte in length. Zero length file names and directory names are not\n  supported.\n\n  Because there are considerable differences in how InnoDB and NDB\n  treat data files, the two storage engines are covered separately in\n  the discussion that follows.\n\n  InnoDB data files An InnoDB tablespace supports only a single data\n  file, whose name must include a .ibd extension.\n\n  To place an InnoDB general tablespace data file in a location outside\n  of the data directory, include a fully qualified path or a path\n  relative to the data directory. Only a fully qualified path is\n  permitted for undo tablespaces. If you do not specify a path, a\n  general tablespace is created in the data directory. An undo\n  tablespace created without specifying a path is created in the\n  directory defined by the innodb_undo_directory variable. If the\n  innodb_undo_directory variable is undefined, undo tablespaces are\n  created in the data directory.\n\n  To avoid conflicts with implicitly created file-per-table\n  tablespaces, creating an InnoDB general tablespace in a subdirectory\n  under the data directory is not supported. When creating a general\n  tablespace or undo tablespace outside of the data directory, the\n  directory must exist and must be known to InnoDB prior to creating\n  the tablespace. To make a directory known to InnoDB, add it to the\n  innodb_directories value or to one of the variables whose values are\n  appended to the innodb_directories value. innodb_directories is a\n  read-only variable. Configuring it requires restarting the server.\n\n  If the ADD DATAFILE clause is not specified when creating an InnoDB\n  tablespace, a tablespace data file with a unique file name is created\n  implicitly. The unique file name is a 128 bit UUID formatted into\n  five groups of hexadecimal numbers separated by dashes\n  (aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee). A file extension is added if\n  required by the storage engine. An .ibd file extension is added for\n  InnoDB general tablespace data files. In a replication environment,\n  the data file name created on the replication source server is not\n  the same as the data file name created on the replica.\n\n  As of MySQL 8.0.17, the ADD DATAFILE clause does not permit circular\n  directory references when creating an InnoDB tablespace. For example,\n  the circular directory reference (/../) in the following statement is\n  not permitted:\n\nCREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd \'any_directory/../ts1.ibd\';\n\n  An exception to this restriction exists on Linux, where a circular\n  directory reference is permitted if the preceding directory is a\n  symbolic link. For example, the data file path in the example above\n  is permitted if any_directory is a symbolic link. (It is still\n  permitted for data file paths to begin with \'../\'.)\n\n  NDB data files An NDB tablespace supports multiple data files which\n  can have any legal file names; more data files can be added to an NDB\n  Cluster tablespace following its creation by using an ALTER\n  TABLESPACE statement.\n\n  An NDB tablespace data file is created by default in the data node\n  file system directory---that is, the directory named ndb_nodeid_fs/TS\n  under the data node\'s data directory (DataDir), where nodeid is the\n  data node\'s NodeId. To place the data file in a location other than\n  the default, include an absolute directory path or a path relative to\n  the default location. If the directory specified does not exist, NDB\n  attempts to create it; the system user account under which the data\n  node process is running must have the appropriate permissions to do\n  so.\n\n  *Note*:\n\n  When determining the path used for a data file, NDB does not expand\n  the ~ (tilde) character.\n\n  When multiple data nodes are run on the same physical host, the\n  following considerations apply:\n\n  o You cannot specify an absolute path when creating a data file.\n\n  o It is not possible to create tablespace data files outside the data\n    node file system directory, unless each data node has a separate\n    data directory.\n\n  o If each data node has its own data directory, data files can be\n    created anywhere within this directory.\n\n  o If each data node has its own data directory, it may also be\n    possible to create a data file outside the node\'s data directory\n    using a relative path, as long as this path resolves to a unique\n    location on the host file system for each data node running on that\n    host.\n\no FILE_BLOCK_SIZE: This option---which is specific to InnoDB general\n  tablespaces, and is ignored by NDB---defines the block size for the\n  tablespace data file. Values can be specified in bytes or kilobytes.\n  For example, an 8 kilobyte file block size can be specified as 8192\n  or 8K. If you do not specify this option, FILE_BLOCK_SIZE defaults to\n  the innodb_page_size value. FILE_BLOCK_SIZE is required when you\n  intend to use the tablespace for storing compressed InnoDB tables\n  (ROW_FORMAT=COMPRESSED). In this case, you must define the tablespace\n  FILE_BLOCK_SIZE when creating the tablespace.\n\n  If FILE_BLOCK_SIZE is equal the innodb_page_size value, the\n  tablespace can contain only tables having an uncompressed row format\n  (COMPACT, REDUNDANT, and DYNAMIC). Tables with a COMPRESSED row\n  format have a different physical page size than uncompressed tables.\n  Therefore, compressed tables cannot coexist in the same tablespace as\n  uncompressed tables.\n\n  For a general tablespace to contain compressed tables,\n  FILE_BLOCK_SIZE must be specified, and the FILE_BLOCK_SIZE value must\n  be a valid compressed page size in relation to the innodb_page_size\n  value. Also, the physical page size of the compressed table\n  (KEY_BLOCK_SIZE) must be equal to FILE_BLOCK_SIZE/1024. For example,\n  if innodb_page_size=16K, and FILE_BLOCK_SIZE=8K, the KEY_BLOCK_SIZE\n  of the table must be 8. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/general-tablespaces.html.\n\no USE LOGFILE GROUP: Required for NDB, this is the name of a log file\n  group previously created using CREATE LOGFILE GROUP. Not supported\n  for InnoDB, where it fails with an error.\n\no EXTENT_SIZE: This option is specific to NDB, and is not supported by\n  InnoDB, where it fails with an error. EXTENT_SIZE sets the size, in\n  bytes, of the extents used by any files belonging to the tablespace.\n  The default value is 1M. The minimum size is 32K, and theoretical\n  maximum is 2G, although the practical maximum size depends on a\n  number of factors. In most cases, changing the extent size does not\n  have any measurable effect on performance, and the default value is\n  recommended for all but the most unusual situations.\n\n  An extent is a unit of disk space allocation. One extent is filled\n  with as much data as that extent can contain before another extent is\n  used. In theory, up to 65,535 (64K) extents may used per data file;\n  however, the recommended maximum is 32,768 (32K). The recommended\n  maximum size for a single data file is 32G---that is, 32K extents x 1\n  MB per extent. In addition, once an extent is allocated to a given\n  partition, it cannot be used to store data from a different\n  partition; an extent cannot store data from more than one partition.\n  This means, for example that a tablespace having a single datafile\n  whose INITIAL_SIZE (described in the following item) is 256 MB and\n  whose EXTENT_SIZE is 128M has just two extents, and so can be used to\n  store data from at most two different disk data table partitions.\n\n  You can see how many extents remain free in a given data file by\n  querying the Information Schema FILES table, and so derive an\n  estimate for how much space remains free in the file. For further\n  discussion and examples, see\n  https://dev.mysql.com/doc/refman/8.0/en/information-schema-files-tabl\n  e.html.\n\no INITIAL_SIZE: This option is specific to NDB, and is not supported by\n  InnoDB, where it fails with an error.\n\n  The INITIAL_SIZE parameter sets the total size in bytes of the data\n  file that was specific using ADD DATATFILE. Once this file has been\n  created, its size cannot be changed; however, you can add more data\n  files to the tablespace using ALTER TABLESPACE ... ADD DATAFILE.\n\n  INITIAL_SIZE is optional; its default value is 134217728 (128 MB).\n\n  On 32-bit systems, the maximum supported value for INITIAL_SIZE is\n  4294967296 (4 GB).\n\no AUTOEXTEND_SIZE: Ignored by MySQL prior to MySQL 8.0.23; From MySQL\n  8.0.23, defines the amount by which InnoDB extends the size of the\n  tablespace when it becomes full. The setting must be a multiple of\n  4MB. The default setting is 0, which causes the tablespace to be\n  extended according to the implicit default behavior. For more\n  information, see\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-autoextend-\n  size.html.\n\n  Has no effect in any release of MySQL NDB Cluster 8.0, regardless of\n  the storage engine used.\n\no MAX_SIZE: Currently ignored by MySQL; reserved for possible future\n  use. Has no effect in any release of MySQL 8.0 or MySQL NDB Cluster\n  8.0, regardless of the storage engine used.\n\no NODEGROUP: Currently ignored by MySQL; reserved for possible future\n  use. Has no effect in any release of MySQL 8.0 or MySQL NDB Cluster\n  8.0, regardless of the storage engine used.\n\no WAIT: Currently ignored by MySQL; reserved for possible future use.\n  Has no effect in any release of MySQL 8.0 or MySQL NDB Cluster 8.0,\n  regardless of the storage engine used.\n\no COMMENT: Currently ignored by MySQL; reserved for possible future\n  use. Has no effect in any release of MySQL 8.0 or MySQL NDB Cluster\n  8.0, regardless of the storage engine used.\n\no The ENCRYPTION clause enables or disables page-level data encryption\n  for an InnoDB general tablespace. Encryption support for general\n  tablespaces was introduced in MySQL 8.0.13.\n\n  As of MySQL 8.0.16, if the ENCRYPTION clause is not specified, the\n  default_table_encryption setting controls whether encryption is\n  enabled. The ENCRYPTION clause overrides the default_table_encryption\n  setting. However, if the table_encryption_privilege_check variable is\n  enabled, the TABLE_ENCRYPTION_ADMIN privilege is required to use an\n  ENCRYPTION clause setting that differs from the\n  default_table_encryption setting.\n\n  A keyring plugin must be installed and configured before an\n  encryption-enabled tablespace can be created.\n\n  When a general tablespace is encrypted, all tables residing in the\n  tablespace are encrypted. Likewise, a table created in an encrypted\n  tablespace is encrypted.\n\n  For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html\n\no ENGINE: Defines the storage engine which uses the tablespace, where\n  engine_name is the name of the storage engine. Currently, only the\n  InnoDB storage engine is supported by standard MySQL 8.0 releases.\n  MySQL NDB Cluster supports both NDB and InnoDB tablespaces. The value\n  of the default_storage_engine system variable is used for ENGINE if\n  the option is not specified.\n\no The ENGINE_ATTRIBUTE option (available as of MySQL 8.0.21) is used to\n  specify tablespace attributes for primary storage engines. The option\n  is reserved for future use.\n\n  Permitted values are a string literal containing a valid JSON\n  document or an empty string (\'\'). Invalid JSON is rejected.\n\nCREATE TABLESPACE ts1 ENGINE_ATTRIBUTE=\'{\"key\":\"value\"}\';\n\n  ENGINE_ATTRIBUTE values can be repeated without error. In this case,\n  the last specified value is used.\n\n  ENGINE_ATTRIBUTE values are not checked by the server, nor are they\n  cleared when the table\'s storage engine is changed.\n\nNotes\n\no For the rules covering the naming of MySQL tablespaces, see\n  https://dev.mysql.com/doc/refman/8.0/en/identifiers.html. In addition\n  to these rules, the slash character (\"/\") is not permitted, nor can\n  you use names beginning with innodb_, as this prefix is reserved for\n  system use.\n\no Creation of temporary general tablespaces is not supported.\n\no General tablespaces do not support temporary tables.\n\no The TABLESPACE option may be used with CREATE TABLE or ALTER TABLE to\n  assign an InnoDB table partition or subpartition to a file-per-table\n  tablespace. All partitions must belong to the same storage engine.\n  Assigning table partitions to shared InnoDB tablespaces is not\n  supported. Shared tablespaces include the InnoDB system tablespace\n  and general tablespaces.\n\no General tablespaces support the addition of tables of any row format\n  using CREATE TABLE ... TABLESPACE. innodb_file_per_table does not\n  need to be enabled.\n\no innodb_strict_mode is not applicable to general tablespaces.\n  Tablespace management rules are strictly enforced independently of\n  innodb_strict_mode. If CREATE TABLESPACE parameters are incorrect or\n  incompatible, the operation fails regardless of the\n  innodb_strict_mode setting. When a table is added to a general\n  tablespace using CREATE TABLE ... TABLESPACE or ALTER TABLE ...\n  TABLESPACE, innodb_strict_mode is ignored but the statement is\n  evaluated as if innodb_strict_mode is enabled.\n\no Use DROP TABLESPACE to remove a tablespace. All tables must be\n  dropped from a tablespace using DROP TABLE prior to dropping the\n  tablespace. Before dropping an NDB Cluster tablespace you must also\n  remove all its data files using one or more ALTER TABLESPACE ... DROP\n  DATATFILE statements. See\n  https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-objec\n  ts.html.\n\no All parts of an InnoDB table added to an InnoDB general tablespace\n  reside in the general tablespace, including indexes and BLOB pages.\n\n  For an NDB table assigned to a tablespace, only those columns which\n  are not indexed are stored on disk, and actually use the tablespace\n  data files. Indexes and indexed columns for all NDB tables are always\n  kept in memory.\n\no Similar to the system tablespace, truncating or dropping tables\n  stored in a general tablespace creates free space internally in the\n  general tablespace .ibd data file which can only be used for new\n  InnoDB data. Space is not released back to the operating system as it\n  is for file-per-table tablespaces.\n\no A general tablespace is not associated with any database or schema.\n\no ALTER TABLE ... DISCARD TABLESPACE and ALTER TABLE ...IMPORT\n  TABLESPACE are not supported for tables that belong to a general\n  tablespace.\n\no The server uses tablespace-level metadata locking for DDL that\n  references general tablespaces. By comparison, the server uses\n  table-level metadata locking for DDL that references file-per-table\n  tablespaces.\n\no A generated or existing tablespace cannot be changed to a general\n  tablespace.\n\no There is no conflict between general tablespace names and\n  file-per-table tablespace names. The \"/\" character, which is present\n  in file-per-table tablespace names, is not permitted in general\n  tablespace names.\n\no mysqldump and mysqlpump do not dump InnoDB CREATE TABLESPACE\n  statements.\n\nInnoDB Examples\n\nThis example demonstrates creating a general tablespace and adding\nthree uncompressed tables of different row formats.\n\nmysql> CREATE TABLESPACE `ts1` ADD DATAFILE \'ts1.ibd\' ENGINE=INNODB;\n\nmysql> CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=REDUNDANT;\n\nmysql> CREATE TABLE t2 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=COMPACT;\n\nmysql> CREATE TABLE t3 (c1 INT PRIMARY KEY) TABLESPACE ts1 ROW_FORMAT=DYNAMIC;\n\nThis example demonstrates creating a general tablespace and adding a\ncompressed table. The example assumes a default innodb_page_size value\nof 16K. The FILE_BLOCK_SIZE of 8192 requires that the compressed table\nhave a KEY_BLOCK_SIZE of 8.\n\nmysql> CREATE TABLESPACE `ts2` ADD DATAFILE \'ts2.ibd\' FILE_BLOCK_SIZE = 8192 Engine=InnoDB;\n\nmysql> CREATE TABLE t4 (c1 INT PRIMARY KEY) TABLESPACE ts2 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;\n\nThis example demonstrates creating a general tablespace without\nspecifying the ADD DATAFILE clause, which is optional as of MySQL\n8.0.14.\n\nmysql> CREATE TABLESPACE `ts3` ENGINE=INNODB;\n\nThis example demonstrates creating an undo tablespace.\n\nmysql> CREATE UNDO TABLESPACE undo_003 ADD DATAFILE \'undo_003.ibu\';\n\nNDB Example\n\nSuppose that you wish to create an NDB Cluster Disk Data tablespace\nnamed myts using a datafile named mydata-1.dat. An NDB tablespace\nalways requires the use of a log file group consisting of one or more\nundo log files. For this example, we first create a log file group\nnamed mylg that contains one undo long file named myundo-1.dat, using\nthe CREATE LOGFILE GROUP statement shown here:\n\nmysql> CREATE LOGFILE GROUP myg1\n    ->     ADD UNDOFILE \'myundo-1.dat\'\n    ->     ENGINE=NDB;\nQuery OK, 0 rows affected (3.29 sec)\n\nNow you can create the tablespace previously described using the\nfollowing statement:\n\nmysql> CREATE TABLESPACE myts\n    ->     ADD DATAFILE \'mydata-1.dat\'\n    ->     USE LOGFILE GROUP mylg\n    ->     ENGINE=NDB;\nQuery OK, 0 rows affected (2.98 sec)\n\nYou can now create a Disk Data table using a CREATE TABLE statement\nwith the TABLESPACE and STORAGE DISK options, similar to what is shown\nhere:\n\nmysql> CREATE TABLE mytable (\n    ->     id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,\n    ->     lname VARCHAR(50) NOT NULL,\n    ->     fname VARCHAR(50) NOT NULL,\n    ->     dob DATE NOT NULL,\n    ->     joined DATE NOT NULL,\n    ->     INDEX(last_name, first_name)\n    -> )\n    ->     TABLESPACE myts STORAGE DISK\n    ->     ENGINE=NDB;\nQuery OK, 0 rows affected (1.41 sec)\n\nIt is important to note that only the dob and joined columns from\nmytable are actually stored on disk, due to the fact that the id,\nlname, and fname columns are all indexed.\n\nAs mentioned previously, when CREATE TABLESPACE is used with ENGINE [=]\nNDB, a tablespace and associated data file are created on each NDB\nCluster data node. You can verify that the data files were created and\nobtain information about them by querying the Information Schema FILES\ntable, as shown here:\n\nmysql> SELECT FILE_NAME, FILE_TYPE, LOGFILE_GROUP_NAME, STATUS, EXTRA\n    ->     FROM INFORMATION_SCHEMA.FILES\n    ->     WHERE TABLESPACE_NAME = \'myts\';\n\n+--------------+------------+--------------------+--------+----------------+\n| file_name    | file_type  | logfile_group_name | status | extra          |\n+--------------+------------+--------------------+--------+----------------+\n| mydata-1.dat | DATAFILE   | mylg               | NORMAL | CLUSTER_NODE=5 |\n| mydata-1.dat | DATAFILE   | mylg               | NORMAL | CLUSTER_NODE=6 |\n| NULL         | TABLESPACE | mylg               | NORMAL | NULL           |\n+--------------+------------+--------------------+--------+----------------+\n3 rows in set (0.01 sec)\n\nFor additional information and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-objects\n.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-tablespace.html'),
(525, 'CREATE TRIGGER', 40, 'Syntax:\nCREATE\n    [DEFINER = user]\n    TRIGGER [IF NOT EXISTS] trigger_name\n    trigger_time trigger_event\n    ON tbl_name FOR EACH ROW\n    [trigger_order]\n    trigger_body\n\ntrigger_time: { BEFORE | AFTER }\n\ntrigger_event: { INSERT | UPDATE | DELETE }\n\ntrigger_order: { FOLLOWS | PRECEDES } other_trigger_name\n\nThis statement creates a new trigger. A trigger is a named database\nobject that is associated with a table, and that activates when a\nparticular event occurs for the table. The trigger becomes associated\nwith the table named tbl_name, which must refer to a permanent table.\nYou cannot associate a trigger with a TEMPORARY table or a view.\n\nTrigger names exist in the schema namespace, meaning that all triggers\nmust have unique names within a schema. Triggers in different schemas\ncan have the same name.\n\nIF NOT EXISTS prevents an error from occurring if a trigger having the\nsame name, on the same table, exists in the same schema. This option is\nsupported with CREATE TRIGGER beginning with MySQL 8.0.29.\n\nThis section describes CREATE TRIGGER syntax. For additional\ndiscussion, see\nhttps://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html.\n\nCREATE TRIGGER requires the TRIGGER privilege for the table associated\nwith the trigger. If the DEFINER clause is present, the privileges\nrequired depend on the user value, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\nIf binary logging is enabled, CREATE TRIGGER might require the SUPER\nprivilege, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-logging.html.\n\nThe DEFINER clause determines the security context to be used when\nchecking access privileges at trigger activation time, as described\nlater in this section.\n\ntrigger_time is the trigger action time. It can be BEFORE or AFTER to\nindicate that the trigger activates before or after each row to be\nmodified.\n\nBasic column value checks occur prior to trigger activation, so you\ncannot use BEFORE triggers to convert values inappropriate for the\ncolumn type to valid values.\n\ntrigger_event indicates the kind of operation that activates the\ntrigger. These trigger_event values are permitted:\n\no INSERT: The trigger activates whenever a new row is inserted into the\n  table (for example, through INSERT, LOAD DATA, and REPLACE\n  statements).\n\no UPDATE: The trigger activates whenever a row is modified (for\n  example, through UPDATE statements).\n\no DELETE: The trigger activates whenever a row is deleted from the\n  table (for example, through DELETE and REPLACE statements). DROP\n  TABLE and TRUNCATE TABLE statements on the table do not activate this\n  trigger, because they do not use DELETE. Dropping a partition does\n  not activate DELETE triggers, either.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-trigger.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-trigger.html'),
(526, 'CREATE VIEW', 40, 'Syntax:\nCREATE\n    [OR REPLACE]\n    [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]\n    [DEFINER = user]\n    [SQL SECURITY { DEFINER | INVOKER }]\n    VIEW view_name [(column_list)]\n    AS select_statement\n    [WITH [CASCADED | LOCAL] CHECK OPTION]\n\nThe CREATE VIEW statement creates a new view, or replaces an existing\nview if the OR REPLACE clause is given. If the view does not exist,\nCREATE OR REPLACE VIEW is the same as CREATE VIEW. If the view does\nexist, CREATE OR REPLACE VIEW replaces it.\n\nFor information about restrictions on view use, see\nhttps://dev.mysql.com/doc/refman/8.0/en/view-restrictions.html.\n\nThe select_statement is a SELECT statement that provides the definition\nof the view. (Selecting from the view selects, in effect, using the\nSELECT statement.) The select_statement can select from base tables,\nother views. Beginning with MySQL 8.0.19, the SELECT statement can use\na VALUES statement as its source, or can be replaced with a TABLE\nstatement, as with CREATE TABLE ... SELECT.\n\nThe view definition is \"frozen\" at creation time and is not affected by\nsubsequent changes to the definitions of the underlying tables. For\nexample, if a view is defined as SELECT * on a table, new columns added\nto the table later do not become part of the view, and columns dropped\nfrom the table result in an error when selecting from the view.\n\nThe ALGORITHM clause affects how MySQL processes the view. The DEFINER\nand SQL SECURITY clauses specify the security context to be used when\nchecking access privileges at view invocation time. The WITH CHECK\nOPTION clause can be given to constrain inserts or updates to rows in\ntables referenced by the view. These clauses are described later in\nthis section.\n\nThe CREATE VIEW statement requires the CREATE VIEW privilege for the\nview, and some privilege for each column selected by the SELECT\nstatement. For columns used elsewhere in the SELECT statement, you must\nhave the SELECT privilege. If the OR REPLACE clause is present, you\nmust also have the DROP privilege for the view. If the DEFINER clause\nis present, the privileges required depend on the user value, as\ndiscussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\n\nWhen a view is referenced, privilege checking occurs as described later\nin this section.\n\nA view belongs to a database. By default, a new view is created in the\ndefault database. To create the view explicitly in a given database,\nuse db_name.view_name syntax to qualify the view name with the database\nname:\n\nCREATE VIEW test.v AS SELECT * FROM t;\n\nUnqualified table or view names in the SELECT statement are also\ninterpreted with respect to the default database. A view can refer to\ntables or views in other databases by qualifying the table or view name\nwith the appropriate database name.\n\nWithin a database, base tables and views share the same namespace, so a\nbase table and a view cannot have the same name.\n\nColumns retrieved by the SELECT statement can be simple references to\ntable columns, or expressions that use functions, constant values,\noperators, and so forth.\n\nA view must have unique column names with no duplicates, just like a\nbase table. By default, the names of the columns retrieved by the\nSELECT statement are used for the view column names. To define explicit\nnames for the view columns, specify the optional column_list clause as\na list of comma-separated identifiers. The number of names in\ncolumn_list must be the same as the number of columns retrieved by the\nSELECT statement.\n\nA view can be created from many kinds of SELECT statements. It can\nrefer to base tables or other views. It can use joins, UNION, and\nsubqueries. The SELECT need not even refer to any tables:\n\nCREATE VIEW v_today (today) AS SELECT CURRENT_DATE;\n\nThe following example defines a view that selects two columns from\nanother table as well as an expression calculated from those columns:\n\nmysql> CREATE TABLE t (qty INT, price INT);\nmysql> INSERT INTO t VALUES(3, 50);\nmysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;\nmysql> SELECT * FROM v;\n+------+-------+-------+\n| qty  | price | value |\n+------+-------+-------+\n|    3 |    50 |   150 |\n+------+-------+-------+\n\nA view definition is subject to the following restrictions:\n\no The SELECT statement cannot refer to system variables or user-defined\n  variables.\n\no Within a stored program, the SELECT statement cannot refer to program\n  parameters or local variables.\n\no The SELECT statement cannot refer to prepared statement parameters.\n\no Any table or view referred to in the definition must exist. If, after\n  the view has been created, a table or view that the definition refers\n  to is dropped, use of the view results in an error. To check a view\n  definition for problems of this kind, use the CHECK TABLE statement.\n\no The definition cannot refer to a TEMPORARY table, and you cannot\n  create a TEMPORARY view.\n\no You cannot associate a trigger with a view.\n\no Aliases for column names in the SELECT statement are checked against\n  the maximum column length of 64 characters (not the maximum alias\n  length of 256 characters).\n\nORDER BY is permitted in a view definition, but it is ignored if you\nselect from a view using a statement that has its own ORDER BY.\n\nFor other options or clauses in the definition, they are added to the\noptions or clauses of the statement that references the view, but the\neffect is undefined. For example, if a view definition includes a LIMIT\nclause, and you select from the view using a statement that has its own\nLIMIT clause, it is undefined which limit applies. This same principle\napplies to options such as ALL, DISTINCT, or SQL_SMALL_RESULT that\nfollow the SELECT keyword, and to clauses such as INTO, FOR UPDATE, FOR\nSHARE, LOCK IN SHARE MODE, and PROCEDURE.\n\nThe results obtained from a view may be affected if you change the\nquery processing environment by changing system variables:\n\nmysql> CREATE VIEW v (mycol) AS SELECT \'abc\';\nQuery OK, 0 rows affected (0.01 sec)\n\nmysql> SET sql_mode = \'\';\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT \"mycol\" FROM v;\n+-------+\n| mycol |\n+-------+\n| mycol |\n+-------+\n1 row in set (0.01 sec)\n\nmysql> SET sql_mode = \'ANSI_QUOTES\';\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT \"mycol\" FROM v;\n+-------+\n| mycol |\n+-------+\n| abc   |\n+-------+\n1 row in set (0.00 sec)\n\nThe DEFINER and SQL SECURITY clauses determine which MySQL account to\nuse when checking access privileges for the view when a statement is\nexecuted that references the view. The valid SQL SECURITY\ncharacteristic values are DEFINER (the default) and INVOKER. These\nindicate that the required privileges must be held by the user who\ndefined or invoked the view, respectively.\n\nIf the DEFINER clause is present, the user value should be a MySQL\naccount specified as \'user_name\'@\'host_name\', CURRENT_USER, or\nCURRENT_USER(). The permitted user values depend on the privileges you\nhold, as discussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html.\nAlso see that section for additional information about view security.\n\nIf the DEFINER clause is omitted, the default definer is the user who\nexecutes the CREATE VIEW statement. This is the same as specifying\nDEFINER = CURRENT_USER explicitly.\n\nWithin a view definition, the CURRENT_USER function returns the view\'s\nDEFINER value by default. For views defined with the SQL SECURITY\nINVOKER characteristic, CURRENT_USER returns the account for the view\'s\ninvoker. For information about user auditing within views, see\nhttps://dev.mysql.com/doc/refman/8.0/en/account-activity-auditing.html.\n\nWithin a stored routine that is defined with the SQL SECURITY DEFINER\ncharacteristic, CURRENT_USER returns the routine\'s DEFINER value. This\nalso affects a view defined within such a routine, if the view\ndefinition contains a DEFINER value of CURRENT_USER.\n\nMySQL checks view privileges like this:\n\no At view definition time, the view creator must have the privileges\n  needed to use the top-level objects accessed by the view. For\n  example, if the view definition refers to table columns, the creator\n  must have some privilege for each column in the select list of the\n  definition, and the SELECT privilege for each column used elsewhere\n  in the definition. If the definition refers to a stored function,\n  only the privileges needed to invoke the function can be checked. The\n  privileges required at function invocation time can be checked only\n  as it executes: For different invocations, different execution paths\n  within the function might be taken.\n\no The user who references a view must have appropriate privileges to\n  access it (SELECT to select from it, INSERT to insert into it, and so\n  forth.)\n\no When a view has been referenced, privileges for objects accessed by\n  the view are checked against the privileges held by the view DEFINER\n  account or invoker, depending on whether the SQL SECURITY\n  characteristic is DEFINER or INVOKER, respectively.\n\no If reference to a view causes execution of a stored function,\n  privilege checking for statements executed within the function depend\n  on whether the function SQL SECURITY characteristic is DEFINER or\n  INVOKER. If the security characteristic is DEFINER, the function runs\n  with the privileges of the DEFINER account. If the characteristic is\n  INVOKER, the function runs with the privileges determined by the\n  view\'s SQL SECURITY characteristic.\n\nExample: A view might depend on a stored function, and that function\nmight invoke other stored routines. For example, the following view\ninvokes a stored function f():\n\nCREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);\n\nSuppose that f() contains a statement such as this:\n\nIF name IS NULL then\n  CALL p1();\nELSE\n  CALL p2();\nEND IF;\n\nThe privileges required for executing statements within f() need to be\nchecked when f() executes. This might mean that privileges are needed\nfor p1() or p2(), depending on the execution path within f(). Those\nprivileges must be checked at runtime, and the user who must possess\nthe privileges is determined by the SQL SECURITY values of the view v\nand the function f().\n\nThe DEFINER and SQL SECURITY clauses for views are extensions to\nstandard SQL. In standard SQL, views are handled using the rules for\nSQL SECURITY DEFINER. The standard says that the definer of the view,\nwhich is the same as the owner of the view\'s schema, gets applicable\nprivileges on the view (for example, SELECT) and may grant them. MySQL\nhas no concept of a schema \"owner\", so MySQL adds a clause to identify\nthe definer. The DEFINER clause is an extension where the intent is to\nhave what the standard has; that is, a permanent record of who defined\nthe view. This is why the default DEFINER value is the account of the\nview creator.\n\nThe optional ALGORITHM clause is a MySQL extension to standard SQL. It\naffects how MySQL processes the view. ALGORITHM takes three values:\nMERGE, TEMPTABLE, or UNDEFINED. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/view-algorithms.html, as well\nas\nhttps://dev.mysql.com/doc/refman/8.0/en/derived-table-optimization.html\n.\n\nSome views are updatable. That is, you can use them in statements such\nas UPDATE, DELETE, or INSERT to update the contents of the underlying\ntable. For a view to be updatable, there must be a one-to-one\nrelationship between the rows in the view and the rows in the\nunderlying table. There are also certain other constructs that make a\nview nonupdatable.\n\nA generated column in a view is considered updatable because it is\npossible to assign to it. However, if such a column is updated\nexplicitly, the only permitted value is DEFAULT. For information about\ngenerated columns, see\nhttps://dev.mysql.com/doc/refman/8.0/en/create-table-generated-columns.\nhtml.\n\nThe WITH CHECK OPTION clause can be given for an updatable view to\nprevent inserts or updates to rows except those for which the WHERE\nclause in the select_statement is true.\n\nIn a WITH CHECK OPTION clause for an updatable view, the LOCAL and\nCASCADED keywords determine the scope of check testing when the view is\ndefined in terms of another view. The LOCAL keyword restricts the CHECK\nOPTION only to the view being defined. CASCADED causes the checks for\nunderlying views to be evaluated as well. When neither keyword is\ngiven, the default is CASCADED.\n\nFor more information about updatable views and the WITH CHECK OPTION\nclause, see\nhttps://dev.mysql.com/doc/refman/8.0/en/view-updatability.html, and\nhttps://dev.mysql.com/doc/refman/8.0/en/view-check-option.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/create-view.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/create-view.html'),
(527, 'DROP DATABASE', 40, 'Syntax:\nDROP {DATABASE | SCHEMA} [IF EXISTS] db_name\n\nDROP DATABASE drops all tables in the database and deletes the\ndatabase. Be very careful with this statement! To use DROP DATABASE,\nyou need the DROP privilege on the database. DROP SCHEMA is a synonym\nfor DROP DATABASE.\n\n*Important*:\n\nWhen a database is dropped, privileges granted specifically for the\ndatabase are not automatically dropped. They must be dropped manually.\nSee [HELP GRANT].\n\nIF EXISTS is used to prevent an error from occurring if the database\ndoes not exist.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-database.html'),
(528, 'DROP SCHEMA', 40, 'Syntax:\nDROP {DATABASE | SCHEMA} [IF EXISTS] db_name\n\nDROP DATABASE drops all tables in the database and deletes the\ndatabase. Be very careful with this statement! To use DROP DATABASE,\nyou need the DROP privilege on the database. DROP SCHEMA is a synonym\nfor DROP DATABASE.\n\n*Important*:\n\nWhen a database is dropped, privileges granted specifically for the\ndatabase are not automatically dropped. They must be dropped manually.\nSee [HELP GRANT].\n\nIF EXISTS is used to prevent an error from occurring if the database\ndoes not exist.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-database.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-database.html'),
(529, 'DROP EVENT', 40, 'Syntax:\nDROP EVENT [IF EXISTS] event_name\n\nThis statement drops the event named event_name. The event immediately\nceases being active, and is deleted completely from the server.\n\nIf the event does not exist, the error ERROR 1517 (HY000): Unknown\nevent \'event_name\' results. You can override this and cause the\nstatement to generate a warning for nonexistent events instead using IF\nEXISTS.\n\nThis statement requires the EVENT privilege for the schema to which the\nevent to be dropped belongs.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-event.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-event.html'),
(530, 'DROP INDEX', 40, 'Syntax:\nDROP INDEX index_name ON tbl_name\n    [algorithm_option | lock_option] ...\n\nalgorithm_option:\n    ALGORITHM [=] {DEFAULT | INPLACE | COPY}\n\nlock_option:\n    LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}\n\nDROP INDEX drops the index named index_name from the table tbl_name.\nThis statement is mapped to an ALTER TABLE statement to drop the index.\nSee [HELP ALTER TABLE].\n\nTo drop a primary key, the index name is always PRIMARY, which must be\nspecified as a quoted identifier because PRIMARY is a reserved word:\n\nDROP INDEX `PRIMARY` ON t;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-index.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-index.html'),
(531, 'DROP PROCEDURE', 40, 'Syntax:\nDROP {PROCEDURE | FUNCTION} [IF EXISTS] sp_name\n\nThese statements are used to drop a stored routine (a stored procedure\nor function). That is, the specified routine is removed from the\nserver. (DROP FUNCTION is also used to drop loadable functions; see\n[HELP DROP FUNCTION loadable function].)\n\nTo drop a stored routine, you must have the ALTER ROUTINE privilege for\nit. (If the automatic_sp_privileges system variable is enabled, that\nprivilege and EXECUTE are granted automatically to the routine creator\nwhen the routine is created and dropped from the creator when the\nroutine is dropped. See\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-routines-privileges.html\n.)\n\nIn addition, if the definer of the routine has the SYSTEM_USER\nprivilege, the user dropping it must also have this privilege. This is\nenforced in MySQL 8.0.16 and later.\n\nThe IF EXISTS clause is a MySQL extension. It prevents an error from\noccurring if the procedure or function does not exist. A warning is\nproduced that can be viewed with SHOW WARNINGS.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-procedure.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-procedure.html'),
(532, 'DROP FUNCTION', 40, 'Syntax:\nDROP {PROCEDURE | FUNCTION} [IF EXISTS] sp_name\n\nThese statements are used to drop a stored routine (a stored procedure\nor function). That is, the specified routine is removed from the\nserver. (DROP FUNCTION is also used to drop loadable functions; see\n[HELP DROP FUNCTION loadable function].)\n\nTo drop a stored routine, you must have the ALTER ROUTINE privilege for\nit. (If the automatic_sp_privileges system variable is enabled, that\nprivilege and EXECUTE are granted automatically to the routine creator\nwhen the routine is created and dropped from the creator when the\nroutine is dropped. See\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-routines-privileges.html\n.)\n\nIn addition, if the definer of the routine has the SYSTEM_USER\nprivilege, the user dropping it must also have this privilege. This is\nenforced in MySQL 8.0.16 and later.\n\nThe IF EXISTS clause is a MySQL extension. It prevents an error from\noccurring if the procedure or function does not exist. A warning is\nproduced that can be viewed with SHOW WARNINGS.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-procedure.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-procedure.html'),
(533, 'DROP SERVER', 40, 'Syntax:\nDROP SERVER [ IF EXISTS ] server_name\n\nDrops the server definition for the server named server_name. The\ncorresponding row in the mysql.servers table is deleted. This statement\nrequires the SUPER privilege.\n\nDropping a server for a table does not affect any FEDERATED tables that\nused this connection information when they were created. See [HELP\nCREATE SERVER].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-server.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-server.html'),
(534, 'DROP SPATIAL REFERENCE SYSTEM', 40, 'Syntax:\nDROP SPATIAL REFERENCE SYSTEM\n    [IF EXISTS]\n    srid\n\nsrid: 32-bit unsigned integer\n\nThis statement removes a spatial reference system (SRS) definition from\nthe data dictionary. It requires the SUPER privilege.\n\nExample:\n\nDROP SPATIAL REFERENCE SYSTEM 4120;\n\nIf no SRS definition with the SRID value exists, an error occurs unless\nIF EXISTS is specified. In that case, a warning occurs rather than an\nerror.\n\nIf the SRID value is used by some column in an existing table, an error\noccurs. For example:\n\nmysql> DROP SPATIAL REFERENCE SYSTEM 4326;\nERROR 3716 (SR005): Can\'t modify SRID 4326. There is at\nleast one column depending on it.\n\nTo identify which column or columns use the SRID, use this query:\n\nSELECT * FROM INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS WHERE SRS_ID=4326;\n\nSRID values must be in the range of 32-bit unsigned integers, with\nthese restrictions:\n\no SRID 0 is a valid SRID but cannot be used with DROP SPATIAL REFERENCE\n  SYSTEM.\n\no If the value is in a reserved SRID range, a warning occurs. Reserved\n  ranges are [0, 32767] (reserved by EPSG), [60,000,000, 69,999,999]\n  (reserved by EPSG), and [2,000,000,000, 2,147,483,647] (reserved by\n  MySQL). EPSG stands for the European Petroleum Survey Group\n  (http://epsg.org).\n\no Users should not drop SRSs with SRIDs in the reserved ranges. If\n  system-installed SRSs are dropped, the SRS definitions may be\n  recreated for MySQL upgrades.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-spatial-reference-system.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-spatial-reference-system.html'),
(535, 'DROP TABLE', 40, 'Syntax:\nDROP [TEMPORARY] TABLE [IF EXISTS]\n    tbl_name [, tbl_name] ...\n    [RESTRICT | CASCADE]\n\nDROP TABLE removes one or more tables. You must have the DROP privilege\nfor each table.\n\nBe careful with this statement! For each table, it removes the table\ndefinition and all table data. If the table is partitioned, the\nstatement removes the table definition, all its partitions, all data\nstored in those partitions, and all partition definitions associated\nwith the dropped table.\n\nDropping a table also drops any triggers for the table.\n\nDROP TABLE causes an implicit commit, except when used with the\nTEMPORARY keyword. See\nhttps://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\n*Important*:\n\nWhen a table is dropped, privileges granted specifically for the table\nare not automatically dropped. They must be dropped manually. See [HELP\nGRANT].\n\nIf any tables named in the argument list do not exist, DROP TABLE\nbehavior depends on whether the IF EXISTS clause is given:\n\no Without IF EXISTS, the statement fails with an error indicating which\n  nonexisting tables it was unable to drop, and no changes are made.\n\no With IF EXISTS, no error occurs for nonexisting tables. The statement\n  drops all named tables that do exist, and generates a NOTE diagnostic\n  for each nonexistent table. These notes can be displayed with SHOW\n  WARNINGS. See [HELP SHOW WARNINGS].\n\nIF EXISTS can also be useful for dropping tables in unusual\ncircumstances under which there is an entry in the data dictionary but\nno table managed by the storage engine. (For example, if an abnormal\nserver exit occurs after removal of the table from the storage engine\nbut before removal of the data dictionary entry.)\n\nThe TEMPORARY keyword has the following effects:\n\no The statement drops only TEMPORARY tables.\n\no The statement does not cause an implicit commit.\n\no No access rights are checked. A TEMPORARY table is visible only with\n  the session that created it, so no check is necessary.\n\nIncluding the TEMPORARY keyword is a good way to prevent accidentally\ndropping non-TEMPORARY tables.\n\nThe RESTRICT and CASCADE keywords do nothing. They are permitted to\nmake porting easier from other database systems.\n\nDROP TABLE is not supported with all innodb_force_recovery settings.\nSee\nhttps://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-table.html'),
(536, 'DROP TABLESPACE', 40, 'Syntax:\nDROP [UNDO] TABLESPACE tablespace_name\n    [ENGINE [=] engine_name]\n\nThis statement drops a tablespace that was previously created using\nCREATE TABLESPACE. It is supported by the NDB and InnoDB storage\nengines.\n\nThe UNDO keyword, introduced in MySQL 8.0.14, must be specified to drop\nan undo tablespace. Only undo tablespaces created using CREATE UNDO\nTABLESPACE syntax can be dropped. An undo tablespace must be in an\nempty state before it can be dropped. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html.\n\nENGINE sets the storage engine that uses the tablespace, where\nengine_name is the name of the storage engine. Currently, the values\nInnoDB and NDB are supported. If not set, the value of\ndefault_storage_engine is used. If it is not the same as the storage\nengine used to create the tablespace, the DROP TABLESPACE statement\nfails.\n\ntablespace_name is a case-sensitive identifier in MySQL.\n\nFor an InnoDB general tablespace, all tables must be dropped from the\ntablespace prior to a DROP TABLESPACE operation. If the tablespace is\nnot empty, DROP TABLESPACE returns an error.\n\nAn NDB tablespace to be dropped must not contain any data files; in\nother words, before you can drop an NDB tablespace, you must first drop\neach of its data files using ALTER TABLESPACE ... DROP DATAFILE.\n\nNotes\n\no A general InnoDB tablespace is not deleted automatically when the\n  last table in the tablespace is dropped. The tablespace must be\n  dropped explicitly using DROP TABLESPACE tablespace_name.\n\no A DROP DATABASE operation can drop tables that belong to a general\n  tablespace but it cannot drop the tablespace, even if the operation\n  drops all tables that belong to the tablespace. The tablespace must\n  be dropped explicitly using DROP TABLESPACE tablespace_name.\n\no Similar to the system tablespace, truncating or dropping tables\n  stored in a general tablespace creates free space internally in the\n  general tablespace .ibd data file which can only be used for new\n  InnoDB data. Space is not released back to the operating system as it\n  is for file-per-table tablespaces.\n\nInnoDB Examples\n\nThis example demonstrates how to drop an InnoDB general tablespace. The\ngeneral tablespace ts1 is created with a single table. Before dropping\nthe tablespace, the table must be dropped.\n\nmysql> CREATE TABLESPACE `ts1` ADD DATAFILE \'ts1.ibd\' Engine=InnoDB;\n\nmysql> CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1 Engine=InnoDB;\n\nmysql> DROP TABLE t1;\n\nmysql> DROP TABLESPACE ts1;\n\nThis example demonstrates dropping an undo tablespace. An undo\ntablespace must be in an empty state before it can be dropped. For more\ninformation, see\nhttps://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html.\n\nmysql> DROP UNDO TABLESPACE undo_003;\n\nNDB Example\n\nThis example shows how to drop an NDB tablespace myts having a data\nfile named mydata-1.dat after first creating the tablespace, and\nassumes the existence of a log file group named mylg (see [HELP CREATE\nLOGFILE GROUP]).\n\nmysql> CREATE TABLESPACE myts\n    ->     ADD DATAFILE \'mydata-1.dat\'\n    ->     USE LOGFILE GROUP mylg\n    ->     ENGINE=NDB;\n\nYou must remove all data files from the tablespace using ALTER\nTABLESPACE, as shown here, before it can be dropped:\n\nmysql> ALTER TABLESPACE myts\n    ->     DROP DATAFILE \'mydata-1.dat\'\n    ->     ENGINE=NDB;\n\nmysql> DROP TABLESPACE myts;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-tablespace.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-tablespace.html'),
(537, 'DROP TRIGGER', 40, 'Syntax:\nDROP TRIGGER [IF EXISTS] [schema_name.]trigger_name\n\nThis statement drops a trigger. The schema (database) name is optional.\nIf the schema is omitted, the trigger is dropped from the default\nschema. DROP TRIGGER requires the TRIGGER privilege for the table\nassociated with the trigger.\n\nUse IF EXISTS to prevent an error from occurring for a trigger that\ndoes not exist. A NOTE is generated for a nonexistent trigger when\nusing IF EXISTS. See [HELP SHOW WARNINGS].\n\nTriggers for a table are also dropped if you drop the table.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-trigger.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-trigger.html'),
(538, 'DROP VIEW', 40, 'Syntax:\nDROP VIEW [IF EXISTS]\n    view_name [, view_name] ...\n    [RESTRICT | CASCADE]\n\nDROP VIEW removes one or more views. You must have the DROP privilege\nfor each view.\n\nIf any views named in the argument list do not exist, the statement\nfails with an error indicating by name which nonexisting views it was\nunable to drop, and no changes are made.\n\n*Note*:\n\nIn MySQL 5.7 and earlier, DROP VIEW returns an error if any views named\nin the argument list do not exist, but also drops all views in the list\nthat do exist. Due to the change in behavior in MySQL 8.0, a partially\ncompleted DROP VIEW operation on a MySQL 5.7 replication source server\nfails when replicated on a MySQL 8.0 replica. To avoid this failure\nscenario, use IF EXISTS syntax in DROP VIEW statements to prevent an\nerror from occurring for views that do not exist. For more information,\nsee https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html.\n\nThe IF EXISTS clause prevents an error from occurring for views that\ndon\'t exist. When this clause is given, a NOTE is generated for each\nnonexistent view. See [HELP SHOW WARNINGS].\n\nRESTRICT and CASCADE, if given, are parsed and ignored.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/drop-view.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/drop-view.html'),
(539, 'RENAME TABLE', 40, 'Syntax:\nRENAME TABLE\n    tbl_name TO new_tbl_name\n    [, tbl_name2 TO new_tbl_name2] ...\n\nRENAME TABLE renames one or more tables. You must have ALTER and DROP\nprivileges for the original table, and CREATE and INSERT privileges for\nthe new table.\n\nFor example, to rename a table named old_table to new_table, use this\nstatement:\n\nRENAME TABLE old_table TO new_table;\n\nThat statement is equivalent to the following ALTER TABLE statement:\n\nALTER TABLE old_table RENAME new_table;\n\nRENAME TABLE, unlike ALTER TABLE, can rename multiple tables within a\nsingle statement:\n\nRENAME TABLE old_table1 TO new_table1,\n             old_table2 TO new_table2,\n             old_table3 TO new_table3;\n\nRenaming operations are performed left to right. Thus, to swap two\ntable names, do this (assuming that a table with the intermediary name\ntmp_table does not already exist):\n\nRENAME TABLE old_table TO tmp_table,\n             new_table TO old_table,\n             tmp_table TO new_table;\n\nMetadata locks on tables are acquired in name order, which in some\ncases can make a difference in operation outcome when multiple\ntransactions execute concurrently. See\nhttps://dev.mysql.com/doc/refman/8.0/en/metadata-locking.html.\n\nAs of MySQL 8.0.13, you can rename tables locked with a LOCK TABLES\nstatement, provided that they are locked with a WRITE lock or are the\nproduct of renaming WRITE-locked tables from earlier steps in a\nmultiple-table rename operation. For example, this is permitted:\n\nLOCK TABLE old_table1 WRITE;\nRENAME TABLE old_table1 TO new_table1,\n             new_table1 TO new_table2;\n\nThis is not permitted:\n\nLOCK TABLE old_table1 READ;\nRENAME TABLE old_table1 TO new_table1,\n             new_table1 TO new_table2;\n\nPrior to MySQL 8.0.13, to execute RENAME TABLE, there must be no tables\nlocked with LOCK TABLES.\n\nWith the transaction table locking conditions satisfied, the rename\noperation is done atomically; no other session can access any of the\ntables while the rename is in progress.\n\nIf any errors occur during a RENAME TABLE, the statement fails and no\nchanges are made.\n\nYou can use RENAME TABLE to move a table from one database to another:\n\nRENAME TABLE current_db.tbl_name TO other_db.tbl_name;\n\nUsing this method to move all tables from one database to a different\none in effect renames the database (an operation for which MySQL has no\nsingle statement), except that the original database continues to\nexist, albeit with no tables.\n\nLike RENAME TABLE, ALTER TABLE ... RENAME can also be used to move a\ntable to a different database. Regardless of the statement used, if the\nrename operation would move the table to a database located on a\ndifferent file system, the success of the outcome is platform specific\nand depends on the underlying operating system calls used to move table\nfiles.\n\nIf a table has triggers, attempts to rename the table into a different\ndatabase fail with a Trigger in wrong schema (ER_TRG_IN_WRONG_SCHEMA\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_trg_in_wrong_schema)) error.\n\nAn unencrypted table can be moved to an encryption-enabled database and\nvice versa. However, if the table_encryption_privilege_check variable\nis enabled, the TABLE_ENCRYPTION_ADMIN privilege is required if the\ntable encryption setting differs from the default database encryption.\n\nTo rename TEMPORARY tables, RENAME TABLE does not work. Use ALTER TABLE\ninstead.\n\nRENAME TABLE works for views, except that views cannot be renamed into\na different database.\n\nAny privileges granted specifically for a renamed table or view are not\nmigrated to the new name. They must be changed manually.\n\nRENAME TABLE tbl_name TO new_tbl_name changes internally generated\nforeign key constraint names and user-defined foreign key constraint\nnames that begin with the string \"tbl_name_ibfk_\" to reflect the new\ntable name. InnoDB interprets foreign key constraint names that begin\nwith the string \"tbl_name_ibfk_\" as internally generated names.\n\nForeign key constraint names that point to the renamed table are\nautomatically updated unless there is a conflict, in which case the\nstatement fails with an error. A conflict occurs if the renamed\nconstraint name already exists. In such cases, you must drop and\nre-create the foreign keys for them to function properly.\n\nRENAME TABLE tbl_name TO new_tbl_name changes internally generated and\nuser-defined CHECK constraint names that begin with the string\n\"tbl_name_chk_\" to reflect the new table name. MySQL interprets CHECK\nconstraint names that begin with the string \"tbl_name_chk_\" as\ninternally generated names. Example:\n\nmysql> SHOW CREATE TABLE t1\\G\n*************************** 1. row ***************************\n       Table: t1\nCreate Table: CREATE TABLE `t1` (\n  `i1` int(11) DEFAULT NULL,\n  `i2` int(11) DEFAULT NULL,\n  CONSTRAINT `t1_chk_1` CHECK ((`i1` > 0)),\n  CONSTRAINT `t1_chk_2` CHECK ((`i2` < 0))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci\n1 row in set (0.02 sec)\n\nmysql> RENAME TABLE t1 TO t3;\nQuery OK, 0 rows affected (0.03 sec)\n\nmysql> SHOW CREATE TABLE t3\\G\n*************************** 1. row ***************************\n       Table: t3\nCreate Table: CREATE TABLE `t3` (\n  `i1` int(11) DEFAULT NULL,\n  `i2` int(11) DEFAULT NULL,\n  CONSTRAINT `t3_chk_1` CHECK ((`i1` > 0)),\n  CONSTRAINT `t3_chk_2` CHECK ((`i2` < 0))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci\n1 row in set (0.01 sec)\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/rename-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/rename-table.html'),
(540, 'TRUNCATE TABLE', 40, 'Syntax:\nTRUNCATE [TABLE] tbl_name\n\nTRUNCATE TABLE empties a table completely. It requires the DROP\nprivilege. Logically, TRUNCATE TABLE is similar to a DELETE statement\nthat deletes all rows, or a sequence of DROP TABLE and CREATE TABLE\nstatements.\n\nTo achieve high performance, TRUNCATE TABLE bypasses the DML method of\ndeleting data. Thus, it does not cause ON DELETE triggers to fire, it\ncannot be performed for InnoDB tables with parent-child foreign key\nrelationships, and it cannot be rolled back like a DML operation.\nHowever, TRUNCATE TABLE operations on tables that use an atomic\nDDL-supported storage engine are either fully committed or rolled back\nif the server halts during their operation. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html.\n\nAlthough TRUNCATE TABLE is similar to DELETE, it is classified as a DDL\nstatement rather than a DML statement. It differs from DELETE in the\nfollowing ways:\n\no Truncate operations drop and re-create the table, which is much\n  faster than deleting rows one by one, particularly for large tables.\n\no Truncate operations cause an implicit commit, and so cannot be rolled\n  back. See\n  https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\no Truncation operations cannot be performed if the session holds an\n  active table lock.\n\no TRUNCATE TABLE fails for an InnoDB table or NDB table if there are\n  any FOREIGN KEY constraints from other tables that reference the\n  table. Foreign key constraints between columns of the same table are\n  permitted.\n\no Truncation operations do not return a meaningful value for the number\n  of deleted rows. The usual result is \"0 rows affected,\" which should\n  be interpreted as \"no information.\"\n\no As long as the table definition is valid, the table can be re-created\n  as an empty table with TRUNCATE TABLE, even if the data or index\n  files have become corrupted.\n\no Any AUTO_INCREMENT value is reset to its start value. This is true\n  even for MyISAM and InnoDB, which normally do not reuse sequence\n  values.\n\no When used with partitioned tables, TRUNCATE TABLE preserves the\n  partitioning; that is, the data and index files are dropped and\n  re-created, while the partition definitions are unaffected.\n\no The TRUNCATE TABLE statement does not invoke ON DELETE triggers.\n\no Truncating a corrupted InnoDB table is supported.\n\nTRUNCATE TABLE is treated for purposes of binary logging and\nreplication as DDL rather than DML, and is always logged as a\nstatement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/truncate-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/truncate-table.html'),
(541, 'CALL', 41, 'Syntax:\nCALL sp_name([parameter[,...]])\nCALL sp_name[()]\n\nThe CALL statement invokes a stored procedure that was defined\npreviously with CREATE PROCEDURE.\n\nStored procedures that take no arguments can be invoked without\nparentheses. That is, CALL p() and CALL p are equivalent.\n\nCALL can pass back values to its caller using parameters that are\ndeclared as OUT or INOUT parameters. When the procedure returns, a\nclient program can also obtain the number of rows affected for the\nfinal statement executed within the routine: At the SQL level, call the\nROW_COUNT() function; from the C API, call the mysql_affected_rows()\n(https://dev.mysql.com/doc/c-api/8.0/en/mysql-affected-rows.html)\nfunction.\n\nFor information about the effect of unhandled conditions on procedure\nparameters, see\nhttps://dev.mysql.com/doc/refman/8.0/en/conditions-and-parameters.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/call.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/call.html'),
(542, 'DELETE', 41, 'Syntax:\nDELETE is a DML statement that removes rows from a table.\n\nA DELETE statement can start with a WITH clause to define common table\nexpressions accessible within the DELETE. See\nhttps://dev.mysql.com/doc/refman/8.0/en/with.html.\n\nSingle-Table Syntax\n\nDELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM tbl_name [[AS] tbl_alias]\n    [PARTITION (partition_name [, partition_name] ...)]\n    [WHERE where_condition]\n    [ORDER BY ...]\n    [LIMIT row_count]\n\nThe DELETE statement deletes rows from tbl_name and returns the number\nof deleted rows. To check the number of deleted rows, call the\nROW_COUNT() function described in\nhttps://dev.mysql.com/doc/refman/8.0/en/information-functions.html.\n\nMain Clauses\n\nThe conditions in the optional WHERE clause identify which rows to\ndelete. With no WHERE clause, all rows are deleted.\n\nwhere_condition is an expression that evaluates to true for each row to\nbe deleted. It is specified as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/select.html.\n\nIf the ORDER BY clause is specified, the rows are deleted in the order\nthat is specified. The LIMIT clause places a limit on the number of\nrows that can be deleted. These clauses apply to single-table deletes,\nbut not multi-table deletes.\n\nMultiple-Table Syntax\n\nDELETE [LOW_PRIORITY] [QUICK] [IGNORE]\n    tbl_name[.*] [, tbl_name[.*]] ...\n    FROM table_references\n    [WHERE where_condition]\n\nDELETE [LOW_PRIORITY] [QUICK] [IGNORE]\n    FROM tbl_name[.*] [, tbl_name[.*]] ...\n    USING table_references\n    [WHERE where_condition]\n\nPrivileges\n\nYou need the DELETE privilege on a table to delete rows from it. You\nneed only the SELECT privilege for any columns that are only read, such\nas those named in the WHERE clause.\n\nPerformance\n\nWhen you do not need to know the number of deleted rows, the TRUNCATE\nTABLE statement is a faster way to empty a table than a DELETE\nstatement with no WHERE clause. Unlike DELETE, TRUNCATE TABLE cannot be\nused within a transaction or if you have a lock on the table. See [HELP\nTRUNCATE TABLE] and [HELP LOCK TABLES].\n\nThe speed of delete operations may also be affected by factors\ndiscussed in\nhttps://dev.mysql.com/doc/refman/8.0/en/delete-optimization.html.\n\nTo ensure that a given DELETE statement does not take too much time,\nthe MySQL-specific LIMIT row_count clause for DELETE specifies the\nmaximum number of rows to be deleted. If the number of rows to delete\nis larger than the limit, repeat the DELETE statement until the number\nof affected rows is less than the LIMIT value.\n\nSubqueries\n\nYou cannot delete from a table and select from the same table in a\nsubquery.\n\nPartitioned Table Support\n\nDELETE supports explicit partition selection using the PARTITION\nclause, which takes a list of the comma-separated names of one or more\npartitions or subpartitions (or both) from which to select rows to be\ndropped. Partitions not included in the list are ignored. Given a\npartitioned table t with a partition named p0, executing the statement\nDELETE FROM t PARTITION (p0) has the same effect on the table as\nexecuting ALTER TABLE t TRUNCATE PARTITION (p0); in both cases, all\nrows in partition p0 are dropped.\n\nPARTITION can be used along with a WHERE condition, in which case the\ncondition is tested only on rows in the listed partitions. For example,\nDELETE FROM t PARTITION (p0) WHERE c < 5 deletes rows only from\npartition p0 for which the condition c < 5 is true; rows in any other\npartitions are not checked and thus not affected by the DELETE.\n\nThe PARTITION clause can also be used in multiple-table DELETE\nstatements. You can use up to one such option per table named in the\nFROM option.\n\nFor more information and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/delete.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/delete.html'),
(543, 'DO', 41, 'Syntax:\nDO expr [, expr] ...\n\nDO executes the expressions but does not return any results. In most\nrespects, DO is shorthand for SELECT expr, ..., but has the advantage\nthat it is slightly faster when you do not care about the result.\n\nDO is useful primarily with functions that have side effects, such as\nRELEASE_LOCK().\n\nExample: This SELECT statement pauses, but also produces a result set:\n\nmysql> SELECT SLEEP(5);\n+----------+\n| SLEEP(5) |\n+----------+\n|        0 |\n+----------+\n1 row in set (5.02 sec)\n\nDO, on the other hand, pauses without producing a result set.:\n\nmysql> DO SLEEP(5);\nQuery OK, 0 rows affected (4.99 sec)\n\nThis could be useful, for example in a stored function or trigger,\nwhich prohibit statements that produce result sets.\n\nDO only executes expressions. It cannot be used in all cases where\nSELECT can be used. For example, DO id FROM t1 is invalid because it\nreferences a table.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/do.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/do.html'),
(544, 'EXCEPT', 41, 'Syntax:\nquery_expression_body EXCEPT [ALL | DISTINCT] query_expression_body\n    [EXCEPT [ALL | DISTINCT] query_expression_body]\n    [...]\n\nquery_expression_body:\n    See \n\nEXCEPT limits the result from the first query block to those rows which\nare (also) not found in the second. As with UNION and INTERSECT, either\nquery block can make use of any of SELECT, TABLE, or VALUES. An example\nusing the tables a, b, and c defined in [HELP INTERSECT], is shown\nhere:\n\nmysql> TABLE a EXCEPT TABLE b;\n+------+------+\n| m    | n    |\n+------+------+\n|    2 |    3 |\n+------+------+\n1 row in set (0.00 sec)\n\nmysql> TABLE a EXCEPT TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n|    2 |    3 |\n+------+------+\n2 rows in set (0.00 sec)\n\nmysql> TABLE b EXCEPT TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n+------+------+\n1 row in set (0.00 sec)\n\nAs with UNION and INTERSECT, if neither DISTINCT nor ALL is specified,\nthe default is DISTINCT.\n\nDISTINCT removes duplicates found on either side of the relation, as\nshown here:\n\nmysql> TABLE c EXCEPT DISTINCT TABLE a;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n+------+------+\n1 row in set (0.00 sec)\n\nmysql> TABLE c EXCEPT ALL TABLE a;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n|    1 |    3 |\n+------+------+\n2 rows in set (0.00 sec)\n\n(The first statement has the same effect as TABLE c EXCEPT TABLE a.)\n\nUnlike UNION or INTERSECT, EXCEPT is not commutative---that is, the\nresult depends on the order of the operands, as shown here:\n\nmysql> TABLE a EXCEPT TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n|    2 |    3 |\n+------+------+\n2 rows in set (0.00 sec)\n\nmysql> TABLE c EXCEPT TABLE a;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n+------+------+\n1 row in set (0.00 sec)\n\nAs with UNION, the result sets to be compared must have the same number\nof columns. Result set column types are also determined as for UNION.\n\nEXCEPT was added in MySQL 8.0.31.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/except.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/except.html'),
(545, 'HANDLER', 41, 'Syntax:\nHANDLER tbl_name OPEN [ [AS] alias]\n\nHANDLER tbl_name READ index_name { = | <= | >= | < | > } (value1,value2,...)\n    [ WHERE where_condition ] [LIMIT ... ]\nHANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST }\n    [ WHERE where_condition ] [LIMIT ... ]\nHANDLER tbl_name READ { FIRST | NEXT }\n    [ WHERE where_condition ] [LIMIT ... ]\n\nHANDLER tbl_name CLOSE\n\nThe HANDLER statement provides direct access to table storage engine\ninterfaces. It is available for InnoDB and MyISAM tables.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/handler.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/handler.html'),
(546, 'IMPORT TABLE', 41, 'Syntax:\nIMPORT TABLE FROM sdi_file [, sdi_file] ...\n\nThe IMPORT TABLE statement imports MyISAM tables based on information\ncontained in .sdi (serialized dictionary information) metadata files.\nIMPORT TABLE requires the FILE privilege to read the .sdi and table\ncontent files, and the CREATE privilege for the table to be created.\n\nTables can be exported from one server using mysqldump to write a file\nof SQL statements and imported into another server using mysql to\nprocess the dump file. IMPORT TABLE provides a faster alternative using\nthe \"raw\" table files.\n\nPrior to import, the files that provide the table content must be\nplaced in the appropriate schema directory for the import server, and\nthe .sdi file must be located in a directory accessible to the server.\nFor example, the .sdi file can be placed in the directory named by the\nsecure_file_priv system variable, or (if secure_file_priv is empty) in\na directory under the server data directory.\n\nThe following example describes how to export MyISAM tables named\nemployees and managers from the hr schema of one server and import them\ninto the hr schema of another server. The example uses these\nassumptions (to perform a similar operation on your own system, modify\nthe path names as appropriate):\n\no For the export server, export_basedir represents its base directory,\n  and its data directory is export_basedir/data.\n\no For the import server, import_basedir represents its base directory,\n  and its data directory is import_basedir/data.\n\no Table files are exported from the export server into the /tmp/export\n  directory and this directory is secure (not accessible to other\n  users).\n\no The import server uses /tmp/mysql-files as the directory named by its\n  secure_file_priv system variable.\n\nTo export tables from the export server, use this procedure:\n\n1. Ensure a consistent snapshot by executing this statement to lock the\n   tables so that they cannot be modified during export:\n\nmysql> FLUSH TABLES hr.employees, hr.managers WITH READ LOCK;\n\n   While the lock is in effect, the tables can still be used, but only\n   for read access.\n\n2. At the file system level, copy the .sdi and table content files from\n   the hr schema directory to the secure export directory:\n\n  o The .sdi file is located in the hr schema directory, but might not\n    have exactly the same basename as the table name. For example, the\n    .sdi files for the employees and managers tables might be named\n    employees_125.sdi and managers_238.sdi.\n\n  o For a MyISAM table, the content files are its .MYD data file and\n    .MYI index file.\n\n   Given those file names, the copy commands look like this:\n\n$> cd export_basedir/data/hr\n$> cp employees_125.sdi /tmp/export\n$> cp managers_238.sdi /tmp/export\n$> cp employees.{MYD,MYI} /tmp/export\n$> cp managers.{MYD,MYI} /tmp/export\n\n3. Unlock the tables:\n\nmysql> UNLOCK TABLES;\n\nTo import tables into the import server, use this procedure:\n\n1. The import schema must exist. If necessary, execute this statement\n   to create it:\n\nmysql> CREATE SCHEMA hr;\n\n2. At the file system level, copy the .sdi files to the import server\n   secure_file_priv directory, /tmp/mysql-files. Also, copy the table\n   content files to the hr schema directory:\n\n$> cd /tmp/export\n$> cp employees_125.sdi /tmp/mysql-files\n$> cp managers_238.sdi /tmp/mysql-files\n$> cp employees.{MYD,MYI} import_basedir/data/hr\n$> cp managers.{MYD,MYI} import_basedir/data/hr\n\n3. Import the tables by executing an IMPORT TABLE statement that names\n   the .sdi files:\n\nmysql> IMPORT TABLE FROM\n       \'/tmp/mysql-files/employees.sdi\',\n       \'/tmp/mysql-files/managers.sdi\';\n\nThe .sdi file need not be placed in the import server directory named\nby the secure_file_priv system variable if that variable is empty; it\ncan be in any directory accessible to the server, including the schema\ndirectory for the imported table. If the .sdi file is placed in that\ndirectory, however, it may be rewritten; the import operation creates a\nnew .sdi file for the table, which overwrites the old .sdi file if the\noperation uses the same file name for the new file.\n\nEach sdi_file value must be a string literal that names the .sdi file\nfor a table or is a pattern that matches .sdi files. If the string is a\npattern, any leading directory path and the .sdi file name suffix must\nbe given literally. Pattern characters are permitted only in the base\nname part of the file name:\n\no ? matches any single character\n\no * matches any sequence of characters, including no characters\n\nUsing a pattern, the previous IMPORT TABLE statement could have been\nwritten like this (assuming that the /tmp/mysql-files directory\ncontains no other .sdi files matching the pattern):\n\nIMPORT TABLE FROM \'/tmp/mysql-files/*.sdi\';\n\nTo interpret the location of .sdi file path names, the server uses the\nsame rules for IMPORT TABLE as the server-side rules for LOAD DATA\n(that is, the non-LOCAL rules). See [HELP LOAD DATA], paying particular\nattention to the rules used to interpret relative path names.\n\nIMPORT TABLE fails if the .sdi or table files cannot be located. After\nimporting a table, the server attempts to open it and reports as\nwarnings any problems detected. To attempt a repair to correct any\nreported issues, use REPAIR TABLE.\n\nIMPORT TABLE is not written to the binary log.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/import-table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/import-table.html'),
(547, 'INSERT', 41, 'Syntax:\nINSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [(col_name [, col_name] ...)]\n    { {VALUES | VALUE} (value_list) [, (value_list)] ... }\n    [AS row_alias[(col_alias [, col_alias] ...)]]\n    [ON DUPLICATE KEY UPDATE assignment_list]\n\nINSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    SET assignment_list\n    [AS row_alias[(col_alias [, col_alias] ...)]]\n    [ON DUPLICATE KEY UPDATE assignment_list]\n\nINSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [(col_name [, col_name] ...)]\n    { SELECT ... \n      | TABLE table_name \n      | VALUES row_constructor_list\n    }\n    [ON DUPLICATE KEY UPDATE assignment_list]\n\nvalue:\n    {expr | DEFAULT}\n\nvalue_list:\n    value [, value] ...\n\nrow_constructor_list:\n    ROW(value_list)[, ROW(value_list)][, ...]\n\nassignment:\n    col_name = \n          value\n        | [row_alias.]col_name\n        | [tbl_name.]col_name\n        | [row_alias.]col_alias\n\nassignment_list:\n    assignment [, assignment] ...\n\nINSERT inserts new rows into an existing table. The INSERT ... VALUES,\nINSERT ... VALUES ROW(), and INSERT ... SET forms of the statement\ninsert rows based on explicitly specified values. The INSERT ... SELECT\nform inserts rows selected from another table or tables. You can also\nuse INSERT ... TABLE in MySQL 8.0.19 and later to insert rows from a\nsingle table. INSERT with an ON DUPLICATE KEY UPDATE clause enables\nexisting rows to be updated if a row to be inserted would cause a\nduplicate value in a UNIQUE index or PRIMARY KEY. In MySQL 8.0.19 and\nlater, a row alias with one or more optional column aliases can be used\nwith ON DUPLICATE KEY UPDATE to refer to the row to be inserted.\n\nFor additional information about INSERT ... SELECT and INSERT ... ON\nDUPLICATE KEY UPDATE, see [HELP INSERT SELECT], and\nhttps://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html.\n\nIn MySQL 8.0, the DELAYED keyword is accepted but ignored by the\nserver. For the reasons for this, see [HELP INSERT DELAYED],\n\nInserting into a table requires the INSERT privilege for the table. If\nthe ON DUPLICATE KEY UPDATE clause is used and a duplicate key causes\nan UPDATE to be performed instead, the statement requires the UPDATE\nprivilege for the columns to be updated. For columns that are read but\nnot modified you need only the SELECT privilege (such as for a column\nreferenced only on the right hand side of an col_name=expr assignment\nin an ON DUPLICATE KEY UPDATE clause).\n\nWhen inserting into a partitioned table, you can control which\npartitions and subpartitions accept new rows. The PARTITION clause\ntakes a list of the comma-separated names of one or more partitions or\nsubpartitions (or both) of the table. If any of the rows to be inserted\nby a given INSERT statement do not match one of the partitions listed,\nthe INSERT statement fails with the error Found a row not matching the\ngiven partition set. For more information and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/insert.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/insert.html'),
(548, 'INSERT SELECT', 41, 'Syntax:\nINSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [(col_name [, col_name] ...)]\n    {   SELECT ... \n      | TABLE table_name \n      | VALUES row_constructor_list\n    }\n    [ON DUPLICATE KEY UPDATE assignment_list]\n\n\nvalue:\n    {expr | DEFAULT}\n\nvalue_list:\n    value [, value] ...\n\nrow_constructor_list:\n    ROW(value_list)[, ROW(value_list)][, ...]\n\nassignment:\n    col_name = \n          value\n        | [row_alias.]col_name\n        | [tbl_name.]col_name\n        | [row_alias.]col_alias\n\nassignment_list:\n    assignment [, assignment] ...\n\nWith INSERT ... SELECT, you can quickly insert many rows into a table\nfrom the result of a SELECT statement, which can select from one or\nmany tables. For example:\n\nINSERT INTO tbl_temp2 (fld_id)\n  SELECT tbl_temp1.fld_order_id\n  FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;\n\nBeginning with MySQL 8.0.19, you can use a TABLE statement in place of\nSELECT, as shown here:\n\nINSERT INTO ta TABLE tb;\n\nTABLE tb is equivalent to SELECT * FROM tb. It can be useful when\ninserting all columns from the source table into the target table, and\nno filtering with WHERE is required. In addition, the rows from TABLE\ncan be ordered by one or more columns using ORDER BY, and the number of\nrows inserted can be limited using a LIMIT clause. For more\ninformation, see [HELP TABLE].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/insert-select.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/insert-select.html'),
(549, 'INSERT DELAYED', 41, 'Syntax:\nINSERT DELAYED ...\n\nThe DELAYED option for the INSERT statement is a MySQL extension to\nstandard SQL. In previous versions of MySQL, it can be used for certain\nkinds of tables (such as MyISAM), such that when a client uses INSERT\nDELAYED, it gets an okay from the server at once, and the row is queued\nto be inserted when the table is not in use by any other thread.\n\nDELAYED inserts and replaces were deprecated in MySQL 5.6. In MySQL\n8.0, DELAYED is not supported. The server recognizes but ignores the\nDELAYED keyword, handles the insert as a nondelayed insert, and\ngenerates an ER_WARN_LEGACY_SYNTAX_CONVERTED warning: INSERT DELAYED is\nno longer supported. The statement was converted to INSERT. The DELAYED\nkeyword is scheduled for removal in a future release.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/insert-delayed.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/insert-delayed.html'),
(550, 'INTERSECT', 41, 'Syntax:\nquery_expression_body INTERSECT [ALL | DISTINCT] query_expression_body\n    [INTERSECT [ALL | DISTINCT] query_expression_body]\n    [...]\n\nquery_expression_body:\n    See \n\nINTERSECT limits the result from multiple query blocks to those rows\nwhich are common to all. Example:\n\nmysql> TABLE a;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n|    2 |    3 |\n|    3 |    4 |\n+------+------+\n3 rows in set (0.00 sec)\n\nmysql> TABLE b;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n|    1 |    3 |\n|    3 |    4 |\n+------+------+\n3 rows in set (0.00 sec)\n\nmysql> TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n|    1 |    3 |\n|    3 |    4 |\n+------+------+\n3 rows in set (0.00 sec)\n\nmysql> TABLE a INTERSECT TABLE b;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    2 |\n|    3 |    4 |\n+------+------+\n2 rows in set (0.00 sec)\n\nmysql> TABLE a INTERSECT TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    3 |    4 |\n+------+------+\n1 row in set (0.00 sec)\n\nAs with UNION and EXCEPT, if neither DISTINCT nor ALL is specified, the\ndefault is DISTINCT.\n\nDISTINCT can remove duplicates from either side of the intersection, as\nshown here:\n\nmysql> TABLE c INTERSECT DISTINCT TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n|    3 |    4 |\n+------+------+\n2 rows in set (0.00 sec)\n\nmysql> TABLE c INTERSECT ALL TABLE c;\n+------+------+\n| m    | n    |\n+------+------+\n|    1 |    3 |\n|    1 |    3 |\n|    3 |    4 |\n+------+------+\n3 rows in set (0.00 sec)\n\n(TABLE c INTERSECT TABLE c is the equivalent of the first of the two\nstatements just shown.)\n\nAs with UNION, the operands must have the same number of columns.\nResult set column types are also determined as for UNION.\n\nINTERSECT has greater precedence than and is evaluated before UNION and\nEXCEPT, so that the two statements shown here are equivalent:\n\nTABLE r EXCEPT TABLE s INTERSECT TABLE t;\n\nTABLE r EXCEPT (TABLE s INTERSECT TABLE t);\n\nFor INTERSECT ALL, the maximum supported number of duplicates of any\nunique row in the left hand table is 4294967295.\n\nINTERSECT was added in MySQL 8.0.31.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/intersect.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/intersect.html'),
(551, 'LOAD DATA', 41, 'Syntax:\nLOAD DATA\n    [LOW_PRIORITY | CONCURRENT] [LOCAL]\n    INFILE \'file_name\'\n    [REPLACE | IGNORE]\n    INTO TABLE tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [CHARACTER SET charset_name]\n    [{FIELDS | COLUMNS}\n        [TERMINATED BY \'string\']\n        [[OPTIONALLY] ENCLOSED BY \'char\']\n        [ESCAPED BY \'char\']\n    ]\n    [LINES\n        [STARTING BY \'string\']\n        [TERMINATED BY \'string\']\n    ]\n    [IGNORE number {LINES | ROWS}]\n    [(col_name_or_user_var\n        [, col_name_or_user_var] ...)]\n    [SET col_name={expr | DEFAULT}\n        [, col_name={expr | DEFAULT}] ...]\n\nThe LOAD DATA statement reads rows from a text file into a table at a\nvery high speed. The file can be read from the server host or the\nclient host, depending on whether the LOCAL modifier is given. LOCAL\nalso affects data interpretation and error handling.\n\nLOAD DATA is the complement of SELECT ... INTO OUTFILE. (See\nhttps://dev.mysql.com/doc/refman/8.0/en/select-into.html.) To write\ndata from a table to a file, use SELECT ... INTO OUTFILE. To read the\nfile back into a table, use LOAD DATA. The syntax of the FIELDS and\nLINES clauses is the same for both statements.\n\nThe mysqlimport utility provides another way to load data files; it\noperates by sending a LOAD DATA statement to the server. See\nhttps://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html.\n\nFor information about the efficiency of INSERT versus LOAD DATA and\nspeeding up LOAD DATA, see\nhttps://dev.mysql.com/doc/refman/8.0/en/insert-optimization.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/load-data.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/load-data.html'),
(552, 'LOAD XML', 41, 'Syntax:\nLOAD XML\n    [LOW_PRIORITY | CONCURRENT] [LOCAL]\n    INFILE \'file_name\'\n    [REPLACE | IGNORE]\n    INTO TABLE [db_name.]tbl_name\n    [CHARACTER SET charset_name]\n    [ROWS IDENTIFIED BY \'<tagname>\']\n    [IGNORE number {LINES | ROWS}]\n    [(field_name_or_user_var\n        [, field_name_or_user_var] ...)]\n    [SET col_name={expr | DEFAULT}\n        [, col_name={expr | DEFAULT}] ...]\n\nThe LOAD XML statement reads data from an XML file into a table. The\nfile_name must be given as a literal string. The tagname in the\noptional ROWS IDENTIFIED BY clause must also be given as a literal\nstring, and must be surrounded by angle brackets (< and >).\n\nLOAD XML acts as the complement of running the mysql client in XML\noutput mode (that is, starting the client with the --xml option). To\nwrite data from a table to an XML file, you can invoke the mysql client\nwith the --xml and -e options from the system shell, as shown here:\n\n$> mysql --xml -e \'SELECT * FROM mydb.mytable\' > file.xml\n\nTo read the file back into a table, use LOAD XML. By default, the <row>\nelement is considered to be the equivalent of a database table row;\nthis can be changed using the ROWS IDENTIFIED BY clause.\n\nThis statement supports three different XML formats:\n\no Column names as attributes and column values as attribute values:\n\n<row column1=\"value1\" column2=\"value2\" .../>\n\no Column names as tags and column values as the content of these tags:\n\n<row>\n  <column1>value1</column1>\n  <column2>value2</column2>\n</row>\n\no Column names are the name attributes of <field> tags, and values are\n  the contents of these tags:\n\n<row>\n  <field name=\'column1\'>value1</field>\n  <field name=\'column2\'>value2</field>\n</row>\n\n  This is the format used by other MySQL tools, such as mysqldump.\n\nAll three formats can be used in the same XML file; the import routine\nautomatically detects the format for each row and interprets it\ncorrectly. Tags are matched based on the tag or attribute name and the\ncolumn name.\n\nPrior to MySQL 8.0.21, LOAD XML did not support CDATA sections in the\nsource XML. (Bug #30753708, Bug #98199)\n\nThe following clauses work essentially the same way for LOAD XML as\nthey do for LOAD DATA:\n\no LOW_PRIORITY or CONCURRENT\n\no LOCAL\n\no REPLACE or IGNORE\n\no CHARACTER SET\n\no SET\n\nSee [HELP LOAD DATA], for more information about these clauses.\n\n(field_name_or_user_var, ...) is a list of one or more comma-separated\nXML fields or user variables. The name of a user variable used for this\npurpose must match the name of a field from the XML file, prefixed with\n@. You can use field names to select only desired fields. User\nvariables can be employed to store the corresponding field values for\nsubsequent re-use.\n\nThe IGNORE number LINES or IGNORE number ROWS clause causes the first\nnumber rows in the XML file to be skipped. It is analogous to the LOAD\nDATA statement\'s IGNORE ... LINES clause.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/load-xml.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/load-xml.html'),
(553, 'PARENTHESIZED QUERY EXPRESSIONS', 41, 'Syntax:\nparenthesized_query_expression:\n    ( query_expression [order_by_clause] [limit_clause] )\n      [order_by_clause]\n      [limit_clause]\n      [into_clause]\n\nquery_expression:\n    query_block [set_op query_block [set_op query_block ...]]\n      [order_by_clause]\n      [limit_clause]\n      [into_clause]\n\nquery_block:\n    SELECT ... | TABLE | VALUES\n\norder_by_clause:\n    ORDER BY as for SELECT\n\nlimit_clause:\n    LIMIT as for SELECT\n\ninto_clause:\n    INTO as for SELECT\n\nset_op:\n    UNION | INTERSECT | EXCEPT\n\nMySQL 8.0.22 and higher supports parenthesized query expressions\naccording to the preceding syntax. At its simplest, a parenthesized\nquery expression contains a single SELECT or other statement returning\na result set and no following optional clauses:\n\n(SELECT 1);\n(SELECT * FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = \'mysql\');\n\nTABLE t;\n\nVALUES ROW(2, 3, 4), ROW(1, -2, 3);\n\n(Support for the TABLE and VALUES statements is available beginning\nwith MySQL 8.0.19.)\n\nA parenthesized query expression can also contain queries linked by one\nor more set operations such as UNION, and end with any or all of the\noptional clauses:\n\nmysql> (SELECT 1 AS result UNION SELECT 2);\n+--------+\n| result |\n+--------+\n|      1 |\n|      2 |\n+--------+\nmysql> (SELECT 1 AS result UNION SELECT 2) LIMIT 1;\n+--------+\n| result |\n+--------+\n|      1 |\n+--------+\nmysql> (SELECT 1 AS result UNION SELECT 2) LIMIT 1 OFFSET 1;\n+--------+\n| result |\n+--------+\n|      2 |\n+--------+\nmysql> (SELECT 1 AS result UNION SELECT 2)\n       ORDER BY result DESC LIMIT 1;\n+--------+\n| result |\n+--------+\n|      2 |\n+--------+\nmysql> (SELECT 1 AS result UNION SELECT 2)\n       ORDER BY result DESC LIMIT 1 OFFSET 1;\n+--------+\n| result |\n+--------+\n|      1 |\n+--------+\nmysql> (SELECT 1 AS result UNION SELECT 3 UNION SELECT 2)\n       ORDER BY result LIMIT 1 OFFSET 1 INTO @var;\nmysql> SELECT @var;\n+------+\n| @var |\n+------+\n|    2 |\n+------+\n\nIn addition to UNION, the INTERSECT and EXCEPT set operators are\navailable beginning with MySQL 8.0.31. INTERSECT acts before UNION and\nEXCEPT, so that the following two statements are equivalent:\n\nSELECT a FROM t1 EXCEPT SELECT b FROM t2 INTERSECT SELECT c FROM t3;\n\nSELECT a FROM t1 EXCEPT (SELECT b FROM t2 INTERSECT SELECT c FROM t3);\n\nParenthesized query expressions are also used as query expressions, so\na query expression, usually composed of query blocks, may also consist\nof parenthesized query expressions:\n\n(TABLE t1 ORDER BY a) UNION (TABLE t2 ORDER BY b) ORDER BY z;\n\nQuery blocks may have trailing ORDER BY and LIMIT clauses, which are\napplied before the outer set operation, ORDER BY, and LIMIT.\n\nYou cannot have a query block with a trailing ORDER BY or LIMIT without\nwrapping it in parentheses but parentheses may be used for enforcement\nin various ways:\n\no To enforce LIMIT on each query block:\n\n(SELECT 1 LIMIT 1) UNION (VALUES ROW(2) LIMIT 1);\n\n(VALUES ROW(1), ROW(2) LIMIT 2) EXCEPT (SELECT 2 LIMIT 1);\n\no To enforce LIMIT on both query blocks and the entire query\n  expression:\n\n(SELECT 1 LIMIT 1) UNION (SELECT 2 LIMIT 1) LIMIT 1;\n\no To enforce LIMIT on the entire query expression (with no\n  parentheses):\n\nVALUES ROW(1), ROW(2) INTERSECT VALUES ROW(2), ROW(1) LIMIT 1;\n\no Hybrid enforcement: LIMIT on the first query block and on the entire\n  query expression:\n\n(SELECT 1 LIMIT 1) UNION SELECT 2 LIMIT 1;\n\nThe syntax described in this section is subject to certain\nrestrictions:\n\no A trailing INTO clause for a query expression is not permitted if\n  there is another INTO clause inside parentheses.\n\no Prior to MySQL 8.0.31, when ORDER BY or LIMIT occurred within a\n  parenthesized query expression and was also applied in the outer\n  query, the result was undefined. This is not an issue in MySQL 8.0.31\n  and later, where this is handled in accordance with the SQL standard.\n\n  Prior to MySQL 8.0.31, parenthesized query expressions did not permit\n  multiple levels of ORDER BY or LIMIT operations, and statements\n  containing these were rejected with ER_NOT_SUPPORTED_YET\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_not_supported_yet). In MySQL 8.0.31 and later, this\n  restriction is lifted, and nested parenthesized query expressions are\n  permitted. The maximum level of nesting supported is 63; this is\n  after any simplifications or merges have been performed by the\n  parser.\n\n  An example of such a statement is shown here:\n\nmysql> (SELECT \'a\' UNION SELECT \'b\' LIMIT 2) LIMIT 3;\n+---+\n| a |\n+---+\n| a |\n| b |\n+---+\n2 rows in set (0.00 sec)\n\n  You should be aware that, in MySQL 8.0.31 and later, when collapsing\n  parenthesized expression bodies, MySQL follows SQL standard\n  semantics, so that a higher outer limit cannot override an inner\n  lower one. For example, (SELECT ... LIMIT 5) LIMIT 10 can return no\n  more than five rows.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/parenthesized-query-expressions.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/parenthesized-query-expressions.html'),
(554, 'REPLACE', 41, 'Syntax:\nREPLACE [LOW_PRIORITY | DELAYED]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [(col_name [, col_name] ...)]\n    { {VALUES | VALUE} (value_list) [, (value_list)] ...\n      |\n      VALUES row_constructor_list\n    }\n\nREPLACE [LOW_PRIORITY | DELAYED]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    SET assignment_list\n\nREPLACE [LOW_PRIORITY | DELAYED]\n    [INTO] tbl_name\n    [PARTITION (partition_name [, partition_name] ...)]\n    [(col_name [, col_name] ...)]\n    {SELECT ... | TABLE table_name}\n\nvalue:\n    {expr | DEFAULT}\n\nvalue_list:\n    value [, value] ...\n\nrow_constructor_list:\n    ROW(value_list)[, ROW(value_list)][, ...]\n\nassignment:\n    col_name = value\n\nassignment_list:\n    assignment [, assignment] ...\n\nREPLACE works exactly like INSERT, except that if an old row in the\ntable has the same value as a new row for a PRIMARY KEY or a UNIQUE\nindex, the old row is deleted before the new row is inserted. See [HELP\nINSERT].\n\nREPLACE is a MySQL extension to the SQL standard. It either inserts, or\ndeletes and inserts. For another MySQL extension to standard SQL---that\neither inserts or updates---see\nhttps://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html.\n\nDELAYED inserts and replaces were deprecated in MySQL 5.6. In MySQL\n8.0, DELAYED is not supported. The server recognizes but ignores the\nDELAYED keyword, handles the replace as a nondelayed replace, and\ngenerates an ER_WARN_LEGACY_SYNTAX_CONVERTED warning: REPLACE DELAYED\nis no longer supported. The statement was converted to REPLACE. The\nDELAYED keyword is scheduled for removal in a future release. release.\n\n*Note*:\n\nREPLACE makes sense only if a table has a PRIMARY KEY or UNIQUE index.\nOtherwise, it becomes equivalent to INSERT, because there is no index\nto be used to determine whether a new row duplicates another.\n\nValues for all columns are taken from the values specified in the\nREPLACE statement. Any missing columns are set to their default values,\njust as happens for INSERT. You cannot refer to values from the current\nrow and use them in the new row. If you use an assignment such as SET\ncol_name = col_name + 1, the reference to the column name on the right\nhand side is treated as DEFAULT(col_name), so the assignment is\nequivalent to SET col_name = DEFAULT(col_name) + 1.\n\nIn MySQL 8.0.19 and later, you can specify the column values that\nREPLACE attempts to insert using VALUES ROW().\n\nTo use REPLACE, you must have both the INSERT and DELETE privileges for\nthe table.\n\nIf a generated column is replaced explicitly, the only permitted value\nis DEFAULT. For information about generated columns, see\nhttps://dev.mysql.com/doc/refman/8.0/en/create-table-generated-columns.\nhtml.\n\nREPLACE supports explicit partition selection using the PARTITION\nclause with a list of comma-separated names of partitions,\nsubpartitions, or both. As with INSERT, if it is not possible to insert\nthe new row into any of these partitions or subpartitions, the REPLACE\nstatement fails with the error Found a row not matching the given\npartition set. For more information and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/replace.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/replace.html'),
(555, 'SELECT', 41, 'Syntax:\nSELECT\n    [ALL | DISTINCT | DISTINCTROW ]\n    [HIGH_PRIORITY]\n    [STRAIGHT_JOIN]\n    [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]\n    [SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]\n    select_expr [, select_expr] ...\n    [into_option]\n    [FROM table_references\n      [PARTITION partition_list]]\n    [WHERE where_condition]\n    [GROUP BY {col_name | expr | position}, ... [WITH ROLLUP]]\n    [HAVING where_condition]\n    [WINDOW window_name AS (window_spec)\n        [, window_name AS (window_spec)] ...]\n    [ORDER BY {col_name | expr | position}\n      [ASC | DESC], ... [WITH ROLLUP]]\n    [LIMIT {[offset,] row_count | row_count OFFSET offset}]\n    [into_option]\n    [FOR {UPDATE | SHARE}\n        [OF tbl_name [, tbl_name] ...]\n        [NOWAIT | SKIP LOCKED]\n      | LOCK IN SHARE MODE]\n    [into_option]\n\ninto_option: {\n    INTO OUTFILE \'file_name\'\n        [CHARACTER SET charset_name]\n        export_options\n  | INTO DUMPFILE \'file_name\'\n  | INTO var_name [, var_name] ...\n}\n\nSELECT is used to retrieve rows selected from one or more tables, and\ncan include UNION operations and subqueries. Beginning with MySQL\n8.0.31, INTERSECT and EXCEPT operations are also supported. The UNION,\nINTERSECT, and EXCEPT operators are described in more detail later in\nthis section. See also\nhttps://dev.mysql.com/doc/refman/8.0/en/subqueries.html.\n\nA SELECT statement can start with a WITH clause to define common table\nexpressions accessible within the SELECT. See\nhttps://dev.mysql.com/doc/refman/8.0/en/with.html.\n\nThe most commonly used clauses of SELECT statements are these:\n\no Each select_expr indicates a column that you want to retrieve. There\n  must be at least one select_expr.\n\no table_references indicates the table or tables from which to retrieve\n  rows. Its syntax is described in [HELP JOIN].\n\no SELECT supports explicit partition selection using the PARTITION\n  clause with a list of partitions or subpartitions (or both) following\n  the name of the table in a table_reference (see [HELP JOIN]). In this\n  case, rows are selected only from the partitions listed, and any\n  other partitions of the table are ignored. For more information and\n  examples, see\n  https://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\no The WHERE clause, if given, indicates the condition or conditions\n  that rows must satisfy to be selected. where_condition is an\n  expression that evaluates to true for each row to be selected. The\n  statement selects all rows if there is no WHERE clause.\n\n  In the WHERE expression, you can use any of the functions and\n  operators that MySQL supports, except for aggregate (group)\n  functions. See\n  https://dev.mysql.com/doc/refman/8.0/en/expressions.html, and\n  https://dev.mysql.com/doc/refman/8.0/en/functions.html.\n\nSELECT can also be used to retrieve rows computed without reference to\nany table.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/select.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/select.html'),
(556, 'DUAL', 41, 'You are permitted to specify DUAL as a dummy table name in situations\nwhere no tables are referenced:\n\nmysql> SELECT 1 + 1 FROM DUAL;\n        -> 2\n\nDUAL is purely for the convenience of people who require that all\nSELECT statements should have FROM and possibly other clauses. MySQL\nmay ignore the clauses. MySQL does not require FROM DUAL if no tables\nare referenced.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/select.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/select.html'),
(557, 'JOIN', 41, 'MySQL supports the following JOIN syntax for the table_references part\nof SELECT statements and multiple-table DELETE and UPDATE statements:\n\ntable_references:\n    escaped_table_reference [, escaped_table_reference] ...\n\nescaped_table_reference: {\n    table_reference\n  | { OJ table_reference }\n}\n\ntable_reference: {\n    table_factor\n  | joined_table\n}\n\ntable_factor: {\n    tbl_name [PARTITION (partition_names)]\n        [[AS] alias] [index_hint_list]\n  | [LATERAL] table_subquery [AS] alias [(col_list)]\n  | ( table_references )\n}\n\njoined_table: {\n    table_reference {[INNER | CROSS] JOIN | STRAIGHT_JOIN} table_factor [join_specification]\n  | table_reference {LEFT|RIGHT} [OUTER] JOIN table_reference join_specification\n  | table_reference NATURAL [INNER | {LEFT|RIGHT} [OUTER]] JOIN table_factor\n}\n\njoin_specification: {\n    ON search_condition\n  | USING (join_column_list)\n}\n\njoin_column_list:\n    column_name [, column_name] ...\n\nindex_hint_list:\n    index_hint [, index_hint] ...\n\nindex_hint: {\n    USE {INDEX|KEY}\n      [FOR {JOIN|ORDER BY|GROUP BY}] ([index_list])\n  | {IGNORE|FORCE} {INDEX|KEY}\n      [FOR {JOIN|ORDER BY|GROUP BY}] (index_list)\n}\n\nindex_list:\n    index_name [, index_name] ...\n\nA table reference is also known as a join expression.\n\nA table reference (when it refers to a partitioned table) may contain a\nPARTITION clause, including a list of comma-separated partitions,\nsubpartitions, or both. This option follows the name of the table and\nprecedes any alias declaration. The effect of this option is that rows\nare selected only from the listed partitions or subpartitions. Any\npartitions or subpartitions not named in the list are ignored. For more\ninformation and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\nThe syntax of table_factor is extended in MySQL in comparison with\nstandard SQL. The standard accepts only table_reference, not a list of\nthem inside a pair of parentheses.\n\nThis is a conservative extension if each comma in a list of\ntable_reference items is considered as equivalent to an inner join. For\nexample:\n\nSELECT * FROM t1 LEFT JOIN (t2, t3, t4)\n                 ON (t2.a = t1.a AND t3.b = t1.b AND t4.c = t1.c)\n\nis equivalent to:\n\nSELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)\n                 ON (t2.a = t1.a AND t3.b = t1.b AND t4.c = t1.c)\n\nIn MySQL, JOIN, CROSS JOIN, and INNER JOIN are syntactic equivalents\n(they can replace each other). In standard SQL, they are not\nequivalent. INNER JOIN is used with an ON clause, CROSS JOIN is used\notherwise.\n\nIn general, parentheses can be ignored in join expressions containing\nonly inner join operations. MySQL also supports nested joins. See\nhttps://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html.\n\nIndex hints can be specified to affect how the MySQL optimizer makes\nuse of indexes. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/index-hints.html. Optimizer\nhints and the optimizer_switch system variable are other ways to\ninfluence optimizer use of indexes. See\nhttps://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html, and\nhttps://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/join.html\n\n', 'SELECT left_tbl.*\n  FROM left_tbl LEFT JOIN right_tbl ON left_tbl.id = right_tbl.id\n  WHERE right_tbl.id IS NULL;\n', 'https://dev.mysql.com/doc/refman/8.0/en/join.html'),
(558, 'TABLE', 41, 'Syntax:\nTABLE is a DML statement introduced in MySQL 8.0.19 which returns rows\nand columns of the named table.\n\nTABLE table_name [ORDER BY column_name] [LIMIT number [OFFSET number]]\n\nThe TABLE statement in some ways acts like SELECT. Given the existence\nof a table named t, the following two statements produce identical\noutput:\n\nTABLE t;\n\nSELECT * FROM t;\n\nYou can order and limit the number of rows produced by TABLE using\nORDER BY and LIMIT clauses, respectively. These function identically to\nthe same clauses when used with SELECT (including an optional OFFSET\nclause with LIMIT), as you can see here:\n\nmysql> TABLE t;\n+----+----+\n| a  | b  |\n+----+----+\n|  1 |  2 |\n|  6 |  7 |\n|  9 |  5 |\n| 10 | -4 |\n| 11 | -1 |\n| 13 |  3 |\n| 14 |  6 |\n+----+----+\n7 rows in set (0.00 sec)\n\nmysql> TABLE t ORDER BY b;\n+----+----+\n| a  | b  |\n+----+----+\n| 10 | -4 |\n| 11 | -1 |\n|  1 |  2 |\n| 13 |  3 |\n|  9 |  5 |\n| 14 |  6 |\n|  6 |  7 |\n+----+----+\n7 rows in set (0.00 sec)\n\nmysql> TABLE t LIMIT 3;\n+---+---+\n| a | b |\n+---+---+\n| 1 | 2 |\n| 6 | 7 |\n| 9 | 5 |\n+---+---+\n3 rows in set (0.00 sec)\n\nmysql> TABLE t ORDER BY b LIMIT 3;\n+----+----+\n| a  | b  |\n+----+----+\n| 10 | -4 |\n| 11 | -1 |\n|  1 |  2 |\n+----+----+\n3 rows in set (0.00 sec)\n\nmysql> TABLE t ORDER BY b LIMIT 3 OFFSET 2;\n+----+----+\n| a  | b  |\n+----+----+\n|  1 |  2 |\n| 13 |  3 |\n|  9 |  5 |\n+----+----+\n3 rows in set (0.00 sec)\n\nTABLE differs from SELECT in two key respects:\n\no TABLE always displays all columns of the table.\n\n  Exception: The output of TABLE does not include invisible columns.\n  See https://dev.mysql.com/doc/refman/8.0/en/invisible-columns.html.\n\no TABLE does not allow for any arbitrary filtering of rows; that is,\n  TABLE does not support any WHERE clause.\n\nFor limiting which table columns are returned, filtering rows beyond\nwhat can be accomplished using ORDER BY and LIMIT, or both, use SELECT.\n\nTABLE can be used with temporary tables.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/table.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/table.html'),
(559, 'UPDATE', 41, 'Syntax:\nUPDATE is a DML statement that modifies rows in a table.\n\nAn UPDATE statement can start with a WITH clause to define common table\nexpressions accessible within the UPDATE. See\nhttps://dev.mysql.com/doc/refman/8.0/en/with.html.\n\nSingle-table syntax:\n\nUPDATE [LOW_PRIORITY] [IGNORE] table_reference\n    SET assignment_list\n    [WHERE where_condition]\n    [ORDER BY ...]\n    [LIMIT row_count]\n\nvalue:\n    {expr | DEFAULT}\n\nassignment:\n    col_name = value\n\nassignment_list:\n    assignment [, assignment] ...\n\nMultiple-table syntax:\n\nUPDATE [LOW_PRIORITY] [IGNORE] table_references\n    SET assignment_list\n    [WHERE where_condition]\n\nFor the single-table syntax, the UPDATE statement updates columns of\nexisting rows in the named table with new values. The SET clause\nindicates which columns to modify and the values they should be given.\nEach value can be given as an expression, or the keyword DEFAULT to set\na column explicitly to its default value. The WHERE clause, if given,\nspecifies the conditions that identify which rows to update. With no\nWHERE clause, all rows are updated. If the ORDER BY clause is\nspecified, the rows are updated in the order that is specified. The\nLIMIT clause places a limit on the number of rows that can be updated.\n\nFor the multiple-table syntax, UPDATE updates rows in each table named\nin table_references that satisfy the conditions. Each matching row is\nupdated once, even if it matches the conditions multiple times. For\nmultiple-table syntax, ORDER BY and LIMIT cannot be used.\n\nFor partitioned tables, both the single-single and multiple-table forms\nof this statement support the use of a PARTITION clause as part of a\ntable reference. This option takes a list of one or more partitions or\nsubpartitions (or both). Only the partitions (or subpartitions) listed\nare checked for matches, and a row that is not in any of these\npartitions or subpartitions is not updated, whether it satisfies the\nwhere_condition or not.\n\n*Note*:\n\nUnlike the case when using PARTITION with an INSERT or REPLACE\nstatement, an otherwise valid UPDATE ... PARTITION statement is\nconsidered successful even if no rows in the listed partitions (or\nsubpartitions) match the where_condition.\n\nFor more information and examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/partitioning-selection.html.\n\nwhere_condition is an expression that evaluates to true for each row to\nbe updated. For expression syntax, see\nhttps://dev.mysql.com/doc/refman/8.0/en/expressions.html.\n\ntable_references and where_condition are specified as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/select.html.\n\nYou need the UPDATE privilege only for columns referenced in an UPDATE\nthat are actually updated. You need only the SELECT privilege for any\ncolumns that are read but not modified.\n\nThe UPDATE statement supports the following modifiers:\n\no With the LOW_PRIORITY modifier, execution of the UPDATE is delayed\n  until no other clients are reading from the table. This affects only\n  storage engines that use only table-level locking (such as MyISAM,\n  MEMORY, and MERGE).\n\no With the IGNORE modifier, the update statement does not abort even if\n  errors occur during the update. Rows for which duplicate-key\n  conflicts occur on a unique key value are not updated. Rows updated\n  to values that would cause data conversion errors are updated to the\n  closest valid values instead. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#ignore-effect-o\n  n-execution.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/update.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/update.html'),
(560, 'UNION', 41, 'Syntax:\nquery_expression_body UNION [ALL | DISTINCT] query_block\n    [UNION [ALL | DISTINCT] query_expression_body]\n    [...]\n\nquery_expression_body:\n    See \n\nUNION combines the result from multiple query blocks into a single\nresult set. This example uses SELECT statements:\n\nmysql> SELECT 1, 2;\n+---+---+\n| 1 | 2 |\n+---+---+\n| 1 | 2 |\n+---+---+\nmysql> SELECT \'a\', \'b\';\n+---+---+\n| a | b |\n+---+---+\n| a | b |\n+---+---+\nmysql> SELECT 1, 2 UNION SELECT \'a\', \'b\';\n+---+---+\n| 1 | 2 |\n+---+---+\n| 1 | 2 |\n| a | b |\n+---+---+\n\nUNION Handing in MySQL 8.0 Compared to MySQL 5.7\n\nIn MySQL 8.0, the parser rules for SELECT and UNION were refactored to\nbe more consistent (the same SELECT syntax applies uniformly in each\nsuch context) and reduce duplication. Compared to MySQL 5.7, several\nuser-visible effects resulted from this work, which may require\nrewriting of certain statements:\n\no NATURAL JOIN permits an optional INNER keyword (NATURAL INNER JOIN),\n  in compliance with standard SQL.\n\no Right-deep joins without parentheses are permitted (for example, ...\n  JOIN ... JOIN ... ON ... ON), in compliance with standard SQL.\n\no STRAIGHT_JOIN now permits a USING clause, similar to other inner\n  joins.\n\no The parser accepts parentheses around query expressions. For example,\n  (SELECT ... UNION SELECT ...) is permitted. See also [HELP\n  parenthesized query expressions].\n\no The parser better conforms to the documented permitted placement of\n  the SQL_CACHE and SQL_NO_CACHE query modifiers.\n\no Left-hand nesting of unions, previously permitted only in subqueries,\n  is now permitted in top-level statements. For example, this statement\n  is now accepted as valid:\n\n(SELECT 1 UNION SELECT 1) UNION SELECT 1;\n\no Locking clauses (FOR UPDATE, LOCK IN SHARE MODE) are allowed only in\n  non-UNION queries. This means that parentheses must be used for\n  SELECT statements containing locking clauses. This statement is no\n  longer accepted as valid:\n\nSELECT 1 FOR UPDATE UNION SELECT 1 FOR UPDATE;\n\n  Instead, write the statement like this:\n\n(SELECT 1 FOR UPDATE) UNION (SELECT 1 FOR UPDATE);\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/union.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/union.html'),
(561, 'VALUES STATEMENT', 41, 'Syntax:\nVALUES row_constructor_list [ORDER BY column_designator] [LIMIT number]\n\nrow_constructor_list:\n    ROW(value_list)[, ROW(value_list)][, ...]\n\nvalue_list:\n    value[, value][, ...]\n\ncolumn_designator:\n    column_index\n\nThe VALUES statement consists of the VALUES keyword followed by a list\nof one or more row constructors, separated by commas. A row constructor\nconsists of the ROW() row constructor clause with a value list of one\nor more scalar values enclosed in the parentheses. A value can be a\nliteral of any MySQL data type or an expression that resolves to a\nscalar value.\n\nROW() cannot be empty (but each of the supplied scalar values can be\nNULL). Each ROW() in the same VALUES statement must have the same\nnumber of values in its value list.\n\nThe DEFAULT keyword is not supported by VALUES and causes a syntax\nerror, except when it is used to supply values in an INSERT statement.\n\nThe output of VALUES is a table:\n\nmysql> VALUES ROW(1,-2,3), ROW(5,7,9), ROW(4,6,8);\n+----------+----------+----------+\n| column_0 | column_1 | column_2 |\n+----------+----------+----------+\n|        1 |       -2 |        3 |\n|        5 |        7 |        9 |\n|        4 |        6 |        8 |\n+----------+----------+----------+\n3 rows in set (0.00 sec)\n\nThe columns of the table output from VALUES have the implicitly named\ncolumns column_0, column_1, column_2, and so on, always beginning with\n0. This fact can be used to order the rows by column using an optional\nORDER BY clause in the same way that this clause works with a SELECT\nstatement, as shown here:\n\nmysql> VALUES ROW(1,-2,3), ROW(5,7,9), ROW(4,6,8) ORDER BY column_1;\n+----------+----------+----------+\n| column_0 | column_1 | column_2 |\n+----------+----------+----------+\n|        1 |       -2 |        3 |\n|        4 |        6 |        8 |\n|        5 |        7 |        9 |\n+----------+----------+----------+\n3 rows in set (0.00 sec)\n\nIn MySQL 8.0.21 and later, the VALUES statement also supports a LIMIT\nclause for limiting the number of rows in the output. (Previously,\nLIMIT was allowed but did nothing.)\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/values.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/values.html'),
(562, 'START TRANSACTION', 42, 'Syntax:\nSTART TRANSACTION\n    [transaction_characteristic [, transaction_characteristic] ...]\n\ntransaction_characteristic: {\n    WITH CONSISTENT SNAPSHOT\n  | READ WRITE\n  | READ ONLY\n}\n\nBEGIN [WORK]\nCOMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nSET autocommit = {0 | 1}\n\nThese statements provide control over use of transactions:\n\no START TRANSACTION or BEGIN start a new transaction.\n\no COMMIT commits the current transaction, making its changes permanent.\n\no ROLLBACK rolls back the current transaction, canceling its changes.\n\no SET autocommit disables or enables the default autocommit mode for\n  the current session.\n\nBy default, MySQL runs with autocommit mode enabled. This means that,\nwhen not otherwise inside a transaction, each statement is atomic, as\nif it were surrounded by START TRANSACTION and COMMIT. You cannot use\nROLLBACK to undo the effect; however, if an error occurs during\nstatement execution, the statement is rolled back.\n\nTo disable autocommit mode implicitly for a single series of\nstatements, use the START TRANSACTION statement:\n\nSTART TRANSACTION;\nSELECT @A:=SUM(salary) FROM table1 WHERE type=1;\nUPDATE table2 SET summary=@A WHERE type=1;\nCOMMIT;\n\nWith START TRANSACTION, autocommit remains disabled until you end the\ntransaction with COMMIT or ROLLBACK. The autocommit mode then reverts\nto its previous state.\n\nSTART TRANSACTION permits several modifiers that control transaction\ncharacteristics. To specify multiple modifiers, separate them by\ncommas.\n\no The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for\n  storage engines that are capable of it. This applies only to InnoDB.\n  The effect is the same as issuing a START TRANSACTION followed by a\n  SELECT from any InnoDB table. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html.\n  The WITH CONSISTENT SNAPSHOT modifier does not change the current\n  transaction isolation level, so it provides a consistent snapshot\n  only if the current isolation level is one that permits a consistent\n  read. The only isolation level that permits a consistent read is\n  REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT\n  SNAPSHOT clause is ignored. A warning is generated when the WITH\n  CONSISTENT SNAPSHOT clause is ignored.\n\no The READ WRITE and READ ONLY modifiers set the transaction access\n  mode. They permit or prohibit changes to tables used in the\n  transaction. The READ ONLY restriction prevents the transaction from\n  modifying or locking both transactional and nontransactional tables\n  that are visible to other transactions; the transaction can still\n  modify or lock temporary tables.\n\n  MySQL enables extra optimizations for queries on InnoDB tables when\n  the transaction is known to be read-only. Specifying READ ONLY\n  ensures these optimizations are applied in cases where the read-only\n  status cannot be determined automatically. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-ro-txn.htm\n  l for more information.\n\n  If no access mode is specified, the default mode applies. Unless the\n  default has been changed, it is read/write. It is not permitted to\n  specify both READ WRITE and READ ONLY in the same statement.\n\n  In read-only mode, it remains possible to change tables created with\n  the TEMPORARY keyword using DML statements. Changes made with DDL\n  statements are not permitted, just as with permanent tables.\n\n  For additional information about transaction access mode, including\n  ways to change the default mode, see [HELP SET TRANSACTION].\n\n  If the read_only system variable is enabled, explicitly starting a\n  transaction with START TRANSACTION READ WRITE requires the\n  CONNECTION_ADMIN privilege (or the deprecated SUPER privilege).\n\n*Important*:\n\nMany APIs used for writing MySQL client applications (such as JDBC)\nprovide their own methods for starting transactions that can (and\nsometimes should) be used instead of sending a START TRANSACTION\nstatement from the client. See\nhttps://dev.mysql.com/doc/refman/8.0/en/connectors-apis.html, or the\ndocumentation for your API, for more information.\n\nTo disable autocommit mode explicitly, use the following statement:\n\nSET autocommit=0;\n\nAfter disabling autocommit mode by setting the autocommit variable to\nzero, changes to transaction-safe tables (such as those for InnoDB or\nNDB) are not made permanent immediately. You must use COMMIT to store\nyour changes to disk or ROLLBACK to ignore the changes.\n\nautocommit is a session variable and must be set for each session. To\ndisable autocommit mode for each new connection, see the description of\nthe autocommit system variable at\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nBEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for\ninitiating a transaction. START TRANSACTION is standard SQL syntax, is\nthe recommended way to start an ad-hoc transaction, and permits\nmodifiers that BEGIN does not.\n\nThe BEGIN statement differs from the use of the BEGIN keyword that\nstarts a BEGIN ... END compound statement. The latter does not begin a\ntransaction. See [HELP BEGIN END].\n\n*Note*:\n\nWithin all stored programs (stored procedures and functions, triggers,\nand events), the parser treats BEGIN [WORK] as the beginning of a BEGIN\n... END block. Begin a transaction in this context with START\nTRANSACTION instead.\n\nThe optional WORK keyword is supported for COMMIT and ROLLBACK, as are\nthe CHAIN and RELEASE clauses. CHAIN and RELEASE can be used for\nadditional control over transaction completion. The value of the\ncompletion_type system variable determines the default completion\nbehavior. See\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nThe AND CHAIN clause causes a new transaction to begin as soon as the\ncurrent one ends, and the new transaction has the same isolation level\nas the just-terminated transaction. The new transaction also uses the\nsame access mode (READ WRITE or READ ONLY) as the just-terminated\ntransaction. The RELEASE clause causes the server to disconnect the\ncurrent client session after terminating the current transaction.\nIncluding the NO keyword suppresses CHAIN or RELEASE completion, which\ncan be useful if the completion_type system variable is set to cause\nchaining or release completion by default.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/commit.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/commit.html'),
(563, 'BEGIN', 42, 'Syntax:\nSTART TRANSACTION\n    [transaction_characteristic [, transaction_characteristic] ...]\n\ntransaction_characteristic: {\n    WITH CONSISTENT SNAPSHOT\n  | READ WRITE\n  | READ ONLY\n}\n\nBEGIN [WORK]\nCOMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nSET autocommit = {0 | 1}\n\nThese statements provide control over use of transactions:\n\no START TRANSACTION or BEGIN start a new transaction.\n\no COMMIT commits the current transaction, making its changes permanent.\n\no ROLLBACK rolls back the current transaction, canceling its changes.\n\no SET autocommit disables or enables the default autocommit mode for\n  the current session.\n\nBy default, MySQL runs with autocommit mode enabled. This means that,\nwhen not otherwise inside a transaction, each statement is atomic, as\nif it were surrounded by START TRANSACTION and COMMIT. You cannot use\nROLLBACK to undo the effect; however, if an error occurs during\nstatement execution, the statement is rolled back.\n\nTo disable autocommit mode implicitly for a single series of\nstatements, use the START TRANSACTION statement:\n\nSTART TRANSACTION;\nSELECT @A:=SUM(salary) FROM table1 WHERE type=1;\nUPDATE table2 SET summary=@A WHERE type=1;\nCOMMIT;\n\nWith START TRANSACTION, autocommit remains disabled until you end the\ntransaction with COMMIT or ROLLBACK. The autocommit mode then reverts\nto its previous state.\n\nSTART TRANSACTION permits several modifiers that control transaction\ncharacteristics. To specify multiple modifiers, separate them by\ncommas.\n\no The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for\n  storage engines that are capable of it. This applies only to InnoDB.\n  The effect is the same as issuing a START TRANSACTION followed by a\n  SELECT from any InnoDB table. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html.\n  The WITH CONSISTENT SNAPSHOT modifier does not change the current\n  transaction isolation level, so it provides a consistent snapshot\n  only if the current isolation level is one that permits a consistent\n  read. The only isolation level that permits a consistent read is\n  REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT\n  SNAPSHOT clause is ignored. A warning is generated when the WITH\n  CONSISTENT SNAPSHOT clause is ignored.\n\no The READ WRITE and READ ONLY modifiers set the transaction access\n  mode. They permit or prohibit changes to tables used in the\n  transaction. The READ ONLY restriction prevents the transaction from\n  modifying or locking both transactional and nontransactional tables\n  that are visible to other transactions; the transaction can still\n  modify or lock temporary tables.\n\n  MySQL enables extra optimizations for queries on InnoDB tables when\n  the transaction is known to be read-only. Specifying READ ONLY\n  ensures these optimizations are applied in cases where the read-only\n  status cannot be determined automatically. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-ro-txn.htm\n  l for more information.\n\n  If no access mode is specified, the default mode applies. Unless the\n  default has been changed, it is read/write. It is not permitted to\n  specify both READ WRITE and READ ONLY in the same statement.\n\n  In read-only mode, it remains possible to change tables created with\n  the TEMPORARY keyword using DML statements. Changes made with DDL\n  statements are not permitted, just as with permanent tables.\n\n  For additional information about transaction access mode, including\n  ways to change the default mode, see [HELP SET TRANSACTION].\n\n  If the read_only system variable is enabled, explicitly starting a\n  transaction with START TRANSACTION READ WRITE requires the\n  CONNECTION_ADMIN privilege (or the deprecated SUPER privilege).\n\n*Important*:\n\nMany APIs used for writing MySQL client applications (such as JDBC)\nprovide their own methods for starting transactions that can (and\nsometimes should) be used instead of sending a START TRANSACTION\nstatement from the client. See\nhttps://dev.mysql.com/doc/refman/8.0/en/connectors-apis.html, or the\ndocumentation for your API, for more information.\n\nTo disable autocommit mode explicitly, use the following statement:\n\nSET autocommit=0;\n\nAfter disabling autocommit mode by setting the autocommit variable to\nzero, changes to transaction-safe tables (such as those for InnoDB or\nNDB) are not made permanent immediately. You must use COMMIT to store\nyour changes to disk or ROLLBACK to ignore the changes.\n\nautocommit is a session variable and must be set for each session. To\ndisable autocommit mode for each new connection, see the description of\nthe autocommit system variable at\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nBEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for\ninitiating a transaction. START TRANSACTION is standard SQL syntax, is\nthe recommended way to start an ad-hoc transaction, and permits\nmodifiers that BEGIN does not.\n\nThe BEGIN statement differs from the use of the BEGIN keyword that\nstarts a BEGIN ... END compound statement. The latter does not begin a\ntransaction. See [HELP BEGIN END].\n\n*Note*:\n\nWithin all stored programs (stored procedures and functions, triggers,\nand events), the parser treats BEGIN [WORK] as the beginning of a BEGIN\n... END block. Begin a transaction in this context with START\nTRANSACTION instead.\n\nThe optional WORK keyword is supported for COMMIT and ROLLBACK, as are\nthe CHAIN and RELEASE clauses. CHAIN and RELEASE can be used for\nadditional control over transaction completion. The value of the\ncompletion_type system variable determines the default completion\nbehavior. See\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nThe AND CHAIN clause causes a new transaction to begin as soon as the\ncurrent one ends, and the new transaction has the same isolation level\nas the just-terminated transaction. The new transaction also uses the\nsame access mode (READ WRITE or READ ONLY) as the just-terminated\ntransaction. The RELEASE clause causes the server to disconnect the\ncurrent client session after terminating the current transaction.\nIncluding the NO keyword suppresses CHAIN or RELEASE completion, which\ncan be useful if the completion_type system variable is set to cause\nchaining or release completion by default.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/commit.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/commit.html'),
(564, 'COMMIT', 42, 'Syntax:\nSTART TRANSACTION\n    [transaction_characteristic [, transaction_characteristic] ...]\n\ntransaction_characteristic: {\n    WITH CONSISTENT SNAPSHOT\n  | READ WRITE\n  | READ ONLY\n}\n\nBEGIN [WORK]\nCOMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nSET autocommit = {0 | 1}\n\nThese statements provide control over use of transactions:\n\no START TRANSACTION or BEGIN start a new transaction.\n\no COMMIT commits the current transaction, making its changes permanent.\n\no ROLLBACK rolls back the current transaction, canceling its changes.\n\no SET autocommit disables or enables the default autocommit mode for\n  the current session.\n\nBy default, MySQL runs with autocommit mode enabled. This means that,\nwhen not otherwise inside a transaction, each statement is atomic, as\nif it were surrounded by START TRANSACTION and COMMIT. You cannot use\nROLLBACK to undo the effect; however, if an error occurs during\nstatement execution, the statement is rolled back.\n\nTo disable autocommit mode implicitly for a single series of\nstatements, use the START TRANSACTION statement:\n\nSTART TRANSACTION;\nSELECT @A:=SUM(salary) FROM table1 WHERE type=1;\nUPDATE table2 SET summary=@A WHERE type=1;\nCOMMIT;\n\nWith START TRANSACTION, autocommit remains disabled until you end the\ntransaction with COMMIT or ROLLBACK. The autocommit mode then reverts\nto its previous state.\n\nSTART TRANSACTION permits several modifiers that control transaction\ncharacteristics. To specify multiple modifiers, separate them by\ncommas.\n\no The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for\n  storage engines that are capable of it. This applies only to InnoDB.\n  The effect is the same as issuing a START TRANSACTION followed by a\n  SELECT from any InnoDB table. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html.\n  The WITH CONSISTENT SNAPSHOT modifier does not change the current\n  transaction isolation level, so it provides a consistent snapshot\n  only if the current isolation level is one that permits a consistent\n  read. The only isolation level that permits a consistent read is\n  REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT\n  SNAPSHOT clause is ignored. A warning is generated when the WITH\n  CONSISTENT SNAPSHOT clause is ignored.\n\no The READ WRITE and READ ONLY modifiers set the transaction access\n  mode. They permit or prohibit changes to tables used in the\n  transaction. The READ ONLY restriction prevents the transaction from\n  modifying or locking both transactional and nontransactional tables\n  that are visible to other transactions; the transaction can still\n  modify or lock temporary tables.\n\n  MySQL enables extra optimizations for queries on InnoDB tables when\n  the transaction is known to be read-only. Specifying READ ONLY\n  ensures these optimizations are applied in cases where the read-only\n  status cannot be determined automatically. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-ro-txn.htm\n  l for more information.\n\n  If no access mode is specified, the default mode applies. Unless the\n  default has been changed, it is read/write. It is not permitted to\n  specify both READ WRITE and READ ONLY in the same statement.\n\n  In read-only mode, it remains possible to change tables created with\n  the TEMPORARY keyword using DML statements. Changes made with DDL\n  statements are not permitted, just as with permanent tables.\n\n  For additional information about transaction access mode, including\n  ways to change the default mode, see [HELP SET TRANSACTION].\n\n  If the read_only system variable is enabled, explicitly starting a\n  transaction with START TRANSACTION READ WRITE requires the\n  CONNECTION_ADMIN privilege (or the deprecated SUPER privilege).\n\n*Important*:\n\nMany APIs used for writing MySQL client applications (such as JDBC)\nprovide their own methods for starting transactions that can (and\nsometimes should) be used instead of sending a START TRANSACTION\nstatement from the client. See\nhttps://dev.mysql.com/doc/refman/8.0/en/connectors-apis.html, or the\ndocumentation for your API, for more information.\n\nTo disable autocommit mode explicitly, use the following statement:\n\nSET autocommit=0;\n\nAfter disabling autocommit mode by setting the autocommit variable to\nzero, changes to transaction-safe tables (such as those for InnoDB or\nNDB) are not made permanent immediately. You must use COMMIT to store\nyour changes to disk or ROLLBACK to ignore the changes.\n\nautocommit is a session variable and must be set for each session. To\ndisable autocommit mode for each new connection, see the description of\nthe autocommit system variable at\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nBEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for\ninitiating a transaction. START TRANSACTION is standard SQL syntax, is\nthe recommended way to start an ad-hoc transaction, and permits\nmodifiers that BEGIN does not.\n\nThe BEGIN statement differs from the use of the BEGIN keyword that\nstarts a BEGIN ... END compound statement. The latter does not begin a\ntransaction. See [HELP BEGIN END].\n\n*Note*:\n\nWithin all stored programs (stored procedures and functions, triggers,\nand events), the parser treats BEGIN [WORK] as the beginning of a BEGIN\n... END block. Begin a transaction in this context with START\nTRANSACTION instead.\n\nThe optional WORK keyword is supported for COMMIT and ROLLBACK, as are\nthe CHAIN and RELEASE clauses. CHAIN and RELEASE can be used for\nadditional control over transaction completion. The value of the\ncompletion_type system variable determines the default completion\nbehavior. See\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nThe AND CHAIN clause causes a new transaction to begin as soon as the\ncurrent one ends, and the new transaction has the same isolation level\nas the just-terminated transaction. The new transaction also uses the\nsame access mode (READ WRITE or READ ONLY) as the just-terminated\ntransaction. The RELEASE clause causes the server to disconnect the\ncurrent client session after terminating the current transaction.\nIncluding the NO keyword suppresses CHAIN or RELEASE completion, which\ncan be useful if the completion_type system variable is set to cause\nchaining or release completion by default.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/commit.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/commit.html'),
(565, 'ROLLBACK', 42, 'Syntax:\nSTART TRANSACTION\n    [transaction_characteristic [, transaction_characteristic] ...]\n\ntransaction_characteristic: {\n    WITH CONSISTENT SNAPSHOT\n  | READ WRITE\n  | READ ONLY\n}\n\nBEGIN [WORK]\nCOMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]\nSET autocommit = {0 | 1}\n\nThese statements provide control over use of transactions:\n\no START TRANSACTION or BEGIN start a new transaction.\n\no COMMIT commits the current transaction, making its changes permanent.\n\no ROLLBACK rolls back the current transaction, canceling its changes.\n\no SET autocommit disables or enables the default autocommit mode for\n  the current session.\n\nBy default, MySQL runs with autocommit mode enabled. This means that,\nwhen not otherwise inside a transaction, each statement is atomic, as\nif it were surrounded by START TRANSACTION and COMMIT. You cannot use\nROLLBACK to undo the effect; however, if an error occurs during\nstatement execution, the statement is rolled back.\n\nTo disable autocommit mode implicitly for a single series of\nstatements, use the START TRANSACTION statement:\n\nSTART TRANSACTION;\nSELECT @A:=SUM(salary) FROM table1 WHERE type=1;\nUPDATE table2 SET summary=@A WHERE type=1;\nCOMMIT;\n\nWith START TRANSACTION, autocommit remains disabled until you end the\ntransaction with COMMIT or ROLLBACK. The autocommit mode then reverts\nto its previous state.\n\nSTART TRANSACTION permits several modifiers that control transaction\ncharacteristics. To specify multiple modifiers, separate them by\ncommas.\n\no The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for\n  storage engines that are capable of it. This applies only to InnoDB.\n  The effect is the same as issuing a START TRANSACTION followed by a\n  SELECT from any InnoDB table. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html.\n  The WITH CONSISTENT SNAPSHOT modifier does not change the current\n  transaction isolation level, so it provides a consistent snapshot\n  only if the current isolation level is one that permits a consistent\n  read. The only isolation level that permits a consistent read is\n  REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT\n  SNAPSHOT clause is ignored. A warning is generated when the WITH\n  CONSISTENT SNAPSHOT clause is ignored.\n\no The READ WRITE and READ ONLY modifiers set the transaction access\n  mode. They permit or prohibit changes to tables used in the\n  transaction. The READ ONLY restriction prevents the transaction from\n  modifying or locking both transactional and nontransactional tables\n  that are visible to other transactions; the transaction can still\n  modify or lock temporary tables.\n\n  MySQL enables extra optimizations for queries on InnoDB tables when\n  the transaction is known to be read-only. Specifying READ ONLY\n  ensures these optimizations are applied in cases where the read-only\n  status cannot be determined automatically. See\n  https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-ro-txn.htm\n  l for more information.\n\n  If no access mode is specified, the default mode applies. Unless the\n  default has been changed, it is read/write. It is not permitted to\n  specify both READ WRITE and READ ONLY in the same statement.\n\n  In read-only mode, it remains possible to change tables created with\n  the TEMPORARY keyword using DML statements. Changes made with DDL\n  statements are not permitted, just as with permanent tables.\n\n  For additional information about transaction access mode, including\n  ways to change the default mode, see [HELP SET TRANSACTION].\n\n  If the read_only system variable is enabled, explicitly starting a\n  transaction with START TRANSACTION READ WRITE requires the\n  CONNECTION_ADMIN privilege (or the deprecated SUPER privilege).\n\n*Important*:\n\nMany APIs used for writing MySQL client applications (such as JDBC)\nprovide their own methods for starting transactions that can (and\nsometimes should) be used instead of sending a START TRANSACTION\nstatement from the client. See\nhttps://dev.mysql.com/doc/refman/8.0/en/connectors-apis.html, or the\ndocumentation for your API, for more information.\n\nTo disable autocommit mode explicitly, use the following statement:\n\nSET autocommit=0;\n\nAfter disabling autocommit mode by setting the autocommit variable to\nzero, changes to transaction-safe tables (such as those for InnoDB or\nNDB) are not made permanent immediately. You must use COMMIT to store\nyour changes to disk or ROLLBACK to ignore the changes.\n\nautocommit is a session variable and must be set for each session. To\ndisable autocommit mode for each new connection, see the description of\nthe autocommit system variable at\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nBEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for\ninitiating a transaction. START TRANSACTION is standard SQL syntax, is\nthe recommended way to start an ad-hoc transaction, and permits\nmodifiers that BEGIN does not.\n\nThe BEGIN statement differs from the use of the BEGIN keyword that\nstarts a BEGIN ... END compound statement. The latter does not begin a\ntransaction. See [HELP BEGIN END].\n\n*Note*:\n\nWithin all stored programs (stored procedures and functions, triggers,\nand events), the parser treats BEGIN [WORK] as the beginning of a BEGIN\n... END block. Begin a transaction in this context with START\nTRANSACTION instead.\n\nThe optional WORK keyword is supported for COMMIT and ROLLBACK, as are\nthe CHAIN and RELEASE clauses. CHAIN and RELEASE can be used for\nadditional control over transaction completion. The value of the\ncompletion_type system variable determines the default completion\nbehavior. See\nhttps://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html.\n\nThe AND CHAIN clause causes a new transaction to begin as soon as the\ncurrent one ends, and the new transaction has the same isolation level\nas the just-terminated transaction. The new transaction also uses the\nsame access mode (READ WRITE or READ ONLY) as the just-terminated\ntransaction. The RELEASE clause causes the server to disconnect the\ncurrent client session after terminating the current transaction.\nIncluding the NO keyword suppresses CHAIN or RELEASE completion, which\ncan be useful if the completion_type system variable is set to cause\nchaining or release completion by default.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/commit.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/commit.html'),
(566, 'SAVEPOINT', 42, 'Syntax:\nSAVEPOINT identifier\nROLLBACK [WORK] TO [SAVEPOINT] identifier\nRELEASE SAVEPOINT identifier\n\nInnoDB supports the SQL statements SAVEPOINT, ROLLBACK TO SAVEPOINT,\nRELEASE SAVEPOINT and the optional WORK keyword for ROLLBACK.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/savepoint.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/savepoint.html'),
(567, 'ROLLBACK TO SAVEPOINT', 42, 'Syntax:\nSAVEPOINT identifier\nROLLBACK [WORK] TO [SAVEPOINT] identifier\nRELEASE SAVEPOINT identifier\n\nInnoDB supports the SQL statements SAVEPOINT, ROLLBACK TO SAVEPOINT,\nRELEASE SAVEPOINT and the optional WORK keyword for ROLLBACK.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/savepoint.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/savepoint.html'),
(568, 'RELEASE SAVEPOINT', 42, 'Syntax:\nSAVEPOINT identifier\nROLLBACK [WORK] TO [SAVEPOINT] identifier\nRELEASE SAVEPOINT identifier\n\nInnoDB supports the SQL statements SAVEPOINT, ROLLBACK TO SAVEPOINT,\nRELEASE SAVEPOINT and the optional WORK keyword for ROLLBACK.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/savepoint.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/savepoint.html'),
(569, 'LOCK INSTANCE FOR BACKUP', 42, 'Syntax:\nLOCK INSTANCE FOR BACKUP\n\nUNLOCK INSTANCE\n\nLOCK INSTANCE FOR BACKUP acquires an instance-level backup lock that\npermits DML during an online backup while preventing operations that\ncould result in an inconsistent snapshot.\n\nExecuting the LOCK INSTANCE FOR BACKUP statement requires the\nBACKUP_ADMIN privilege. The BACKUP_ADMIN privilege is automatically\ngranted to users with the RELOAD privilege when performing an in-place\nupgrade to MySQL 8.0 from an earlier version.\n\nMultiple sessions can hold a backup lock simultaneously.\n\nUNLOCK INSTANCE releases a backup lock held by the current session. A\nbackup lock held by a session is also released if the session is\nterminated.\n\nLOCK INSTANCE FOR BACKUP prevents files from being created, renamed, or\nremoved. REPAIR TABLE TRUNCATE TABLE, OPTIMIZE TABLE, and account\nmanagement statements are blocked. See\nhttps://dev.mysql.com/doc/refman/8.0/en/account-management-statements.html\n. Operations that modify InnoDB files that are not recorded in the\nInnoDB redo log are also blocked.\n\nLOCK INSTANCE FOR BACKUP permits DDL operations that only affect\nuser-created temporary tables. In effect, files that belong to\nuser-created temporary tables can be created, renamed, or removed while\na backup lock is held. Creation of binary log files is also permitted.\n\nPURGE BINARY LOGS should not be issued while a LOCK INSTANCE FOR BACKUP\nstatement is in effect for the instance, because it contravenes the\nrules of the backup lock by removing files from the server. From MySQL\n8.0.28, this is disallowed.\n\nA backup lock acquired by LOCK INSTANCE FOR BACKUP is independent of\ntransactional locks and locks taken by FLUSH TABLES tbl_name [,\ntbl_name] ... WITH READ LOCK, and the following sequences of statements\nare permitted:\n\nLOCK INSTANCE FOR BACKUP;\nFLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK;\nUNLOCK TABLES;\nUNLOCK INSTANCE;\n\nFLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK;\nLOCK INSTANCE FOR BACKUP;\nUNLOCK INSTANCE;\nUNLOCK TABLES;\n\nThe lock_wait_timeout setting defines the amount of time that a LOCK\nINSTANCE FOR BACKUP statement waits to acquire a lock before giving up.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html');
INSERT INTO `help_topic` (`help_topic_id`, `name`, `help_category_id`, `description`, `example`, `url`) VALUES
(570, 'LOCK TABLES', 42, 'Syntax:\nLOCK TABLES\n    tbl_name [[AS] alias] lock_type\n    [, tbl_name [[AS] alias] lock_type] ...\n\nlock_type: {\n    READ [LOCAL]\n  | [LOW_PRIORITY] WRITE\n}\n\nUNLOCK TABLES\n\nMySQL enables client sessions to acquire table locks explicitly for the\npurpose of cooperating with other sessions for access to tables, or to\nprevent other sessions from modifying tables during periods when a\nsession requires exclusive access to them. A session can acquire or\nrelease locks only for itself. One session cannot acquire locks for\nanother session or release locks held by another session.\n\nLocks may be used to emulate transactions or to get more speed when\nupdating tables. This is explained in more detail in\nhttps://dev.mysql.com/doc/refman/8.0/en/lock-tables.html#lock-tables-re\nstrictions.\n\nLOCK TABLES explicitly acquires table locks for the current client\nsession. Table locks can be acquired for base tables or views. You must\nhave the LOCK TABLES privilege, and the SELECT privilege for each\nobject to be locked.\n\nFor view locking, LOCK TABLES adds all base tables used in the view to\nthe set of tables to be locked and locks them automatically. For tables\nunderlying any view being locked, LOCK TABLES checks that the view\ndefiner (for SQL SECURITY DEFINER views) or invoker (for all views) has\nthe proper privileges on the tables.\n\nIf you lock a table explicitly with LOCK TABLES, any tables used in\ntriggers are also locked implicitly, as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/lock-tables.html#lock-tables-an\nd-triggers.\n\nIf you lock a table explicitly with LOCK TABLES, any tables related by\na foreign key constraint are opened and locked implicitly. For foreign\nkey checks, a shared read-only lock (LOCK TABLES READ) is taken on\nrelated tables. For cascading updates, a shared-nothing write lock\n(LOCK TABLES WRITE) is taken on related tables that are involved in the\noperation.\n\nUNLOCK TABLES explicitly releases any table locks held by the current\nsession. LOCK TABLES implicitly releases any table locks held by the\ncurrent session before acquiring new locks.\n\nAnother use for UNLOCK TABLES is to release the global read lock\nacquired with the FLUSH TABLES WITH READ LOCK statement, which enables\nyou to lock all tables in all databases. See [HELP FLUSH]. (This is a\nvery convenient way to get backups if you have a file system such as\nVeritas that can take snapshots in time.)\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/lock-tables.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/lock-tables.html'),
(571, 'SET TRANSACTION', 42, 'Syntax:\nSET [GLOBAL | SESSION] TRANSACTION\n    transaction_characteristic [, transaction_characteristic] ...\n\ntransaction_characteristic: {\n    ISOLATION LEVEL level\n  | access_mode\n}\n\nlevel: {\n     REPEATABLE READ\n   | READ COMMITTED\n   | READ UNCOMMITTED\n   | SERIALIZABLE\n}\n\naccess_mode: {\n     READ WRITE\n   | READ ONLY\n}\n\nThis statement specifies transaction characteristics. It takes a list\nof one or more characteristic values separated by commas. Each\ncharacteristic value sets the transaction isolation level or access\nmode. The isolation level is used for operations on InnoDB tables. The\naccess mode specifies whether transactions operate in read/write or\nread-only mode.\n\nIn addition, SET TRANSACTION can include an optional GLOBAL or SESSION\nkeyword to indicate the scope of the statement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/set-transaction.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/set-transaction.html'),
(572, 'XA', 42, 'Syntax:\nXA {START|BEGIN} xid [JOIN|RESUME]\n\nXA END xid [SUSPEND [FOR MIGRATE]]\n\nXA PREPARE xid\n\nXA COMMIT xid [ONE PHASE]\n\nXA ROLLBACK xid\n\nXA RECOVER [CONVERT XID]\n\nFor XA START, the JOIN and RESUME clauses are recognized but have no\neffect.\n\nFor XA END the SUSPEND [FOR MIGRATE] clause is recognized but has no\neffect.\n\nEach XA statement begins with the XA keyword, and most of them require\nan xid value. An xid is an XA transaction identifier. It indicates\nwhich transaction the statement applies to. xid values are supplied by\nthe client, or generated by the MySQL server. An xid value has from one\nto three parts:\n\nxid: gtrid [, bqual [, formatID ]]\n\ngtrid is a global transaction identifier, bqual is a branch qualifier,\nand formatID is a number that identifies the format used by the gtrid\nand bqual values. As indicated by the syntax, bqual and formatID are\noptional. The default bqual value is \'\' if not given. The default\nformatID value is 1 if not given.\n\ngtrid and bqual must be string literals, each up to 64 bytes (not\ncharacters) long. gtrid and bqual can be specified in several ways. You\ncan use a quoted string (\'ab\'), hex string (X\'6162\', 0x6162), or bit\nvalue (b\'nnnn\').\n\nformatID is an unsigned integer.\n\nThe gtrid and bqual values are interpreted in bytes by the MySQL\nserver\'s underlying XA support routines. However, while an SQL\nstatement containing an XA statement is being parsed, the server works\nwith some specific character set. To be safe, write gtrid and bqual as\nhex strings.\n\nxid values typically are generated by the Transaction Manager. Values\ngenerated by one TM must be different from values generated by other\nTMs. A given TM must be able to recognize its own xid values in a list\nof values returned by the XA RECOVER statement.\n\nXA START xid starts an XA transaction with the given xid value. Each XA\ntransaction must have a unique xid value, so the value must not\ncurrently be used by another XA transaction. Uniqueness is assessed\nusing the gtrid and bqual values. All following XA statements for the\nXA transaction must be specified using the same xid value as that given\nin the XA START statement. If you use any of those statements but\nspecify an xid value that does not correspond to some existing XA\ntransaction, an error occurs.\n\nBeginning with MySQL 8.0.31, XA START, XA BEGIN, XA END, XA COMMIT, and\nXA ROLLBACK statements are not filtered by the default database when\nthe server is running with --replicate-do-db or --replicate-ignore-db.\n\nOne or more XA transactions can be part of the same global transaction.\nAll XA transactions within a given global transaction must use the same\ngtrid value in the xid value. For this reason, gtrid values must be\nglobally unique so that there is no ambiguity about which global\ntransaction a given XA transaction is part of. The bqual part of the\nxid value must be different for each XA transaction within a global\ntransaction. (The requirement that bqual values be different is a\nlimitation of the current MySQL XA implementation. It is not part of\nthe XA specification.)\n\nThe XA RECOVER statement returns information for those XA transactions\non the MySQL server that are in the PREPARED state. (See\nhttps://dev.mysql.com/doc/refman/8.0/en/xa-states.html.) The output\nincludes a row for each such XA transaction on the server, regardless\nof which client started it.\n\nXA RECOVER requires the XA_RECOVER_ADMIN privilege. This privilege\nrequirement prevents users from discovering the XID values for\noutstanding prepared XA transactions other than their own. It does not\naffect normal commit or rollback of an XA transaction because the user\nwho started it knows its XID.\n\nXA RECOVER output rows look like this (for an example xid value\nconsisting of the parts \'abc\', \'def\', and 7):\n\nmysql> XA RECOVER;\n+----------+--------------+--------------+--------+\n| formatID | gtrid_length | bqual_length | data   |\n+----------+--------------+--------------+--------+\n|        7 |            3 |            3 | abcdef |\n+----------+--------------+--------------+--------+\n\nThe output columns have the following meanings:\n\no formatID is the formatID part of the transaction xid\n\no gtrid_length is the length in bytes of the gtrid part of the xid\n\no bqual_length is the length in bytes of the bqual part of the xid\n\no data is the concatenation of the gtrid and bqual parts of the xid\n\nXID values may contain nonprintable characters. XA RECOVER permits an\noptional CONVERT XID clause so that clients can request XID values in\nhexadecimal.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/xa-statements.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/xa-statements.html'),
(573, 'PURGE BINARY LOGS', 43, 'Syntax:\nPURGE { BINARY | MASTER } LOGS {\n    TO \'log_name\'\n  | BEFORE datetime_expr\n}\n\nThe binary log is a set of files that contain information about data\nmodifications made by the MySQL server. The log consists of a set of\nbinary log files, plus an index file (see\nhttps://dev.mysql.com/doc/refman/8.0/en/binary-log.html).\n\nThe PURGE BINARY LOGS statement deletes all the binary log files listed\nin the log index file prior to the specified log file name or date.\nBINARY and MASTER are synonyms. Deleted log files also are removed from\nthe list recorded in the index file, so that the given log file becomes\nthe first in the list.\n\nPURGE BINARY LOGS requires the BINLOG_ADMIN privilege. This statement\nhas no effect if the server was not started with the --log-bin option\nto enable binary logging.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html\n\n', 'PURGE BINARY LOGS TO \'mysql-bin.010\';\nPURGE BINARY LOGS BEFORE \'2019-04-02 22:46:26\';\n', 'https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html'),
(574, 'PURGE MASTER LOGS', 43, 'Syntax:\nPURGE { BINARY | MASTER } LOGS {\n    TO \'log_name\'\n  | BEFORE datetime_expr\n}\n\nThe binary log is a set of files that contain information about data\nmodifications made by the MySQL server. The log consists of a set of\nbinary log files, plus an index file (see\nhttps://dev.mysql.com/doc/refman/8.0/en/binary-log.html).\n\nThe PURGE BINARY LOGS statement deletes all the binary log files listed\nin the log index file prior to the specified log file name or date.\nBINARY and MASTER are synonyms. Deleted log files also are removed from\nthe list recorded in the index file, so that the given log file becomes\nthe first in the list.\n\nPURGE BINARY LOGS requires the BINLOG_ADMIN privilege. This statement\nhas no effect if the server was not started with the --log-bin option\nto enable binary logging.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html\n\n', 'PURGE BINARY LOGS TO \'mysql-bin.010\';\nPURGE BINARY LOGS BEFORE \'2019-04-02 22:46:26\';\n', 'https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html'),
(575, 'RESET MASTER', 43, 'Syntax:\nRESET MASTER [TO binary_log_file_index_number]\n\n*Warning*:\n\nUse this statement with caution to ensure you do not lose any wanted\nbinary log file data and GTID execution history.\n\nRESET MASTER requires the RELOAD privilege.\n\nFor a server where binary logging is enabled (log_bin is ON), RESET\nMASTER deletes all existing binary log files and resets the binary log\nindex file, resetting the server to its state before binary logging was\nstarted. A new empty binary log file is created so that binary logging\ncan be restarted.\n\nFor a server where GTIDs are in use (gtid_mode is ON), issuing RESET\nMASTER resets the GTID execution history. The value of the gtid_purged\nsystem variable is set to an empty string (\'\'), the global value (but\nnot the session value) of the gtid_executed system variable is set to\nan empty string, and the mysql.gtid_executed table is cleared (see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html\n#replication-gtids-gtid-executed-table). If the GTID-enabled server has\nbinary logging enabled, RESET MASTER also resets the binary log as\ndescribed above. Note that RESET MASTER is the method to reset the GTID\nexecution history even if the GTID-enabled server is a replica where\nbinary logging is disabled; RESET REPLICA has no effect on the GTID\nexecution history. For more information on resetting the GTID execution\nhistory, see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-gtids-lifecycle.html\n#replication-gtids-execution-history.\n\nIssuing RESET MASTER without the optional TO clause deletes all binary\nlog files listed in the index file, resets the binary log index file to\nbe empty, and creates a new binary log file starting at 1. Use the\noptional TO clause to start the binary log file index from a number\nother than 1 after the reset.\n\nUsing RESET MASTER with the TO clause to specify a binary log file\nindex number to start from simplifies failover by providing a single\nstatement alternative to the FLUSH BINARY LOGS and PURGE BINARY LOGS TO\nstatements. Check that you are using a reasonable value for the index\nnumber. If you enter an incorrect value, you can correct this by\nissuing another RESET MASTER statement with or without the TO clause.\nIf you do not correct a value that is out of range, the server cannot\nbe restarted.\n\nThe following example demonstrates TO clause usage:\n\nRESET MASTER TO 1234;\n\nSHOW BINARY LOGS;\n+-------------------+-----------+-----------+\n| Log_name          | File_size | Encrypted |\n+-------------------+-----------+-----------+\n| source-bin.001234 |       154 | No        |\n+-------------------+-----------+-----------+\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/reset-master.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/reset-master.html'),
(576, 'SET SQL_LOG_BIN', 43, 'Syntax:\nSET sql_log_bin = {OFF|ON}\n\nThe sql_log_bin variable controls whether logging to the binary log is\nenabled for the current session (assuming that the binary log itself is\nenabled). The default value is ON. To disable or enable binary logging\nfor the current session, set the session sql_log_bin variable to OFF or\nON.\n\nSet this variable to OFF for a session to temporarily disable binary\nlogging while making changes to the source that you do not want\nreplicated to the replica.\n\nSetting the session value of this system variable is a restricted\noperation. The session user must have privileges sufficient to set\nrestricted session variables. See\nhttps://dev.mysql.com/doc/refman/8.0/en/system-variable-privileges.html\n.\n\nIt is not possible to set the session value of sql_log_bin within a\ntransaction or subquery.\n\nSetting this variable to OFF prevents new GTIDs from being assigned to\ntransactions in the binary log. If you are using GTIDs for replication,\nthis means that even when binary logging is later enabled again, the\nGTIDs written into the log from this point do not account for any\ntransactions that occurred in the meantime, so in effect those\ntransactions are lost.\n\nmysqldump adds a SET @@SESSION.sql_log_bin=0 statement to a dump file\nfrom a server where GTIDs are in use, which disables binary logging\nwhile the dump file is being reloaded. The statement prevents new GTIDs\nfrom being generated and assigned to the transactions in the dump file\nas they are executed, so that the original GTIDs for the transactions\nare used.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/set-sql-log-bin.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/set-sql-log-bin.html'),
(577, 'CHANGE MASTER TO', 43, 'Syntax:\nCHANGE MASTER TO option [, option] ... [ channel_option ]\n\noption: {\n    MASTER_BIND = \'interface_name\'\n  | MASTER_HOST = \'host_name\'\n  | MASTER_USER = \'user_name\'\n  | MASTER_PASSWORD = \'password\'\n  | MASTER_PORT = port_num\n  | PRIVILEGE_CHECKS_USER = {\'account\' | NULL}\n  | REQUIRE_ROW_FORMAT = {0|1}\n  | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}\n  | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}\n  | MASTER_LOG_FILE = \'source_log_name\'\n  | MASTER_LOG_POS = source_log_pos\n  | MASTER_AUTO_POSITION = {0|1}\n  | RELAY_LOG_FILE = \'relay_log_name\'\n  | RELAY_LOG_POS = relay_log_pos\n  | MASTER_HEARTBEAT_PERIOD = interval\n  | MASTER_CONNECT_RETRY = interval\n  | MASTER_RETRY_COUNT = count\n  | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}\n  | MASTER_DELAY = interval\n  | MASTER_COMPRESSION_ALGORITHMS = \'algorithm[,algorithm][,algorithm]\'\n  | MASTER_ZSTD_COMPRESSION_LEVEL = level\n  | MASTER_SSL = {0|1}\n  | MASTER_SSL_CA = \'ca_file_name\'\n  | MASTER_SSL_CAPATH = \'ca_directory_name\'\n  | MASTER_SSL_CERT = \'cert_file_name\'\n  | MASTER_SSL_CRL = \'crl_file_name\'\n  | MASTER_SSL_CRLPATH = \'crl_directory_name\'\n  | MASTER_SSL_KEY = \'key_file_name\'\n  | MASTER_SSL_CIPHER = \'cipher_list\'\n  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}\n  | MASTER_TLS_VERSION = \'protocol_list\'\n  | MASTER_TLS_CIPHERSUITES = \'ciphersuite_list\'\n  | MASTER_PUBLIC_KEY_PATH = \'key_file_name\'\n  | GET_MASTER_PUBLIC_KEY = {0|1}\n  | NETWORK_NAMESPACE = \'namespace\'\n  | IGNORE_SERVER_IDS = (server_id_list),\n  | GTID_ONLY = {0|1}\n}\n\nchannel_option:\n    FOR CHANNEL channel\n\nserver_id_list:\n    [server_id [, server_id] ... ]\n\nCHANGE MASTER TO changes the parameters that the replica server uses\nfor connecting to the source and for reading data from the source. It\nalso updates the contents of the replication metadata repositories (see\nhttps://dev.mysql.com/doc/refman/8.0/en/replica-logs.html). From MySQL\n8.0.23, use CHANGE REPLICATION SOURCE TO in place of CHANGE MASTER TO,\nwhich is deprecated from that release. In releases before MySQL 8.0.23,\nuse CHANGE MASTER TO.\n\nCHANGE MASTER TO requires the REPLICATION_SLAVE_ADMIN privilege (or the\ndeprecated SUPER privilege).\n\nOptions that you do not specify on a CHANGE MASTER TO statement retain\ntheir value, except as indicated in the following discussion. In most\ncases, there is therefore no need to specify options that do not\nchange.\n\nValues used for SOURCE_HOST and other CHANGE REPLICATION SOURCE TO\noptions are checked for linefeed (\\n or 0x0A) characters. The presence\nof such characters in these values causes the statement to fail with an\nerror.\n\nThe optional FOR CHANNEL channel clause enables you to name which\nreplication channel the statement applies to. Providing a FOR CHANNEL\nchannel clause applies the CHANGE MASTER TO statement to a specific\nreplication channel, and is used to add a new channel or modify an\nexisting channel. For example, to add a new channel called channel2:\n\nCHANGE MASTER TO MASTER_HOST=host1, MASTER_PORT=3002 FOR CHANNEL \'channel2\'\n\nIf no clause is named and no extra channels exist, a CHANGE MASTER TO\nstatement applies to the default channel, whose name is the empty\nstring (\"\"). When you have set up multiple replication channels, every\nCHANGE MASTER TO statement must name a channel using the FOR CHANNEL\nchannel clause. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nFor some of the options of the CHANGE MASTER TO statement, you must\nissue a STOP SLAVE statement prior to issuing a CHANGE MASTER TO\nstatement (and a START SLAVE statement afterwards). Sometimes, you only\nneed to stop the replication SQL (applier) thread or the replication\nI/O (receiver) thread, not both:\n\no When the applier thread is stopped, you can execute CHANGE MASTER TO\n  using any combination that is otherwise allowed of RELAY_LOG_FILE,\n  RELAY_LOG_POS, and MASTER_DELAY options, even if the replication\n  receiver thread is running. No other options may be used with this\n  statement when the receiver thread is running.\n\no When the receiver thread is stopped, you can execute CHANGE MASTER TO\n  using any of the options for this statement (in any allowed\n  combination) except RELAY_LOG_FILE, RELAY_LOG_POS, MASTER_DELAY, or\n  MASTER_AUTO_POSITION = 1 even when the applier thread is running.\n\no Both the receiver thread and the applier thread must be stopped\n  before issuing a CHANGE MASTER TO statement that employs\n  MASTER_AUTO_POSITION = 1, GTID_ONLY = 1, or\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS.\n\nYou can check the current state of the replication applier thread and\nreplication receiver thread using SHOW SLAVE STATUS. Note that the\nGroup Replication applier channel (group_replication_applier) has no\nreceiver thread, only an applier thread.\n\nCHANGE MASTER TO statements have a number of side-effects and\ninteractions that you should be aware of beforehand:\n\no CHANGE MASTER TO causes an implicit commit of an ongoing transaction.\n  See https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\no CHANGE MASTER TO causes the previous values for MASTER_HOST,\n  MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS to be written to the\n  error log, along with other information about the replica\'s state\n  prior to execution.\n\no If you are using statement-based replication and temporary tables, it\n  is possible for a CHANGE MASTER TO statement following a STOP SLAVE\n  statement to leave behind temporary tables on the replica. A warning\n  (ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_warn_open_temp_tables_must_be_zero)) is issued\n  whenever this occurs. You can avoid this in such cases by making sure\n  that the value of the Replica_open_temp_tables or\n  Slave_open_temp_tables system status variable is equal to 0 prior to\n  executing such a CHANGE MASTER TO statement.\n\no When using a multithreaded replica (replica_parallel_workers > 0 or\n  slave_parallel_workers > 0), stopping the replica can cause gaps in\n  the sequence of transactions that have been executed from the relay\n  log, regardless of whether the replica was stopped intentionally or\n  otherwise. When such gaps exist, issuing CHANGE MASTER TO fails. The\n  solution in this situation is to issue START SLAVE UNTIL\n  SQL_AFTER_MTS_GAPS which ensures that the gaps are closed. From MySQL\n  8.0.26, the process of checking for gaps in the sequence of\n  transactions is skipped entirely when GTID-based replication and GTID\n  auto-positioning are in use, because gaps in transactions can be\n  resolved using GTID auto-positioning. In that situation, CHANGE\n  MASTER TO can still be used.\n\nThe following options are available for CHANGE MASTER TO statements:\n\no ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}\n\n  Makes the replication channel assign a GTID to replicated\n  transactions that do not have one, enabling replication from a source\n  that does not use GTID-based replication, to a replica that does. For\n  a multi-source replica, you can have a mix of channels that use\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS, and channels that do not. The\n  default is OFF, meaning that the feature is not used.\n\n  LOCAL assigns a GTID including the replica\'s own UUID (the\n  server_uuid setting). uuid assigns a GTID including the specified\n  UUID, such as the server_uuid setting for the replication source\n  server. Using a nonlocal UUID lets you differentiate between\n  transactions that originated on the replica and transactions that\n  originated on the source, and for a multi-source replica, between\n  transactions that originated on different sources. The UUID you\n  choose only has significance for the replica\'s own use. If any of the\n  transactions sent by the source do have a GTID already, that GTID is\n  retained.\n\n  Channels specific to Group Replication cannot use\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS, but an asynchronous\n  replication channel for another source on a server instance that is a\n  Group Replication group member can do so. In that case, do not\n  specify the Group Replication group name as the UUID for creating the\n  GTIDs.\n\n  To set ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS to LOCAL or uuid, the\n  replica must have gtid_mode=ON set, and this cannot be changed\n  afterwards. This option is for use with a source that has binary log\n  file position based replication, so MASTER_AUTO_POSITION=1 cannot be\n  set for the channel. Both the replication SQL thread and the\n  replication I/O (receiver) thread must be stopped before setting this\n  option.\n\n  *Important*:\n\n  A replica set up with ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS on any\n  channel cannot be promoted to replace the replication source server\n  in the event that a failover is required, and a backup taken from the\n  replica cannot be used to restore the replication source server. The\n  same restriction applies to replacing or restoring other replicas\n  that use ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS on any channel.\n\n  For further restrictions and information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon\n  .html.\n\no GET_MASTER_PUBLIC_KEY = {0|1}\n\n  Enables RSA key pair-based password exchange by requesting the public\n  key from the source. The option is disabled by default.\n\n  This option applies to replicas that authenticate with the\n  caching_sha2_password authentication plugin. For connections by\n  accounts that authenticate using this plugin, the source does not\n  send the public key unless requested, so it must be requested or\n  specified in the client. If MASTER_PUBLIC_KEY_PATH is given and\n  specifies a valid public key file, it takes precedence over\n  GET_MASTER_PUBLIC_KEY. If you are using a replication user account\n  that authenticates with the caching_sha2_password plugin (which is\n  the default from MySQL 8.0), and you are not using a secure\n  connection, you must specify either this option or the\n  MASTER_PUBLIC_KEY_PATH option to provide the RSA public key to the\n  replica.\n\no GTID_ONLY = {0|1}\n\n  Stops the replication channel persisting file names and file\n  positions in the replication metadata repositories. GTID_ONLY is\n  available as of MySQL 8.0.27. The GTID_ONLY option is disabled by\n  default for asynchronous replication channels, but it is enabled by\n  default for Group Replication channels, and it cannot be disabled for\n  them.\n\n  For replication channels with this setting, in-memory file positions\n  are still tracked, and file positions can still be observed for\n  debugging purposes in error messages and through interfaces such as\n  SHOW REPLICA STATUS statements (where they are shown as being invalid\n  if they are out of date). However, the writes and reads required to\n  persist and check the file positions are avoided in situations where\n  GTID-based replication does not actually require them, including the\n  transaction queuing and application process.\n\n  This option can be used only if both the replication SQL (applier)\n  thread and replication I/O (receiver) thread are stopped. To set\n  GTID_ONLY = 1 for a replication channel, GTIDs must be in use on the\n  server (gtid_mode = ON), and row-based binary logging must be in use\n  on the source (statement-based replication is not supported). The\n  options REQUIRE_ROW_FORMAT = 1 and SOURCE_AUTO_POSITION = 1 must be\n  set for the replication channel.\n\n  When GTID_ONLY = 1 is set, the replica uses\n  replica_parallel_workers=1 if that system variable is set to zero for\n  the server, so it is always technically a multi-threaded applier.\n  This is because a multi-threaded applier uses saved positions rather\n  than the replication metadata repositories to locate the start of a\n  transaction that it needs to reapply.\n\n  If you disable GTID_ONLY after setting it, the existing relay logs\n  are deleted and the existing known binary log file positions are\n  persisted, even if they are stale. The file positions for the binary\n  log and relay log in the replication metadata repositories might be\n  invalid, and a warning is returned if this is the case. Provided that\n  SOURCE_AUTO_POSITION is still enabled, GTID auto-positioning is used\n  to provide the correct positioning.\n\n  If you also disable SOURCE_AUTO_POSITION, the file positions for the\n  binary log and relay log in the replication metadata repositories are\n  used for positioning if they are valid. If they are marked as\n  invalid, you must provide a valid binary log file name and position\n  (SOURCE_LOG_FILE and SOURCE_LOG_POS). If you also provide a relay log\n  file name and position (RELAY_LOG_FILE and RELAY_LOG_POS), the relay\n  logs are preserved and the applier position is set to the stated\n  position. GTID auto-skip ensures that any transactions already\n  applied are skipped even if the eventual applier position is not\n  correct.\n\no IGNORE_SERVER_IDS = (server_id_list)\n\n  Makes the replica ignore events originating from the specified\n  servers. The option takes a comma-separated list of 0 or more server\n  IDs. Log rotation and deletion events from the servers are not\n  ignored, and are recorded in the relay log.\n\n  In circular replication, the originating server normally acts as the\n  terminator of its own events, so that they are not applied more than\n  once. Thus, this option is useful in circular replication when one of\n  the servers in the circle is removed. Suppose that you have a\n  circular replication setup with 4 servers, having server IDs 1, 2, 3,\n  and 4, and server 3 fails. When bridging the gap by starting\n  replication from server 2 to server 4, you can include\n  IGNORE_SERVER_IDS = (3) in the CHANGE MASTER TO statement that you\n  issue on server 4 to tell it to use server 2 as its source instead of\n  server 3. Doing so causes it to ignore and not to propagate any\n  statements that originated with the server that is no longer in use.\n\n  If IGNORE_SERVER_IDS contains the server\'s own ID and the server was\n  started with the --replicate-same-server-id option enabled, an error\n  results.\n\n  *Note*:\n\n  When global transaction identifiers (GTIDs) are used for replication,\n  transactions that have already been applied are automatically\n  ignored, so the IGNORE_SERVER_IDS function is not required and is\n  deprecated. If gtid_mode=ON is set for the server, a deprecation\n  warning is issued if you include the IGNORE_SERVER_IDS option in a\n  CHANGE MASTER TO statement.\n\n  The source metadata repository and the output of SHOW REPLICA STATUS\n  provide the list of servers that are currently ignored. For more\n  information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replica-logs-status.html, and\n  [HELP SHOW REPLICA STATUS].\n\n  If a CHANGE MASTER TO statement is issued without any\n  IGNORE_SERVER_IDS option, any existing list is preserved. To clear\n  the list of ignored servers, it is necessary to use the option with\n  an empty list:\n\nCHANGE MASTER TO IGNORE_SERVER_IDS = ();\n\n  RESET REPLICA ALL clears IGNORE_SERVER_IDS.\n\n  *Note*:\n\n  A deprecation warning is issued if SET GTID_MODE=ON is issued when\n  any channel has existing server IDs set with IGNORE_SERVER_IDS.\n  Before starting GTID-based replication, check for and clear all\n  ignored server ID lists on the servers involved. The SHOW REPLICA\n  STATUS statement displays the list of ignored IDs, if there is one.\n  If you do receive the deprecation warning, you can still clear a list\n  after gtid_mode=ON is set by issuing a CHANGE MASTER TO statement\n  containing the IGNORE_SERVER_IDS option with an empty list.\n\no MASTER_AUTO_POSITION = {0|1}\n\n  Makes the replica attempt to connect to the source using the\n  auto-positioning feature of GTID-based replication, rather than a\n  binary log file based position. This option is used to start a\n  replica using GTID-based replication. The default is 0, meaning that\n  GTID auto-positioning and GTID-based replication are not used. This\n  option can be used with CHANGE MASTER TO only if both the replication\n  SQL (applier) thread and replication I/O (receiver) thread are\n  stopped.\n\n  Both the replica and the source must have GTIDs enabled\n  (GTID_MODE=ON, ON_PERMISSIVE, or OFF_PERMISSIVE on the replica, and\n  GTID_MODE=ON on the source). MASTER_LOG_FILE, MASTER_LOG_POS,\n  RELAY_LOG_FILE, and RELAY_LOG_POS cannot be specified together with\n  MASTER_AUTO_POSITION = 1. If multi-source replication is enabled on\n  the replica, you need to set the MASTER_AUTO_POSITION = 1 option for\n  each applicable replication channel.\n\n  With MASTER_AUTO_POSITION = 1 set, in the initial connection\n  handshake, the replica sends a GTID set containing the transactions\n  that it has already received, committed, or both. The source responds\n  by sending all transactions recorded in its binary log whose GTID is\n  not included in the GTID set sent by the replica. This exchange\n  ensures that the source only sends the transactions with a GTID that\n  the replica has not already recorded or committed. If the replica\n  receives transactions from more than one source, as in the case of a\n  diamond topology, the auto-skip function ensures that the\n  transactions are not applied twice. For details of how the GTID set\n  sent by the replica is computed, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positi\n  oning.html.\n\n  If any of the transactions that should be sent by the source have\n  been purged from the source\'s binary log, or added to the set of\n  GTIDs in the gtid_purged system variable by another method, the\n  source sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_master_has_purged_required_gtids) to the replica, and\n  replication does not start. The GTIDs of the missing purged\n  transactions are identified and listed in the source\'s error log in\n  the warning message ER_FOUND_MISSING_GTIDS\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_found_missing_gtids). Also, if during the exchange of\n  transactions it is found that the replica has recorded or committed\n  transactions with the source\'s UUID in the GTID, but the source\n  itself has not committed them, the source sends the error\n  ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_slave_has_more_gtids_than_master) to the replica and\n  replication does not start. For information on how to handle these\n  situations, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positi\n  oning.html.\n\n  You can see whether replication is running with GTID auto-positioning\n  enabled by checking the Performance Schema\n  replication_connection_status table or the output of SHOW REPLICA\n  STATUS. Disabling the MASTER_AUTO_POSITION option again makes the\n  replica revert to file-based replication.\n\no MASTER_BIND = \'interface_name\'\n\n  Determines which of the replica\'s network interfaces is chosen for\n  connecting to the source, for use on replicas that have multiple\n  network interfaces. Specify the IP address of the network interface.\n  The maximum length of the string value is 255 characters.\n\n  The IP address configured with this option, if any, can be seen in\n  the Master_Bind column of the output from SHOW REPLICA STATUS. In the\n  source metadata repository table mysql.slave_master_info, the value\n  can be seen as the Master_bind column. The ability to bind a replica\n  to a specific network interface is also supported by NDB Cluster.\n\no MASTER_COMPRESSION_ALGORITHMS = \'algorithm[,algorithm][,algorithm]\'\n\n  Specifies one, two, or three of the permitted compression algorithms\n  for connections to the replication source server, separated by\n  commas. The maximum length of the string value is 99 characters. The\n  default value is uncompressed.\n\n  The available algorithms are zlib, zstd, and uncompressed, the same\n  as for the protocol_compression_algorithms system variable. The\n  algorithms can be specified in any order, but it is not an order of\n  preference - the algorithm negotiation process attempts to use zlib,\n  then zstd, then uncompressed, if they are specified.\n  MASTER_COMPRESSION_ALGORITHMS is available as of MySQL 8.0.18.\n\n  The value of MASTER_COMPRESSION_ALGORITHMS applies only if the\n  replica_compressed_protocol or slave_compressed_protocol system\n  variable is disabled. If replica_compressed_protocol or\n  slave_compressed_protocol is enabled, it takes precedence over\n  MASTER_COMPRESSION_ALGORITHMS and connections to the source use zlib\n  compression if both source and replica support that algorithm. For\n  more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/connection-compression-contro\n  l.html.\n\n  Binary log transaction compression (available as of MySQL 8.0.20),\n  which is activated by the binlog_transaction_compression system\n  variable, can also be used to save bandwidth. If you do this in\n  combination with connection compression, connection compression has\n  less opportunity to act on the data, but can still compress headers\n  and those events and transaction payloads that are uncompressed. For\n  more information on binary log transaction compression, see\n  https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compre\n  ssion.html.\n\no MASTER_CONNECT_RETRY = interval\n\n  Specifies the interval in seconds between the reconnection attempts\n  that the replica makes after the connection to the source times out.\n  The default interval is 60.\n\n  The attempts are limited by the MASTER_RETRY_COUNT option. If both\n  the default settings are used, the replica waits 60 seconds between\n  reconnection attempts (MASTER_CONNECT_RETRY=60), and keeps attempting\n  to reconnect at this rate for 60 days (MASTER_RETRY_COUNT=86400).\n  These values are recorded in the source metadata repository and shown\n  in the replication_connection_configuration Performance Schema table.\n\no MASTER_DELAY = interval\n\n  Specifies how many seconds behind the source the replica must lag. An\n  event received from the source is not executed until at least\n  interval seconds later than its execution on the source. interval\n  must be a nonnegative integer in the range from 0 to 231−1. The\n  default is 0. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-delayed.html.\n\n  A CHANGE MASTER TO statement employing the MASTER_DELAY option can be\n  executed on a running replica when the replication SQL thread is\n  stopped.\n\no MASTER_HEARTBEAT_PERIOD = interval\n\n  Controls the heartbeat interval, which stops the connection timeout\n  occurring in the absence of data if the connection is still good. A\n  heartbeat signal is sent to the replica after that number of seconds,\n  and the waiting period is reset whenever the source\'s binary log is\n  updated with an event. Heartbeats are therefore sent by the source\n  only if there are no unsent events in the binary log file for a\n  period longer than this.\n\n  The heartbeat interval interval is a decimal value having the range 0\n  to 4294967 seconds and a resolution in milliseconds; the smallest\n  nonzero value is 0.001. Setting interval to 0 disables heartbeats\n  altogether. The heartbeat interval defaults to half the value of the\n  replica_net_timeout or slave_net_timeout system variable. It is\n  recorded in the source metadata repository and shown in the\n  replication_connection_configuration Performance Schema table.\n  Issuing RESET REPLICA resets the heartbeat interval to the default\n  value.\n\n  The system variable replica_net_timeout (from MySQL 8.0.26) or\n  slave_net_timeout (before MySQL 8.0.26) specifies the number of\n  seconds that the replica waits for either more data or a heartbeat\n  signal from the source, before the replica considers the connection\n  broken, aborts the read, and tries to reconnect. The default value is\n  60 seconds (one minute). Note that a change to the value or default\n  setting of replica_net_timeout or slave_net_timeout does not\n  automatically change the heartbeat interval, whether that has been\n  set explicitly or is using a previously calculated default. A warning\n  is issued if you set the global value of replica_net_timeout or\n  slave_net_timeout to a value less than that of the current heartbeat\n  interval. If replica_net_timeout or slave_net_timeout is changed, you\n  must also issue CHANGE MASTER TO to adjust the heartbeat interval to\n  an appropriate value so that the heartbeat signal occurs before the\n  connection timeout. If you do not do this, the heartbeat signal has\n  no effect, and if no data is received from the source, the replica\n  can make repeated reconnection attempts, creating zombie dump\n  threads.\n\no MASTER_HOST = \'host_name\'\n\n  The host name or IP address of the replication source server. The\n  replica uses this to connect to the source. The maximum length of the\n  string value is 255 characters. Before MySQL 8.0.17 it was 60\n  characters.\n\n  If you specify MASTER_HOST or MASTER_PORT, the replica assumes that\n  the source server is different from before (even if the option value\n  is the same as its current value.) In this case, the old values for\n  the source\'s binary log file name and position are considered no\n  longer applicable, so if you do not specify MASTER_LOG_FILE and\n  MASTER_LOG_POS in the statement, MASTER_LOG_FILE=\'\' and\n  MASTER_LOG_POS=4 are silently appended to it.\n\n  Setting MASTER_HOST=\'\' (that is, setting its value explicitly to an\n  empty string) is not the same as not setting MASTER_HOST at all.\n  Trying to set MASTER_HOST to an empty string fails with an error.\n\no MASTER_LOG_FILE = \'source_log_name\', MASTER_LOG_POS = source_log_pos\n\n  The binary log file name, and the location in that file, at which the\n  replication I/O (receiver) thread begins reading from the source\'s\n  binary log the next time the thread starts. Specify these options if\n  you are using binary log file position based replication.\n\n  MASTER_LOG_FILE must include the numeric suffix of a specific binary\n  log file that is available on the source server, for example,\n  MASTER_LOG_FILE=\'binlog.000145\'. The maximum length of the string\n  value is 511 characters.\n\n  MASTER_LOG_POS is the numeric position for the replica to start\n  reading in that file. MASTER_LOG_POS=4 represents the start of the\n  events in a binary log file.\n\n  If you specify either of MASTER_LOG_FILE or MASTER_LOG_POS, you\n  cannot specify MASTER_AUTO_POSITION = 1, which is for GTID-based\n  replication.\n\n  If neither of MASTER_LOG_FILE or MASTER_LOG_POS is specified, the\n  replica uses the last coordinates of the replication SQL (applier)\n  thread before CHANGE MASTER TO was issued. This ensures that there is\n  no discontinuity in replication, even if the replication SQL\n  (applier) thread was late compared to the replication I/O (receiver)\n  thread.\n\no MASTER_PASSWORD = \'password\'\n\n  The password for the replication user account to use for connecting\n  to the replication source server. The maximum length of the string\n  value is 32 characters. If you specify MASTER_PASSWORD, MASTER_USER\n  is also required.\n\n  The password used for a replication user account in a CHANGE MASTER\n  TO statement is limited to 32 characters in length. Trying to use a\n  password of more than 32 characters causes CHANGE MASTER TO to fail.\n\n  The password is masked in MySQL Server\'s logs, Performance Schema\n  tables, and SHOW PROCESSLIST statements.\n\no MASTER_PORT = port_num\n\n  The TCP/IP port number that the replica uses to connect to the\n  replication source server.\n\n  *Note*:\n\n  Replication cannot use Unix socket files. You must be able to connect\n  to the replication source server using TCP/IP.\n\n  If you specify MASTER_HOST or MASTER_PORT, the replica assumes that\n  the source server is different from before (even if the option value\n  is the same as its current value). In this case, the old values for\n  the source\'s binary log file name and position are considered no\n  longer applicable, so if you do not specify MASTER_LOG_FILE and\n  MASTER_LOG_POS in the statement, MASTER_LOG_FILE=\'\' and\n  MASTER_LOG_POS=4 are silently appended to it.\n\no MASTER_PUBLIC_KEY_PATH = \'key_file_name\'\n\n  Enables RSA key pair-based password exchange by providing the path\n  name to a file containing a replica-side copy of the public key\n  required by the source. The file must be in PEM format. The maximum\n  length of the string value is 511 characters.\n\n  This option applies to replicas that authenticate with the\n  sha256_password or caching_sha2_password authentication plugin. (For\n  sha256_password, MASTER_PUBLIC_KEY_PATH can be used only if MySQL was\n  built using OpenSSL.) If you are using a replication user account\n  that authenticates with the caching_sha2_password plugin (which is\n  the default from MySQL 8.0), and you are not using a secure\n  connection, you must specify either this option or the\n  GET_MASTER_PUBLIC_KEY=1 option to provide the RSA public key to the\n  replica.\n\no MASTER_RETRY_COUNT = count\n\n  Sets the maximum number of reconnection attempts that the replica\n  makes after the connection to the source times out, as determined by\n  the replica_net_timeout or slave_net_timeout system variable. If the\n  replica does need to reconnect, the first retry occurs immediately\n  after the timeout. The default is 86400 attempts.\n\n  The interval between the attempts is specified by the\n  MASTER_CONNECT_RETRY option. If both the default settings are used,\n  the replica waits 60 seconds between reconnection attempts\n  (MASTER_CONNECT_RETRY=60), and keeps attempting to reconnect at this\n  rate for 60 days (MASTER_RETRY_COUNT=86400). A setting of 0 for\n  MASTER_RETRY_COUNT means that there is no limit on the number of\n  reconnection attempts, so the replica keeps trying to reconnect\n  indefinitely.\n\n  The values for MASTER_CONNECT_RETRY and MASTER_RETRY_COUNT are\n  recorded in the source metadata repository and shown in the\n  replication_connection_configuration Performance Schema table.\n  MASTER_RETRY_COUNT supersedes the --master-retry-count server startup\n  option.\n\no MASTER_SSL = {0|1}\n\n  Specify whether the replica encrypts the replication connection. The\n  default is 0, meaning that the replica does not encrypt the\n  replication connection. If you set MASTER_SSL=1, you can configure\n  the encryption using the MASTER_SSL_xxx and MASTER_TLS_xxx options.\n\n  Setting MASTER_SSL=1 for a replication connection and then setting no\n  further MASTER_SSL_xxx options corresponds to setting\n  --ssl-mode=REQUIRED for the client, as described in\n  https://dev.mysql.com/doc/refman/8.0/en/connection-options.html#encry\n  pted-connection-options. With MASTER_SSL=1, the connection attempt\n  only succeeds if an encrypted connection can be established. A\n  replication connection does not fall back to an unencrypted\n  connection, so there is no setting corresponding to the\n  --ssl-mode=PREFERRED setting for replication. If MASTER_SSL=0 is set,\n  this corresponds to --ssl-mode=DISABLED.\n\n  *Important*:\n\n  To help prevent sophisticated man-in-the-middle attacks, it is\n  important for the replica to verify the server\'s identity. You can\n  specify additional MASTER_SSL_xxx options to correspond to the\n  settings --ssl-mode=VERIFY_CA and --ssl-mode=VERIFY_IDENTITY, which\n  are a better choice than the default setting to help prevent this\n  type of attack. With these settings, the replica checks that the\n  server\'s certificate is valid, and checks that the host name the\n  replica is using matches the identity in the server\'s certificate. To\n  implement one of these levels of verification, you must first ensure\n  that the CA certificate for the server is reliably available to the\n  replica, otherwise availability issues will result. For this reason,\n  they are not the default setting.\n\no MASTER_SSL_xxx, MASTER_TLS_xxx\n\n  Specify how the replica uses encryption and ciphers to secure the\n  replication connection. These options can be changed even on replicas\n  that are compiled without SSL support. They are saved to the source\n  metadata repository, but are ignored if the replica does not have SSL\n  support enabled. The maximum length of the value for the\n  string-valued MASTER_SSL_xxx and MASTER_TLS_xxx options is 511\n  characters, with the exception of MASTER_TLS_CIPHERSUITES, for which\n  it is 4000 characters.\n\n  The MASTER_SSL_xxx and MASTER_TLS_xxx options perform the same\n  functions as the --ssl-xxx and --tls-xxx client options described in\n  https://dev.mysql.com/doc/refman/8.0/en/connection-options.html#encry\n  pted-connection-options. The correspondence between the two sets of\n  options, and the use of the MASTER_SSL_xxx and MASTER_TLS_xxx options\n  to set up a secure connection, is explained in\n  https://dev.mysql.com/doc/refman/8.0/en/replication-encrypted-connect\n  ions.html.\n\no MASTER_USER = \'user_name\'\n\n  The user name for the replication user account to use for connecting\n  to the replication source server. The maximum length of the string\n  value is 96 characters.\n\n  For Group Replication, this account must exist on every member of the\n  replication group. It is used for distributed recovery if the XCom\n  communication stack is in use for the group, and also used for group\n  communication connections if the MySQL communication stack is in use\n  for the group. With the MySQL communication stack, the account must\n  have the GROUP_REPLICATION_STREAM permission.\n\n  It is possible to set an empty user name by specifying\n  MASTER_USER=\'\', but the replication channel cannot be started with an\n  empty user name. In releases before MySQL 8.0.21, only set an empty\n  MASTER_USER user name if you need to clear previously used\n  credentials from the replication metadata repositories for security\n  purposes. Do not use the channel afterwards, due to a bug in these\n  releases that can substitute a default user name if an empty user\n  name is read from the repositories (for example, during an automatic\n  restart of a Group Replication channel). From MySQL 8.0.21, it is\n  valid to set an empty MASTER_USER user name and use the channel\n  afterwards if you always provide user credentials using the START\n  REPLICA statement or START GROUP_REPLICATION statement that starts\n  the replication channel. This approach means that the replication\n  channel always needs operator intervention to restart, but the user\n  credentials are not recorded in the replication metadata\n  repositories.\n\n  *Important*:\n\n  To connect to the source using a replication user account that\n  authenticates with the caching_sha2_password plugin, you must either\n  set up a secure connection as described in\n  https://dev.mysql.com/doc/refman/8.0/en/replication-encrypted-connect\n  ions.html, or enable the unencrypted connection to support password\n  exchange using an RSA key pair. The caching_sha2_password\n  authentication plugin is the default for new users created from MySQL\n  8.0 (for details, see\n  https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authen\n  tication.html). If the user account that you create or use for\n  replication uses this authentication plugin, and you are not using a\n  secure connection, you must enable RSA key pair-based password\n  exchange for a successful connection. You can do this using either\n  the MASTER_PUBLIC_KEY_PATH option or the GET_MASTER_PUBLIC_KEY=1\n  option for this statement.\n\no MASTER_ZSTD_COMPRESSION_LEVEL = level\n\n  The compression level to use for connections to the replication\n  source server that use the zstd compression algorithm. The permitted\n  levels are from 1 to 22, with larger values indicating increasing\n  levels of compression. The default level is 3.\n  MASTER_ZSTD_COMPRESSION_LEVEL is available as of MySQL 8.0.18.\n\n  The compression level setting has no effect on connections that do\n  not use zstd compression. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/connection-compression-contro\n  l.html.\n\no NETWORK_NAMESPACE = \'namespace\'\n\n  The network namespace to use for TCP/IP connections to the\n  replication source server or, if the MySQL communication stack is in\n  use, for Group Replication\'s group communication connections. The\n  maximum length of the string value is 64 characters. If this option\n  is omitted, connections from the replica use the default (global)\n  namespace. On platforms that do not implement network namespace\n  support, failure occurs when the replica attempts to connect to the\n  source. For information about network namespaces, see\n  https://dev.mysql.com/doc/refman/8.0/en/network-namespace-support.htm\n  l. NETWORK_NAMESPACE is available as of MySQL 8.0.22.\n\no PRIVILEGE_CHECKS_USER = {NULL | \'account\'}\n\n  Names a user account that supplies a security context for the\n  specified channel. NULL, which is the default, means no security\n  context is used. PRIVILEGE_CHECKS_USER is available as of MySQL\n  8.0.18.\n\n  The user name and host name for the user account must follow the\n  syntax described in\n  https://dev.mysql.com/doc/refman/8.0/en/account-names.html, and the\n  user must not be an anonymous user (with a blank user name) or the\n  CURRENT_USER. The account must have the REPLICATION_APPLIER\n  privilege, plus the required privileges to execute the transactions\n  replicated on the channel. For details of the privileges required by\n  the account, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html. When you restart the replication channel, the privilege checks\n  are applied from that point on. If you do not specify a channel and\n  no other channels exist, the statement is applied to the default\n  channel.\n\n  The use of row-based binary logging is strongly recommended when\n  PRIVILEGE_CHECKS_USER is set, and you can set REQUIRE_ROW_FORMAT to\n  enforce this. For example, to start privilege checks on the channel\n  channel_1 on a running replica, issue the following statements:\n\nmysql> STOP REPLICA FOR CHANNEL \'channel_1\';\nmysql> CHANGE MASTER TO\n         PRIVILEGE_CHECKS_USER = \'priv_repl\'@\'%.example.com\',\n         REQUIRE_ROW_FORMAT = 1,\n         FOR CHANNEL \'channel_1\';\nmysql> START REPLICA FOR CHANNEL \'channel_1\';\n\n  For releases from MySQL 8.0.22, use START REPLICA and STOP REPLICA,\n  and for releases before MySQL 8.0.22, use START SLAVE and STOP SLAVE.\n  The statements work in the same way, only the terminology has\n  changed.\n\no RELAY_LOG_FILE = \'relay_log_file\' , RELAY_LOG_POS = \'relay_log_pos\'\n\n  The relay log file name, and the location in that file, at which the\n  replication SQL thread begins reading from the replica\'s relay log\n  the next time the thread starts. RELAY_LOG_FILE can use either an\n  absolute or relative path, and uses the same base name as\n  MASTER_LOG_FILE. The maximum length of the string value is 511\n  characters.\n\n  A CHANGE MASTER TO statement using RELAY_LOG_FILE, RELAY_LOG_POS, or\n  both options can be executed on a running replica when the\n  replication SQL thread is stopped. Relay logs are preserved if at\n  least one of the replication SQL (applier) thread and the replication\n  I/O (receiver) thread is running. If both threads are stopped, all\n  relay log files are deleted unless at least one of RELAY_LOG_FILE or\n  RELAY_LOG_POS is specified. For the Group Replication applier channel\n  (group_replication_applier), which only has an applier thread and no\n  receiver thread, this is the case if the applier thread is stopped,\n  but with that channel you cannot use the RELAY_LOG_FILE and\n  RELAY_LOG_POS options.\n\no REQUIRE_ROW_FORMAT = {0|1}\n\n  Permits only row-based replication events to be processed by the\n  replication channel. This option prevents the replication applier\n  from taking actions such as creating temporary tables and executing\n  LOAD DATA INFILE requests, which increases the security of the\n  channel. The REQUIRE_ROW_FORMAT option is disabled by default for\n  asynchronous replication channels, but it is enabled by default for\n  Group Replication channels, and it cannot be disabled for them. For\n  more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html. REQUIRE_ROW_FORMAT is available as of MySQL 8.0.19.\n\no REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}\n\n  Enables a replica to select its own policy for primary key checks.\n  The default is STREAM. REQUIRE_TABLE_PRIMARY_KEY_CHECK is available\n  as of MySQL 8.0.20.\n\n  When the option is set to ON for a replication channel, the replica\n  always uses the value ON for the sql_require_primary_key system\n  variable in replication operations, requiring a primary key. When the\n  option is set to OFF, the replica always uses the value OFF for the\n  sql_require_primary_key system variable in replication operations, so\n  that a primary key is never required, even if the source required\n  one. When the REQUIRE_TABLE_PRIMARY_KEY_CHECK option is set to\n  STREAM, which is the default, the replica uses whatever value is\n  replicated from the source for each transaction.\n\n  For multisource replication, setting REQUIRE_TABLE_PRIMARY_KEY_CHECK\n  to ON or OFF enables a replica to normalize behavior across the\n  replication channels for different sources, and keep a consistent\n  setting for the sql_require_primary_key system variable. Using ON\n  safeguards against the accidental loss of primary keys when multiple\n  sources update the same set of tables. Using OFF allows sources that\n  can manipulate primary keys to work alongside sources that cannot.\n\n  When PRIVILEGE_CHECKS_USER is set, setting\n  REQUIRE_TABLE_PRIMARY_KEY_CHECK to ON or OFF means that the user\n  account does not need session administration level privileges to set\n  restricted session variables, which are required to change the value\n  of sql_require_primary_key to match the source\'s setting for each\n  transaction. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html.\n\no SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}\n\n  Activates the asynchronous connection failover mechanism for a\n  replication channel if one or more alternative replication source\n  servers are available (so when there are multiple MySQL servers or\n  groups of servers that share the replicated data).\n  SOURCE_CONNECTION_AUTO_FAILOVER is available as of MySQL 8.0.22. The\n  default is 0, meaning that the mechanism is not activated. For full\n  information and instructions to set up this feature, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-conn\n  ection-failover-replica.html.\n\n  The asynchronous connection failover mechanism takes over after the\n  reconnection attempts controlled by MASTER_CONNECT_RETRY and\n  MASTER_RETRY_COUNT are exhausted. It reconnects the replica to an\n  alternative source chosen from a specified source list, which you\n  manage using the asynchronous_connection_failover_add_source and\n  asynchronous_connection_failover_delete_source functions. To add and\n  remove managed groups of servers, use the\n  asynchronous_connection_failover_add_managed and\n  asynchronous_connection_failover_delete_managed functions instead.\n  For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-conn\n  ection-failover.html.\n\n  *Important*:\n\n   1. You can only set SOURCE_CONNECTION_AUTO_FAILOVER = 1 when GTID\n      auto-positioning is in use (MASTER_AUTO_POSITION = 1).\n\n   2. When you set SOURCE_CONNECTION_AUTO_FAILOVER = 1, set\n      MASTER_RETRY_COUNT and MASTER_CONNECT_RETRY to minimal numbers\n      that just allow a few retry attempts with the same source in a\n      short time, in case the connection failure is caused by a\n      transient network outage. Otherwise the asynchronous connection\n      failover mechanism cannot be activated promptly. Suitable values\n      are MASTER_RETRY_COUNT=3 and MASTER_CONNECT_RETRY=10, which make\n      the replica retry the connection 3 times with 10-second intervals\n      between.\n\n   3. When you set SOURCE_CONNECTION_AUTO_FAILOVER = 1, the replication\n      metadata repositories must contain the credentials for a\n      replication user account that can be used to connect to all the\n      servers on the source list for the replication channel. These\n      credentials can be set using the CHANGE REPLICATION SOURCE TO\n      statement with the MASTER_USER and MASTER_PASSWORD options. For\n      more information, see\n      https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-\n      connection-failover.html.\n\n   4. From MySQL 8.0.27, when you set SOURCE_CONNECTION_AUTO_FAILOVER =\n      1, asynchronous connection failover for replicas is automatically\n      activated if this replication channel is on a Group Replication\n      primary in a group in single-primary mode. With this function\n      active, if the primary that is replicating goes offline or into\n      an error state, the new primary starts replication on the same\n      channel when it is elected. If you want to use the function, this\n      replication channel must also be set up on all the secondary\n      servers in the replication group, and on any new joining members.\n      (If the servers are provisioned using MySQL\'s clone\n      functionality, this all happens automatically.) If you do not\n      want to use the function, disable it by using the\n      group_replication_disable_member_action function to disable the\n      Group Replication member action\n      mysql_start_failover_channels_if_primary, which is enabled by\n      default. For more information, see\n      https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-\n      connection-failover-replica.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html'),
(578, 'CHANGE REPLICATION FILTER', 43, 'Syntax:\nCHANGE REPLICATION FILTER filter[, filter]\n	[, ...] [FOR CHANNEL channel]\n\nfilter: {\n    REPLICATE_DO_DB = (db_list)\n  | REPLICATE_IGNORE_DB = (db_list)\n  | REPLICATE_DO_TABLE = (tbl_list)\n  | REPLICATE_IGNORE_TABLE = (tbl_list)\n  | REPLICATE_WILD_DO_TABLE = (wild_tbl_list)\n  | REPLICATE_WILD_IGNORE_TABLE = (wild_tbl_list)\n  | REPLICATE_REWRITE_DB = (db_pair_list)\n}\n\ndb_list:\n    db_name[, db_name][, ...]\n\ntbl_list:\n    db_name.table_name[, db_name.table_name][, ...]\nwild_tbl_list:\n    \'db_pattern.table_pattern\'[, \'db_pattern.table_pattern\'][, ...]\n\ndb_pair_list:\n    (db_pair)[, (db_pair)][, ...]\n\ndb_pair:\n    from_db, to_db\n\nCHANGE REPLICATION FILTER sets one or more replication filtering rules\non the replica in the same way as starting the replica mysqld with\nreplication filtering options such as --replicate-do-db or\n--replicate-wild-ignore-table. Filters set using this statement differ\nfrom those set using the server options in two key respects:\n\n1. The statement does not require restarting the server to take effect,\n   only that the replication SQL thread be stopped using STOP REPLICA\n   SQL_THREAD first (and restarted with START REPLICA SQL_THREAD\n   afterwards).\n\n2. The effects of the statement are not persistent; any filters set\n   using CHANGE REPLICATION FILTER are lost following a restart of the\n   replica mysqld.\n\nCHANGE REPLICATION FILTER requires the REPLICATION_SLAVE_ADMIN\nprivilege (or the deprecated SUPER privilege).\n\nUse the FOR CHANNEL channel clause to make a replication filter\nspecific to a replication channel, for example on a multi-source\nreplica. Filters applied without a specific FOR CHANNEL clause are\nconsidered global filters, meaning that they are applied to all\nreplication channels.\n\nGlobal replication filters cannot be set on a MySQL server instance\nthat is configured for Group Replication, because filtering\ntransactions on some servers would make the group unable to reach\nagreement on a consistent state. Channel specific replication filters\ncan be set on replication channels that are not directly involved with\nGroup Replication, such as where a group member also acts as a replica\nto a source that is outside the group. They cannot be set on the\ngroup_replication_applier or group_replication_recovery channels.\n\nThe following list shows the CHANGE REPLICATION FILTER options and how\nthey relate to --replicate-* server options:\n\no REPLICATE_DO_DB: Include updates based on database name. Equivalent\n  to --replicate-do-db.\n\no REPLICATE_IGNORE_DB: Exclude updates based on database name.\n  Equivalent to --replicate-ignore-db.\n\no REPLICATE_DO_TABLE: Include updates based on table name. Equivalent\n  to --replicate-do-table.\n\no REPLICATE_IGNORE_TABLE: Exclude updates based on table name.\n  Equivalent to --replicate-ignore-table.\n\no REPLICATE_WILD_DO_TABLE: Include updates based on wildcard pattern\n  matching table name. Equivalent to --replicate-wild-do-table.\n\no REPLICATE_WILD_IGNORE_TABLE: Exclude updates based on wildcard\n  pattern matching table name. Equivalent to\n  --replicate-wild-ignore-table.\n\no REPLICATE_REWRITE_DB: Perform updates on replica after substituting\n  new name on replica for specified database on source. Equivalent to\n  --replicate-rewrite-db.\n\nThe precise effects of REPLICATE_DO_DB and REPLICATE_IGNORE_DB filters\nare dependent on whether statement-based or row-based replication is in\neffect. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-rules.html, for\nmore information.\n\nMultiple replication filtering rules can be created in a single CHANGE\nREPLICATION FILTER statement by separating the rules with commas, as\nshown here:\n\nCHANGE REPLICATION FILTER\n    REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);\n\nIssuing the statement just shown is equivalent to starting the replica\nmysqld with the options --replicate-do-db=d1 --replicate-ignore-db=d2.\n\nOn a multi-source replica, which uses multiple replication channels to\nprocess transaction from different sources, use the FOR CHANNEL channel\nclause to set a replication filter on a replication channel:\n\nCHANGE REPLICATION FILTER REPLICATE_DO_DB = (d1) FOR CHANNEL channel_1;\n\nThis enables you to create a channel specific replication filter to\nfilter out selected data from a source. When a FOR CHANNEL clause is\nprovided, the replication filter statement acts on that replication\nchannel, removing any existing replication filter which has the same\nfilter type as the specified replication filters, and replacing them\nwith the specified filter. Filter types not explicitly listed in the\nstatement are not modified. If issued against a replication channel\nwhich is not configured, the statement fails with an\nER_SLAVE_CONFIGURATION error. If issued against Group Replication\nchannels, the statement fails with an\nER_SLAVE_CHANNEL_OPERATION_NOT_ALLOWED error.\n\nOn a replica with multiple replication channels configured, issuing\nCHANGE REPLICATION FILTER with no FOR CHANNEL clause configures the\nreplication filter for every configured replication channel, and for\nthe global replication filters. For every filter type, if the filter\ntype is listed in the statement, then any existing filter rules of that\ntype are replaced by the filter rules specified in the most recently\nissued statement, otherwise the old value of the filter type is\nretained. For more information see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-rules-channel-based\n-filters.html.\n\nIf the same filtering rule is specified multiple times, only the last\nsuch rule is actually used. For example, the two statements shown here\nhave exactly the same effect, because the first REPLICATE_DO_DB rule in\nthe first statement is ignored:\n\nCHANGE REPLICATION FILTER\n    REPLICATE_DO_DB = (db1, db2), REPLICATE_DO_DB = (db3, db4);\n\nCHANGE REPLICATION FILTER\n    REPLICATE_DO_DB = (db3, db4);\n\n*Caution*:\n\nThis behavior differs from that of the --replicate-* filter options\nwhere specifying the same option multiple times causes the creation of\nmultiple filter rules.\n\nNames of tables and database not containing any special characters need\nnot be quoted. Values used with REPLICATION_WILD_TABLE and\nREPLICATION_WILD_IGNORE_TABLE are string expressions, possibly\ncontaining (special) wildcard characters, and so must be quoted. This\nis shown in the following example statements:\n\nCHANGE REPLICATION FILTER\n    REPLICATE_WILD_DO_TABLE = (\'db1.old%\');\n\nCHANGE REPLICATION FILTER\n    REPLICATE_WILD_IGNORE_TABLE = (\'db1.new%\', \'db2.new%\');\n\nValues used with REPLICATE_REWRITE_DB represent pairs of database\nnames; each such value must be enclosed in parentheses. The following\nstatement rewrites statements occurring on database db1 on the source\nto database db2 on the replica:\n\nCHANGE REPLICATION FILTER REPLICATE_REWRITE_DB = ((db1, db2));\n\nThe statement just shown contains two sets of parentheses, one\nenclosing the pair of database names, and the other enclosing the\nentire list. This is perhaps more easily seen in the following example,\nwhich creates two rewrite-db rules, one rewriting database dbA to dbB,\nand one rewriting database dbC to dbD:\n\nCHANGE REPLICATION FILTER\n  REPLICATE_REWRITE_DB = ((dbA, dbB), (dbC, dbD));\n\nThe CHANGE REPLICATION FILTER statement replaces replication filtering\nrules only for the filter types and replication channels affected by\nthe statement, and leaves other rules and channels unchanged. If you\nwant to unset all filters of a given type, set the filter\'s value to an\nexplicitly empty list, as shown in this example, which removes all\nexisting REPLICATE_DO_DB and REPLICATE_IGNORE_DB rules:\n\nCHANGE REPLICATION FILTER\n    REPLICATE_DO_DB = (), REPLICATE_IGNORE_DB = ();\n\nSetting a filter to empty in this way removes all existing rules, does\nnot create any new ones, and does not restore any rules set at mysqld\nstartup using --replicate-* options on the command line or in the\nconfiguration file.\n\nThe RESET REPLICA ALL statement removes channel specific replication\nfilters that were set on channels deleted by the statement. When the\ndeleted channel or channels are recreated, any global replication\nfilters specified for the replica are copied to them, and no channel\nspecific replication filters are applied.\n\nFor more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-rules.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/change-replication-filter.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/change-replication-filter.html'),
(579, 'CHANGE REPLICATION SOURCE TO', 43, 'Syntax:\nCHANGE REPLICATION SOURCE TO option [, option] ... [ channel_option ]\n\noption: {\n    SOURCE_BIND = \'interface_name\'\n  | SOURCE_HOST = \'host_name\'\n  | SOURCE_USER = \'user_name\'\n  | SOURCE_PASSWORD = \'password\'\n  | SOURCE_PORT = port_num\n  | PRIVILEGE_CHECKS_USER = {NULL | \'account\'}\n  | REQUIRE_ROW_FORMAT = {0|1}\n  | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF | GENERATE}\n  | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}\n  | SOURCE_LOG_FILE = \'source_log_name\'\n  | SOURCE_LOG_POS = source_log_pos\n  | SOURCE_AUTO_POSITION = {0|1}\n  | RELAY_LOG_FILE = \'relay_log_name\'\n  | RELAY_LOG_POS = relay_log_pos\n  | SOURCE_HEARTBEAT_PERIOD = interval\n  | SOURCE_CONNECT_RETRY = interval\n  | SOURCE_RETRY_COUNT = count\n  | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}\n  | SOURCE_DELAY = interval\n  | SOURCE_COMPRESSION_ALGORITHMS = \'algorithm[,algorithm][,algorithm]\'\n  | SOURCE_ZSTD_COMPRESSION_LEVEL = level\n  | SOURCE_SSL = {0|1}\n  | SOURCE_SSL_CA = \'ca_file_name\'\n  | SOURCE_SSL_CAPATH = \'ca_directory_name\'\n  | SOURCE_SSL_CERT = \'cert_file_name\'\n  | SOURCE_SSL_CRL = \'crl_file_name\'\n  | SOURCE_SSL_CRLPATH = \'crl_directory_name\'\n  | SOURCE_SSL_KEY = \'key_file_name\'\n  | SOURCE_SSL_CIPHER = \'cipher_list\'\n  | SOURCE_SSL_VERIFY_SERVER_CERT = {0|1}\n  | SOURCE_TLS_VERSION = \'protocol_list\'\n  | SOURCE_TLS_CIPHERSUITES = \'ciphersuite_list\'\n  | SOURCE_PUBLIC_KEY_PATH = \'key_file_name\'\n  | GET_SOURCE_PUBLIC_KEY = {0|1}\n  | NETWORK_NAMESPACE = \'namespace\'\n  | IGNORE_SERVER_IDS = (server_id_list),\n  | GTID_ONLY = {0|1}\n}\n\nchannel_option:\n    FOR CHANNEL channel\n\nserver_id_list:\n    [server_id [, server_id] ... ]\n\nCHANGE REPLICATION SOURCE TO changes the parameters that the replica\nserver uses for connecting to the source and reading data from the\nsource. It also updates the contents of the replication metadata\nrepositories (see\nhttps://dev.mysql.com/doc/refman/8.0/en/replica-logs.html). In MySQL\n8.0.23 and later, use CHANGE REPLICATION SOURCE TO in place of the\ndeprecated CHANGE MASTER TO statement.\n\nCHANGE REPLICATION SOURCE TO requires the REPLICATION_SLAVE_ADMIN\nprivilege (or the deprecated SUPER privilege).\n\nOptions that you do not specify on a CHANGE REPLICATION SOURCE TO\nstatement retain their value, except as indicated in the following\ndiscussion. In most cases, there is therefore no need to specify\noptions that do not change.\n\nValues used for SOURCE_HOST and other CHANGE REPLICATION SOURCE TO\noptions are checked for linefeed (\\n or 0x0A) characters. The presence\nof such characters in these values causes the statement to fail with an\nerror.\n\nThe optional FOR CHANNEL channel clause lets you name which replication\nchannel the statement applies to. Providing a FOR CHANNEL channel\nclause applies the CHANGE REPLICATION SOURCE TO statement to a specific\nreplication channel, and is used to add a new channel or modify an\nexisting channel. For example, to add a new channel called channel2:\n\nCHANGE REPLICATION SOURCE TO SOURCE_HOST=host1, SOURCE_PORT=3002 FOR CHANNEL \'channel2\';\n\nIf no clause is named and no extra channels exist, a CHANGE REPLICATION\nSOURCE TO statement applies to the default channel, whose name is the\nempty string (\"\"). When you have set up multiple replication channels,\nevery CHANGE REPLICATION SOURCE TO statement must name a channel using\nthe FOR CHANNEL channel clause. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nFor some of the options of the CHANGE REPLICATION SOURCE TO statement,\nyou must issue a STOP REPLICA statement prior to issuing a CHANGE\nREPLICATION SOURCE TO statement (and a START REPLICA statement\nafterwards). Sometimes, you only need to stop the replication SQL\n(applier) thread or the replication I/O (receiver) thread, not both:\n\no When the applier thread is stopped, you can execute CHANGE\n  REPLICATION SOURCE TO using any combination that is otherwise allowed\n  of RELAY_LOG_FILE, RELAY_LOG_POS, and SOURCE_DELAY options, even if\n  the replication receiver thread is running. No other options may be\n  used with this statement when the receiver thread is running.\n\no When the receiver thread is stopped, you can execute CHANGE\n  REPLICATION SOURCE TO using any of the options for this statement (in\n  any allowed combination) except RELAY_LOG_FILE, RELAY_LOG_POS,\n  SOURCE_DELAY, or SOURCE_AUTO_POSITION = 1 even when the applier\n  thread is running.\n\no Both the receiver thread and the applier thread must be stopped\n  before issuing a CHANGE REPLICATION SOURCE TO statement that employs\n  SOURCE_AUTO_POSITION = 1, GTID_ONLY = 1, or\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS.\n\nYou can check the current state of the replication applier thread and\nreplication receiver thread using SHOW REPLICA STATUS. Note that the\nGroup Replication applier channel (group_replication_applier) has no\nreceiver thread, only an applier thread.\n\nCHANGE REPLICATION SOURCE TO statements have a number of side-effects\nand interactions that you should be aware of beforehand:\n\no CHANGE REPLICATION SOURCE TO causes an implicit commit of an ongoing\n  transaction. See\n  https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\no CHANGE REPLICATION SOURCE TO causes the previous values for\n  SOURCE_HOST, SOURCE_PORT, SOURCE_LOG_FILE, and SOURCE_LOG_POS to be\n  written to the error log, along with other information about the\n  replica\'s state prior to execution.\n\no If you are using statement-based replication and temporary tables, it\n  is possible for a CHANGE REPLICATION SOURCE TO statement following a\n  STOP REPLICA statement to leave behind temporary tables on the\n  replica. A warning (ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_warn_open_temp_tables_must_be_zero)) is issued\n  whenever this occurs. You can avoid this in such cases by making sure\n  that the value of the Replica_open_temp_tables or\n  Slave_open_temp_tables system status variable is equal to 0 prior to\n  executing such a CHANGE REPLICATION SOURCE TO statement.\n\no When using a multithreaded replica (replica_parallel_workers > 0),\n  stopping the replica can cause gaps in the sequence of transactions\n  that have been executed from the relay log, regardless of whether the\n  replica was stopped intentionally or otherwise. When such gaps exist,\n  issuing CHANGE REPLICATION SOURCE TO fails. The solution in this\n  situation is to issue START REPLICA UNTIL SQL_AFTER_MTS_GAPS which\n  ensures that the gaps are closed. From MySQL 8.0.26, the process of\n  checking for gaps in the sequence of transactions is skipped entirely\n  when GTID-based replication and GTID auto-positioning are in use,\n  because gaps in transactions can be resolved using GTID\n  auto-positioning. In that situation, CHANGE REPLICATION SOURCE TO can\n  still be used.\n\nThe following options are available for CHANGE REPLICATION SOURCE TO\nstatements:\n\no ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | uuid}\n\n  Makes the replication channel assign a GTID to replicated\n  transactions that do not have one, enabling replication from a source\n  that does not use GTID-based replication, to a replica that does. For\n  a multi-source replica, you can have a mix of channels that use\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS, and channels that do not. The\n  default is OFF, meaning that the feature is not used.\n\n  LOCAL assigns a GTID including the replica\'s own UUID (the\n  server_uuid setting). uuid assigns a GTID including the specified\n  UUID, such as the server_uuid setting for the replication source\n  server. Using a nonlocal UUID lets you differentiate between\n  transactions that originated on the replica and transactions that\n  originated on the source, and for a multi-source replica, between\n  transactions that originated on different sources. The UUID you\n  choose only has significance for the replica\'s own use. If any of the\n  transactions sent by the source do have a GTID already, that GTID is\n  retained.\n\n  Channels specific to Group Replication cannot use\n  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS, but an asynchronous\n  replication channel for another source on a server instance that is a\n  Group Replication group member can do so. In that case, do not\n  specify the Group Replication group name as the UUID for creating the\n  GTIDs.\n\n  To set ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS to LOCAL or uuid, the\n  replica must have gtid_mode=ON set, and this cannot be changed\n  afterwards. This option is for use with a source that has binary log\n  file position based replication, so SOURCE_AUTO_POSITION=1 cannot be\n  set for the channel. Both the replication SQL thread and the\n  replication I/O (receiver) thread must be stopped before setting this\n  option.\n\n  *Important*:\n\n  A replica set up with ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS on any\n  channel cannot be promoted to replace the replication source server\n  in the event that a failover is required, and a backup taken from the\n  replica cannot be used to restore the replication source server. The\n  same restriction applies to replacing or restoring other replicas\n  that use ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS on any channel.\n\n  For further restrictions and information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon\n  .html.\n\no GET_SOURCE_PUBLIC_KEY = {0|1}\n\n  Enables RSA key pair-based password exchange by requesting the public\n  key from the source. The option is disabled by default.\n\n  This option applies to replicas that authenticate with the\n  caching_sha2_password authentication plugin. For connections by\n  accounts that authenticate using this plugin, the source does not\n  send the public key unless requested, so it must be requested or\n  specified in the client. If SOURCE_PUBLIC_KEY_PATH is given and\n  specifies a valid public key file, it takes precedence over\n  GET_SOURCE_PUBLIC_KEY. If you are using a replication user account\n  that authenticates with the caching_sha2_password plugin (which is\n  the default from MySQL 8.0), and you are not using a secure\n  connection, you must specify either this option or the\n  SOURCE_PUBLIC_KEY_PATH option to provide the RSA public key to the\n  replica.\n\no GTID_ONLY = {0|1}\n\n  Stops the replication channel persisting file names and file\n  positions in the replication metadata repositories. GTID_ONLY is\n  available as of MySQL 8.0.27. The GTID_ONLY option is disabled by\n  default for asynchronous replication channels, but it is enabled by\n  default for Group Replication channels, and it cannot be disabled for\n  them.\n\n  For replication channels with this setting, in-memory file positions\n  are still tracked, and file positions can still be observed for\n  debugging purposes in error messages and through interfaces such as\n  SHOW REPLICA STATUS statements (where they are shown as being invalid\n  if they are out of date). However, the writes and reads required to\n  persist and check the file positions are avoided in situations where\n  GTID-based replication does not actually require them, including the\n  transaction queuing and application process.\n\n  This option can be used only if both the replication SQL (applier)\n  thread and replication I/O (receiver) thread are stopped. To set\n  GTID_ONLY = 1 for a replication channel, GTIDs must be in use on the\n  server (gtid_mode = ON), and row-based binary logging must be in use\n  on the source (statement-based replication is not supported). The\n  options REQUIRE_ROW_FORMAT = 1 and SOURCE_AUTO_POSITION = 1 must be\n  set for the replication channel.\n\n  When GTID_ONLY = 1 is set, the replica uses\n  replica_parallel_workers=1 if that system variable is set to zero for\n  the server, so it is always technically a multi-threaded applier.\n  This is because a multi-threaded applier uses saved positions rather\n  than the replication metadata repositories to locate the start of a\n  transaction that it needs to reapply.\n\n  If you disable GTID_ONLY after setting it, the existing relay logs\n  are deleted and the existing known binary log file positions are\n  persisted, even if they are stale. The file positions for the binary\n  log and relay log in the replication metadata repositories might be\n  invalid, and a warning is returned if this is the case. Provided that\n  SOURCE_AUTO_POSITION is still enabled, GTID auto-positioning is used\n  to provide the correct positioning.\n\n  If you also disable SOURCE_AUTO_POSITION, the file positions for the\n  binary log and relay log in the replication metadata repositories are\n  used for positioning if they are valid. If they are marked as\n  invalid, you must provide a valid binary log file name and position\n  (SOURCE_LOG_FILE and SOURCE_LOG_POS). If you also provide a relay log\n  file name and position (RELAY_LOG_FILE and RELAY_LOG_POS), the relay\n  logs are preserved and the applier position is set to the stated\n  position. GTID auto-skip ensures that any transactions already\n  applied are skipped even if the eventual applier position is not\n  correct.\n\no IGNORE_SERVER_IDS = (server_id_list)\n\n  Makes the replica ignore events originating from the specified\n  servers. The option takes a comma-separated list of 0 or more server\n  IDs. Log rotation and deletion events from the servers are not\n  ignored, and are recorded in the relay log.\n\n  In circular replication, the originating server normally acts as the\n  terminator of its own events, so that they are not applied more than\n  once. Thus, this option is useful in circular replication when one of\n  the servers in the circle is removed. Suppose that you have a\n  circular replication setup with 4 servers, having server IDs 1, 2, 3,\n  and 4, and server 3 fails. When bridging the gap by starting\n  replication from server 2 to server 4, you can include\n  IGNORE_SERVER_IDS = (3) in the CHANGE REPLICATION SOURCE TO statement\n  that you issue on server 4 to tell it to use server 2 as its source\n  instead of server 3. Doing so causes it to ignore and not to\n  propagate any statements that originated with the server that is no\n  longer in use.\n\n  If IGNORE_SERVER_IDS contains the server\'s own ID and the server was\n  started with the --replicate-same-server-id option enabled, an error\n  results.\n\n  *Note*:\n\n  When global transaction identifiers (GTIDs) are used for replication,\n  transactions that have already been applied are automatically\n  ignored, so the IGNORE_SERVER_IDS function is not required and is\n  deprecated. If gtid_mode=ON is set for the server, a deprecation\n  warning is issued if you include the IGNORE_SERVER_IDS option in a\n  CHANGE REPLICATION SOURCE TO statement.\n\n  The source metadata repository and the output of SHOW REPLICA STATUS\n  provide the list of servers that are currently ignored. For more\n  information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replica-logs-status.html, and\n  [HELP SHOW REPLICA STATUS].\n\n  If a CHANGE REPLICATION SOURCE TO statement is issued without any\n  IGNORE_SERVER_IDS option, any existing list is preserved. To clear\n  the list of ignored servers, it is necessary to use the option with\n  an empty list:\n\nCHANGE REPLICATION SOURCE TO IGNORE_SERVER_IDS = ();\n\n  RESET REPLICA ALL clears IGNORE_SERVER_IDS.\n\n  *Note*:\n\n  A deprecation warning is issued if SET GTID_MODE=ON is issued when\n  any channel has existing server IDs set with IGNORE_SERVER_IDS.\n  Before starting GTID-based replication, check for and clear all\n  ignored server ID lists on the servers involved. The SHOW REPLICA\n  STATUS statement displays the list of ignored IDs, if there is one.\n  If you do receive the deprecation warning, you can still clear a list\n  after gtid_mode=ON is set by issuing a CHANGE REPLICATION SOURCE TO\n  statement containing the IGNORE_SERVER_IDS option with an empty list.\n\no NETWORK_NAMESPACE = \'namespace\'\n\n  The network namespace to use for TCP/IP connections to the\n  replication source server or, if the MySQL communication stack is in\n  use, for Group Replication\'s group communication connections. The\n  maximum length of the string value is 64 characters. If this option\n  is omitted, connections from the replica use the default (global)\n  namespace. On platforms that do not implement network namespace\n  support, failure occurs when the replica attempts to connect to the\n  source. For information about network namespaces, see\n  https://dev.mysql.com/doc/refman/8.0/en/network-namespace-support.htm\n  l. NETWORK_NAMESPACE is available as of MySQL 8.0.22.\n\no PRIVILEGE_CHECKS_USER = {NULL | \'account\'}\n\n  Names a user account that supplies a security context for the\n  specified channel. NULL, which is the default, means no security\n  context is used. PRIVILEGE_CHECKS_USER is available as of MySQL\n  8.0.18.\n\n  The user name and host name for the user account must follow the\n  syntax described in\n  https://dev.mysql.com/doc/refman/8.0/en/account-names.html, and the\n  user must not be an anonymous user (with a blank user name) or the\n  CURRENT_USER. The account must have the REPLICATION_APPLIER\n  privilege, plus the required privileges to execute the transactions\n  replicated on the channel. For details of the privileges required by\n  the account, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html. When you restart the replication channel, the privilege checks\n  are applied from that point on. If you do not specify a channel and\n  no other channels exist, the statement is applied to the default\n  channel.\n\n  The use of row-based binary logging is strongly recommended when\n  PRIVILEGE_CHECKS_USER is set, and you can set REQUIRE_ROW_FORMAT to\n  enforce this. For example, to start privilege checks on the channel\n  channel_1 on a running replica, issue the following statements:\n\nSTOP REPLICA FOR CHANNEL \'channel_1\';\n\nCHANGE REPLICATION SOURCE TO\n    PRIVILEGE_CHECKS_USER = \'user\'@\'host\',\n    REQUIRE_ROW_FORMAT = 1,\n    FOR CHANNEL \'channel_1\';\n\nSTART REPLICA FOR CHANNEL \'channel_1\';\n\no RELAY_LOG_FILE = \'relay_log_file\' , RELAY_LOG_POS = \'relay_log_pos\'\n\n  The relay log file name, and the location in that file, at which the\n  replication SQL thread begins reading from the replica\'s relay log\n  the next time the thread starts. RELAY_LOG_FILE can use either an\n  absolute or relative path, and uses the same base name as\n  SOURCE_LOG_FILE. The maximum length of the string value is 511\n  characters.\n\n  A CHANGE REPLICATION SOURCE TO statement using RELAY_LOG_FILE,\n  RELAY_LOG_POS, or both options can be executed on a running replica\n  when the replication SQL (applier) thread is stopped. Relay logs are\n  preserved if at least one of the replication applier thread and the\n  replication I/O (receiver) thread is running. If both threads are\n  stopped, all relay log files are deleted unless at least one of\n  RELAY_LOG_FILE or RELAY_LOG_POS is specified. For the Group\n  Replication applier channel (group_replication_applier), which only\n  has an applier thread and no receiver thread, this is the case if the\n  applier thread is stopped, but with that channel you cannot use the\n  RELAY_LOG_FILE and RELAY_LOG_POS options.\n\no REQUIRE_ROW_FORMAT = {0|1}\n\n  Permits only row-based replication events to be processed by the\n  replication channel. This option prevents the replication applier\n  from taking actions such as creating temporary tables and executing\n  LOAD DATA INFILE requests, which increases the security of the\n  channel. The REQUIRE_ROW_FORMAT option is disabled by default for\n  asynchronous replication channels, but it is enabled by default for\n  Group Replication channels, and it cannot be disabled for them. For\n  more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html. REQUIRE_ROW_FORMAT is available as of MySQL 8.0.19.\n\no REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF | GENERATE}\n\n  Available as of MySQL 8.0.20, this option lets a replica set its own\n  policy for primary key checks, as follows:\n\n  o ON: The replica sets sql_require_primary_key = ON; all tables on\n    the replica, including all replicated tables, require a primary\n    key.\n\n  o OFF: The replica sets sql_require_primary_key = OFF; a primary key\n    is never required on the replica, including replicated tables, even\n    if one is required on the source.\n\n  o STREAM: The replica uses whatever value of sql_require_primary_key\n    is replicated from the source for each transaction. This is the\n    default value, and the default behavior.\n\n  o GENERATE: Added in MySQL 8.0.32, this causes the replica to\n    generate an invisible primary key for any InnoDB table that, as\n    replicated, lacks a primary key. See\n    https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html,\n    for more information.\n\n    GENERATE is not compatible with Group Replication; you can use ON,\n    OFF, or STREAM.\n\n  A divergence based on the presence of a generated invisible primary\n  key solely on a source or replica table is supported by MySQL\n  Replication as long as the source supports GIPKs (MySQL 8.0.30 and\n  later) and the replica uses MySQL version 8.0.32 or later. If you use\n  GIPKs on a replica and replicate from a source using a MySQL 8.0.29\n  or earlier, you should be aware that in this case such divergences in\n  schema are not supported and may result in replication errors.\n\n  For multisource replication, setting REQUIRE_TABLE_PRIMARY_KEY_CHECK\n  to ON or OFF lets the replica normalize behavior across replication\n  channels for different sources, and to keep a consistent setting for\n  sql_require_primary_key. Using ON safeguards against the accidental\n  loss of primary keys when multiple sources update the same set of\n  tables. Using OFF lets sources that can manipulate primary keys to\n  work alongside sources that cannot.\n\n  In the case of multiple replicas, when\n  REQUIRE_TABLE_PRIMARY_KEY_CHECK is set to GENERATE, the generated\n  invisible primary key added by a given replica is independent of any\n  such key added on any other replica. This means that, if generated\n  invisible primary keys are in use, the values in the generated\n  primary key columns on different replicas are not guaranteed to be\n  the same. This may be an issue when failing over to such a replica.\n\n  When PRIVILEGE_CHECKS_USER is NULL (the default), the user account\n  needs administration-level privileges to set restricted session\n  variables. Setting this option to a value other than NULL means that,\n  when REQUIRE_TABLE_PRIMARY_KEY_CHECK is ON or OFF, the user account\n  does not need session administration level privileges to set\n  restricted session variables, which are required to change the value\n  of sql_require_primary_key to match the setting on the source for\n  each transaction. (Such privileges are required when\n  PRIVILEGE_CHECKS_USER is STREAM.) For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-privilege-checks.\n  html.\n\no SOURCE_AUTO_POSITION = {0|1}\n\n  Makes the replica attempt to connect to the source using the\n  auto-positioning feature of GTID-based replication, rather than a\n  binary log file based position. This option is used to start a\n  replica using GTID-based replication. The default is 0, meaning that\n  GTID auto-positioning and GTID-based replication are not used. This\n  option can be used with CHANGE REPLICATION SOURCE TO only if both the\n  replication SQL (applier) thread and replication I/O (receiver)\n  thread are stopped.\n\n  Both the replica and the source must have GTIDs enabled\n  (GTID_MODE=ON, ON_PERMISSIVE, or OFF_PERMISSIVE on the replica, and\n  GTID_MODE=ON on the source). SOURCE_LOG_FILE, SOURCE_LOG_POS,\n  RELAY_LOG_FILE, and RELAY_LOG_POS cannot be specified together with\n  SOURCE_AUTO_POSITION = 1. If multi-source replication is enabled on\n  the replica, you need to set the SOURCE_AUTO_POSITION = 1 option for\n  each applicable replication channel.\n\n  With SOURCE_AUTO_POSITION = 1 set, in the initial connection\n  handshake, the replica sends a GTID set containing the transactions\n  that it has already received, committed, or both. The source responds\n  by sending all transactions recorded in its binary log whose GTID is\n  not included in the GTID set sent by the replica. This exchange\n  ensures that the source only sends the transactions with a GTID that\n  the replica has not already recorded or committed. If the replica\n  receives transactions from more than one source, as in the case of a\n  diamond topology, the auto-skip function ensures that the\n  transactions are not applied twice. For details of how the GTID set\n  sent by the replica is computed, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positi\n  oning.html.\n\n  If any of the transactions that should be sent by the source have\n  been purged from the source\'s binary log, or added to the set of\n  GTIDs in the gtid_purged system variable by another method, the\n  source sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_master_has_purged_required_gtids) to the replica, and\n  replication does not start. The GTIDs of the missing purged\n  transactions are identified and listed in the source\'s error log in\n  the warning message ER_FOUND_MISSING_GTIDS\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_found_missing_gtids). Also, if during the exchange of\n  transactions it is found that the replica has recorded or committed\n  transactions with the source\'s UUID in the GTID, but the source\n  itself has not committed them, the source sends the error\n  ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html#error_er_slave_has_more_gtids_than_master) to the replica and\n  replication does not start. For information on how to handle these\n  situations, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positi\n  oning.html.\n\n  You can see whether replication is running with GTID auto-positioning\n  enabled by checking the Performance Schema\n  replication_connection_status table or the output of SHOW REPLICA\n  STATUS. Disabling the SOURCE_AUTO_POSITION option again makes the\n  replica revert to file-based replication.\n\no SOURCE_BIND = \'interface_name\'\n\n  Determines which of the replica\'s network interfaces is chosen for\n  connecting to the source, for use on replicas that have multiple\n  network interfaces. Specify the IP address of the network interface.\n  The maximum length of the string value is 255 characters.\n\n  The IP address configured with this option, if any, can be seen in\n  the Source_Bind column of the output from SHOW REPLICA STATUS. In the\n  source metadata repository table mysql.slave_master_info, the value\n  can be seen as the Source_bind column. The ability to bind a replica\n  to a specific network interface is also supported by NDB Cluster.\n\no SOURCE_COMPRESSION_ALGORITHMS = \'algorithm[,algorithm][,algorithm]\'\n\n  Specifies one, two, or three of the permitted compression algorithms\n  for connections to the replication source server, separated by\n  commas. The maximum length of the string value is 99 characters. The\n  default value is uncompressed.\n\n  The available algorithms are zlib, zstd, and uncompressed, the same\n  as for the protocol_compression_algorithms system variable. The\n  algorithms can be specified in any order, but it is not an order of\n  preference - the algorithm negotiation process attempts to use zlib,\n  then zstd, then uncompressed, if they are specified.\n  SOURCE_COMPRESSION_ALGORITHMS is available as of MySQL 8.0.18.\n\n  The value of SOURCE_COMPRESSION_ALGORITHMS applies only if the\n  replica_compressed_protocol or slave_compressed_protocol system\n  variable is disabled. If replica_compressed_protocol or\n  slave_compressed_protocol is enabled, it takes precedence over\n  SOURCE_COMPRESSION_ALGORITHMS and connections to the source use zlib\n  compression if both source and replica support that algorithm. For\n  more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/connection-compression-contro\n  l.html.\n\n  Binary log transaction compression (available as of MySQL 8.0.20),\n  which is activated by the binlog_transaction_compression system\n  variable, can also be used to save bandwidth. If you do this in\n  combination with connection compression, connection compression has\n  less opportunity to act on the data, but can still compress headers\n  and those events and transaction payloads that are uncompressed. For\n  more information on binary log transaction compression, see\n  https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compre\n  ssion.html.\n\no SOURCE_CONNECT_RETRY = interval\n\n  Specifies the interval in seconds between the reconnection attempts\n  that the replica makes after the connection to the source times out.\n  The default interval is 60.\n\n  The number of attempts is limited by the SOURCE_RETRY_COUNT option.\n  If both the default settings are used, the replica waits 60 seconds\n  between reconnection attempts (SOURCE_CONNECT_RETRY=60), and keeps\n  attempting to reconnect at this rate for 60 days\n  (SOURCE_RETRY_COUNT=86400). These values are recorded in the source\n  metadata repository and shown in the\n  replication_connection_configuration Performance Schema table.\n\no SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}\n\n  Activates the asynchronous connection failover mechanism for a\n  replication channel if one or more alternative replication source\n  servers are available (so when there are multiple MySQL servers or\n  groups of servers that share the replicated data).\n  SOURCE_CONNECTION_AUTO_FAILOVER is available as of MySQL 8.0.22. The\n  default is 0, meaning that the mechanism is not activated. For full\n  information and instructions to set up this feature, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-conn\n  ection-failover-replica.html.\n\n  The asynchronous connection failover mechanism takes over after the\n  reconnection attempts controlled by SOURCE_CONNECT_RETRY and\n  SOURCE_RETRY_COUNT are exhausted. It reconnects the replica to an\n  alternative source chosen from a specified source list, which you\n  manage using the asynchronous_connection_failover_add_source and\n  asynchronous_connection_failover_delete_source functions. To add and\n  remove managed groups of servers, use the\n  asynchronous_connection_failover_add_managed and\n  asynchronous_connection_failover_delete_managed functions instead.\n  For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-conn\n  ection-failover.html.\n\n  *Important*:\n\n   1. You can only set SOURCE_CONNECTION_AUTO_FAILOVER = 1 when GTID\n      auto-positioning is in use (SOURCE_AUTO_POSITION = 1).\n\n   2. When you set SOURCE_CONNECTION_AUTO_FAILOVER = 1, set\n      SOURCE_RETRY_COUNT and SOURCE_CONNECT_RETRY to minimal numbers\n      that just allow a few retry attempts with the same source, in\n      case the connection failure is caused by a transient network\n      outage. Otherwise the asynchronous connection failover mechanism\n      cannot be activated promptly. Suitable values are\n      SOURCE_RETRY_COUNT=3 and SOURCE_CONNECT_RETRY=10, which make the\n      replica retry the connection 3 times with 10-second intervals\n      between.\n\n   3. When you set SOURCE_CONNECTION_AUTO_FAILOVER = 1, the replication\n      metadata repositories must contain the credentials for a\n      replication user account that can be used to connect to all the\n      servers on the source list for the replication channel. The\n      account must also have SELECT permissions on the Performance\n      Schema tables. These credentials can be set using the CHANGE\n      REPLICATION SOURCE TO statement with the SOURCE_USER and\n      SOURCE_PASSWORD options. For more information, see\n      https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-\n      connection-failover.html.\n\n   4. From MySQL 8.0.27, when you set SOURCE_CONNECTION_AUTO_FAILOVER =\n      1, asynchronous connection failover for replicas is automatically\n      activated if this replication channel is on a Group Replication\n      primary in a group in single-primary mode. With this function\n      active, if the primary that is replicating goes offline or into\n      an error state, the new primary starts replication on the same\n      channel when it is elected. If you want to use the function, this\n      replication channel must also be set up on all the secondary\n      servers in the replication group, and on any new joining members.\n      (If the servers are provisioned using MySQL\'s clone\n      functionality, this all happens automatically.) If you do not\n      want to use the function, disable it by using the\n      group_replication_disable_member_action function to disable the\n      Group Replication member action\n      mysql_start_failover_channels_if_primary, which is enabled by\n      default. For more information, see\n      https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-\n      connection-failover-replica.html.\n\no SOURCE_DELAY = interval\n\n  Specifies how many seconds behind the source the replica must lag. An\n  event received from the source is not executed until at least\n  interval seconds later than its execution on the source. interval\n  must be a nonnegative integer in the range from 0 to 231−1. The\n  default is 0. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-delayed.html.\n\n  A CHANGE REPLICATION SOURCE TO statement using the SOURCE_DELAY\n  option can be executed on a running replica when the replication SQL\n  thread is stopped.\n\no SOURCE_HEARTBEAT_PERIOD = interval\n\n  Controls the heartbeat interval, which stops the connection timeout\n  occurring in the absence of data if the connection is still good. A\n  heartbeat signal is sent to the replica after that number of seconds,\n  and the waiting period is reset whenever the source\'s binary log is\n  updated with an event. Heartbeats are therefore sent by the source\n  only if there are no unsent events in the binary log file for a\n  period longer than this.\n\n  The heartbeat interval interval is a decimal value having the range 0\n  to 4294967 seconds and a resolution in milliseconds; the smallest\n  nonzero value is 0.001. Setting interval to 0 disables heartbeats\n  altogether. The heartbeat interval defaults to half the value of the\n  replica_net_timeout or slave_net_timeout system variable. It is\n  recorded in the source metadata repository and shown in the\n  replication_connection_configuration Performance Schema table.\n  Issuing RESET REPLICA resets the heartbeat interval to the default\n  value.\n\n  The system variable replica_net_timeout (from MySQL 8.0.26) or\n  slave_net_timeout (before MySQL 8.0.26) specifies the number of\n  seconds that the replica waits for either more data or a heartbeat\n  signal from the source, before the replica considers the connection\n  broken, aborts the read, and tries to reconnect. The default value is\n  60 seconds (one minute). Note that a change to the value or default\n  setting of replica_net_timeout or slave_net_timeout does not\n  automatically change the heartbeat interval, whether that has been\n  set explicitly or is using a previously calculated default. A warning\n  is issued if you set the global value of replica_net_timeout or\n  slave_net_timeout to a value less than that of the current heartbeat\n  interval. If replica_net_timeout or slave_net_timeout is changed, you\n  must also issue CHANGE REPLICATION SOURCE TO to adjust the heartbeat\n  interval to an appropriate value so that the heartbeat signal occurs\n  before the connection timeout. If you do not do this, the heartbeat\n  signal has no effect, and if no data is received from the source, the\n  replica can make repeated reconnection attempts, creating zombie dump\n  threads.\n\no SOURCE_HOST = \'host_name\'\n\n  The host name or IP address of the replication source server. The\n  replica uses this to connect to the source. The maximum length of the\n  string value is 255 characters.\n\n  If you specify SOURCE_HOST or SOURCE_PORT, the replica assumes that\n  the source server is different from before (even if the option value\n  is the same as its current value.) In this case, the old values for\n  the source\'s binary log file name and position are considered no\n  longer applicable, so if you do not specify SOURCE_LOG_FILE and\n  SOURCE_LOG_POS in the statement, SOURCE_LOG_FILE=\'\' and\n  SOURCE_LOG_POS=4 are silently appended to it.\n\n  Setting SOURCE_HOST=\'\' (that is, setting its value explicitly to an\n  empty string) is not the same as not setting SOURCE_HOST at all.\n  Trying to set SOURCE_HOST to an empty string fails with an error.\n\no SOURCE_LOG_FILE = \'source_log_name\', SOURCE_LOG_POS = source_log_pos\n\n  The binary log file name, and the location in that file, at which the\n  replication I/O (receiver) thread begins reading from the source\'s\n  binary log the next time the thread starts. Specify these options if\n  you are using binary log file position based replication.\n\n  SOURCE_LOG_FILE must include the numeric suffix of a specific binary\n  log file that is available on the source server, for example,\n  SOURCE_LOG_FILE=\'binlog.000145\'. The maximum length of the string\n  value is 511 characters.\n\n  SOURCE_LOG_POS is the numeric position for the replica to start\n  reading in that file. SOURCE_LOG_POS=4 represents the start of the\n  events in a binary log file.\n\n  If you specify either of SOURCE_LOG_FILE or SOURCE_LOG_POS, you\n  cannot specify SOURCE_AUTO_POSITION = 1, which is for GTID-based\n  replication.\n\n  If neither of SOURCE_LOG_FILE or SOURCE_LOG_POS is specified, the\n  replica uses the last coordinates of the replication SQL thread\n  before CHANGE REPLICATION SOURCE TO was issued. This ensures that\n  there is no discontinuity in replication, even if the replication SQL\n  (applier) thread was late compared to the replication I/O (receiver)\n  thread.\n\no SOURCE_PASSWORD = \'password\'\n\n  The password for the replication user account to use for connecting\n  to the replication source server. The maximum length of the string\n  value is 32 characters. If you specify SOURCE_PASSWORD, SOURCE_USER\n  is also required.\n\n  The password used for a replication user account in a CHANGE\n  REPLICATION SOURCE TO statement is limited to 32 characters in\n  length. Trying to use a password of more than 32 characters causes\n  CHANGE REPLICATION SOURCE TO to fail.\n\n  The password is masked in MySQL Server\'s logs, Performance Schema\n  tables, and SHOW PROCESSLIST statements.\n\no SOURCE_PORT = port_num\n\n  The TCP/IP port number that the replica uses to connect to the\n  replication source server.\n\n  *Note*:\n\n  Replication cannot use Unix socket files. You must be able to connect\n  to the replication source server using TCP/IP.\n\n  If you specify SOURCE_HOST or SOURCE_PORT, the replica assumes that\n  the source server is different from before (even if the option value\n  is the same as its current value.) In this case, the old values for\n  the source\'s binary log file name and position are considered no\n  longer applicable, so if you do not specify SOURCE_LOG_FILE and\n  SOURCE_LOG_POS in the statement, SOURCE_LOG_FILE=\'\' and\n  SOURCE_LOG_POS=4 are silently appended to it.\n\no SOURCE_PUBLIC_KEY_PATH = \'key_file_name\'\n\n  Enables RSA key pair-based password exchange by providing the path\n  name to a file containing a replica-side copy of the public key\n  required by the source. The file must be in PEM format. The maximum\n  length of the string value is 511 characters.\n\n  This option applies to replicas that authenticate with the\n  sha256_password or caching_sha2_password authentication plugin. (For\n  sha256_password, SOURCE_PUBLIC_KEY_PATH can be used only if MySQL was\n  built using OpenSSL.) If you are using a replication user account\n  that authenticates with the caching_sha2_password plugin (which is\n  the default from MySQL 8.0), and you are not using a secure\n  connection, you must specify either this option or the\n  GET_SOURCE_PUBLIC_KEY=1 option to provide the RSA public key to the\n  replica.\n\no SOURCE_RETRY_COUNT = count\n\n  Sets the maximum number of reconnection attempts that the replica\n  makes after the connection to the source times out, as determined by\n  the replica_net_timeout or slave_net_timeout system variable. If the\n  replica does need to reconnect, the first retry occurs immediately\n  after the timeout. The default is 86400 attempts.\n\n  The interval between the attempts is specified by the\n  SOURCE_CONNECT_RETRY option. If both the default settings are used,\n  the replica waits 60 seconds between reconnection attempts\n  (SOURCE_CONNECT_RETRY=60), and keeps attempting to reconnect at this\n  rate for 60 days (SOURCE_RETRY_COUNT=86400). A setting of 0 for\n  SOURCE_RETRY_COUNT means that there is no limit on the number of\n  reconnection attempts, so the replica keeps trying to reconnect\n  indefinitely.\n\n  The values for SOURCE_CONNECT_RETRY and SOURCE_RETRY_COUNT are\n  recorded in the source metadata repository and shown in the\n  replication_connection_configuration Performance Schema table.\n  SOURCE_RETRY_COUNT supersedes the --master-retry-count server startup\n  option.\n\no SOURCE_SSL = {0|1}\n\n  Specify whether the replica encrypts the replication connection. The\n  default is 0, meaning that the replica does not encrypt the\n  replication connection. If you set SOURCE_SSL=1, you can configure\n  the encryption using the SOURCE_SSL_xxx and SOURCE_TLS_xxx options.\n\n  Setting SOURCE_SSL=1 for a replication connection and then setting no\n  further SOURCE_SSL_xxx options corresponds to setting\n  --ssl-mode=REQUIRED for the client, as described in\n  https://dev.mysql.com/doc/refman/8.0/en/connection-options.html#encry\n  pted-connection-options. With SOURCE_SSL=1, the connection attempt\n  only succeeds if an encrypted connection can be established. A\n  replication connection does not fall back to an unencrypted\n  connection, so there is no setting corresponding to the\n  --ssl-mode=PREFERRED setting for replication. If SOURCE_SSL=0 is set,\n  this corresponds to --ssl-mode=DISABLED.\n\n  *Important*:\n\n  To help prevent sophisticated man-in-the-middle attacks, it is\n  important for the replica to verify the server\'s identity. You can\n  specify additional SOURCE_SSL_xxx options to correspond to the\n  settings --ssl-mode=VERIFY_CA and --ssl-mode=VERIFY_IDENTITY, which\n  are a better choice than the default setting to help prevent this\n  type of attack. With these settings, the replica checks that the\n  server\'s certificate is valid, and checks that the host name the\n  replica is using matches the identity in the server\'s certificate. To\n  implement one of these levels of verification, you must first ensure\n  that the CA certificate for the server is reliably available to the\n  replica, otherwise availability issues will result. For this reason,\n  they are not the default setting.\n\no SOURCE_SSL_xxx, SOURCE_TLS_xxx\n\n  Specify how the replica uses encryption and ciphers to secure the\n  replication connection. These options can be changed even on replicas\n  that are compiled without SSL support. They are saved to the source\n  metadata repository, but are ignored if the replica does not have SSL\n  support enabled. The maximum length of the value for the\n  string-valued SOURCE_SSL_xxx and SOURCE_TLS_xxx options is 511\n  characters, with the exception of SOURCE_TLS_CIPHERSUITES, for which\n  it is 4000 characters.\n\n  The SOURCE_SSL_xxx and SOURCE_TLS_xxx options perform the same\n  functions as the --ssl-xxx and --tls-xxx client options described in\n  https://dev.mysql.com/doc/refman/8.0/en/connection-options.html#encry\n  pted-connection-options. The correspondence between the two sets of\n  options, and the use of the SOURCE_SSL_xxx and SOURCE_TLS_xxx options\n  to set up a secure connection, is explained in\n  https://dev.mysql.com/doc/refman/8.0/en/replication-encrypted-connect\n  ions.html.\n\no SOURCE_USER = \'user_name\'\n\n  The user name for the replication user account to use for connecting\n  to the replication source server. The maximum length of the string\n  value is 96 characters.\n\n  For Group Replication, this account must exist on every member of the\n  replication group. It is used for distributed recovery if the XCom\n  communication stack is in use for the group, and also used for group\n  communication connections if the MySQL communication stack is in use\n  for the group. With the MySQL communication stack, the account must\n  have the GROUP_REPLICATION_STREAM permission.\n\n  It is possible to set an empty user name by specifying\n  SOURCE_USER=\'\', but the replication channel cannot be started with an\n  empty user name. In releases before MySQL 8.0.21, only set an empty\n  SOURCE_USER user name if you need to clear previously used\n  credentials from the replication metadata repositories for security\n  purposes. Do not use the channel afterwards, due to a bug in these\n  releases that can substitute a default user name if an empty user\n  name is read from the repositories (for example, during an automatic\n  restart of a Group Replication channel). From MySQL 8.0.21, it is\n  valid to set an empty SOURCE_USER user name and use the channel\n  afterwards if you always provide user credentials using the START\n  REPLICA statement or START GROUP_REPLICATION statement that starts\n  the replication channel. This approach means that the replication\n  channel always needs operator intervention to restart, but the user\n  credentials are not recorded in the replication metadata\n  repositories.\n\n  *Important*:\n\n  To connect to the source using a replication user account that\n  authenticates with the caching_sha2_password plugin, you must either\n  set up a secure connection as described in\n  https://dev.mysql.com/doc/refman/8.0/en/replication-encrypted-connect\n  ions.html, or enable the unencrypted connection to support password\n  exchange using an RSA key pair. The caching_sha2_password\n  authentication plugin is the default for new users created from MySQL\n  8.0 (for details, see\n  https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authen\n  tication.html). If the user account that you create or use for\n  replication uses this authentication plugin, and you are not using a\n  secure connection, you must enable RSA key pair-based password\n  exchange for a successful connection. You can do this using either\n  the SOURCE_PUBLIC_KEY_PATH option or the GET_SOURCE_PUBLIC_KEY=1\n  option for this statement.\n\no SOURCE_ZSTD_COMPRESSION_LEVEL = level\n\n  The compression level to use for connections to the replication\n  source server that use the zstd compression algorithm.\n  SOURCE_ZSTD_COMPRESSION_LEVEL is available as of MySQL 8.0.18. The\n  permitted levels are from 1 to 22, with larger values indicating\n  increasing levels of compression. The default level is 3.\n\n  The compression level setting has no effect on connections that do\n  not use zstd compression. For more information, see\n  https://dev.mysql.com/doc/refman/8.0/en/connection-compression-contro\n  l.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html'),
(580, 'RESET REPLICA', 43, 'Syntax:\nRESET REPLICA [ALL] [channel_option]\n\nchannel_option:\n    FOR CHANNEL channel\n\nRESET REPLICA makes the replica forget its position in the source\'s\nbinary log. From MySQL 8.0.22, use RESET REPLICA in place of RESET\nSLAVE, which is deprecated from that release. In releases before MySQL\n8.0.22, use RESET SLAVE.\n\nThis statement is meant to be used for a clean start; it clears the\nreplication metadata repositories, deletes all the relay log files, and\nstarts a new relay log file. It also resets to 0 the replication delay\nspecified with the SOURCE_DELAY | MASTER_DELAY option of the CHANGE\nREPLICATION SOURCE TO statement (from MySQL 8.0.23) or CHANGE MASTER TO\nstatement (before MySQL 8.0.23).\n\n*Note*:\n\nAll relay log files are deleted, even if they have not been completely\nexecuted by the replication SQL thread. (This is a condition likely to\nexist on a replica if you have issued a STOP REPLICA statement or if\nthe replica is highly loaded.)\n\nFor a server where GTIDs are in use (gtid_mode is ON), issuing RESET\nREPLICA has no effect on the GTID execution history. The statement does\nnot change the values of gtid_executed or gtid_purged, or the\nmysql.gtid_executed table. If you need to reset the GTID execution\nhistory, use RESET MASTER, even if the GTID-enabled server is a replica\nwhere binary logging is disabled.\n\nRESET REPLICA requires the RELOAD privilege.\n\nTo use RESET REPLICA, the replication SQL thread and replication I/O\n(receiver) thread must be stopped, so on a running replica use STOP\nREPLICA before issuing RESET REPLICA. To use RESET REPLICA on a Group\nReplication group member, the member status must be OFFLINE, meaning\nthat the plugin is loaded but the member does not currently belong to\nany group. A group member can be taken offline by using a STOP GROUP\nREPLICATION statement.\n\nThe optional FOR CHANNEL channel clause enables you to name which\nreplication channel the statement applies to. Providing a FOR CHANNEL\nchannel clause applies the RESET REPLICA statement to a specific\nreplication channel. Combining a FOR CHANNEL channel clause with the\nALL option deletes the specified channel. If no channel is named and no\nextra channels exist, the statement applies to the default channel.\nIssuing a RESET REPLICA ALL statement without a FOR CHANNEL channel\nclause when multiple replication channels exist deletes all replication\nchannels and recreates only the default channel. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nRESET REPLICA does not change any replication connection parameters,\nwhich include the source\'s host name and port, the replication user\naccount and its password, the PRIVILEGE_CHECKS_USER account, the\nREQUIRE_ROW_FORMAT option, the REQUIRE_TABLE_PRIMARY_KEY_CHECK\noption,and the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS option. If you\nwant to change any of the replication connection parameters, you can do\nthis using a CHANGE REPLICATION SOURCE TO statement (from MySQL 8.0.23)\nor CHANGE MASTER TO statement (before MySQL 8.0.23) after the server\nstart. If you want to remove all of the replication connection\nparameters, use RESET REPLICA ALL. RESET REPLICA ALL also clears the\nIGNORE_SERVER_IDS list set by CHANGE REPLICATION SOURCE TO | CHANGE\nMASTER TO. When you have used RESET REPLICA ALL, if you want to use the\ninstance as a replica again, you need to issue a CHANGE REPLICATION\nSOURCE TO | CHANGE MASTER TO statement after the server start to\nspecify new connection parameters.\n\nFrom MySQL 8.0.27, you can set the GTID_ONLY option on the CHANGE\nREPLICATION SOURCE TO statement to stop a replication channel from\npersisting file names and file positions in the replication metadata\nrepositories. When you issue a RESET REPLICA statement, the replication\nmetadata repositories are synchronized. RESET REPLICA ALL deletes\nrather than updates the repositories, so they are synchronized\nimplicitly.\n\nIn the event of an unexpected server exit or deliberate restart after\nissuing RESET REPLICA but before issuing START REPLICA, retention of\nthe replication connection parameters depends on the repository used\nfor the replication metadata:\n\no When master_info_repository=TABLE and relay_log_info_repository=TABLE\n  are set on the server (which are the default settings from MySQL\n  8.0), replication connection parameters are preserved in the\n  crash-safe InnoDB tables mysql.slave_master_info and\n  mysql.slave_relay_log_info as part of the RESET REPLICA operation.\n  They are also retained in memory. In the event of an unexpected\n  server exit or deliberate restart after issuing RESET REPLICA but\n  before issuing START REPLICA, the replication connection parameters\n  are retrieved from the tables and reapplied to the channel. This\n  situation applies from MySQL 8.0.13 for the connection metadata\n  repository, and from MySQL 8.0.19 for the applier metadata\n  repository.\n\no If master_info_repository=FILE and relay_log_info_repository=FILE are\n  set on the server, which is deprecated from MySQL 8.0, or the MySQL\n  Server release is earlier than those specified above, replication\n  connection parameters are only retained in memory. If the replica\n  mysqld is restarted immediately after issuing RESET REPLICA due to an\n  unexpected server exit or deliberate restart, the connection\n  parameters are lost. In that case, you must issue a CHANGE\n  REPLICATION SOURCE TO statement (from MySQL 8.0.23) or CHANGE MASTER\n  TO statement (before MySQL 8.0.23) after the server start to\n  respecify the connection parameters before issuing START REPLICA.\n\nRESET REPLICA does not change any replication filter settings (such as\n--replicate-ignore-table) for channels affected by the statement.\nHowever, RESET REPLICA ALL removes the replication filters that were\nset on the channels deleted by the statement. When the deleted channel\nor channels are recreated, any global replication filters specified for\nthe replica are copied to them, and no channel specific replication\nfilters are applied. For more information see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-rules-channel-based\n-filters.html.\n\nRESET REPLICA causes an implicit commit of an ongoing transaction. See\nhttps://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\nIf the replication SQL thread was in the middle of replicating\ntemporary tables when it was stopped, and RESET REPLICA is issued,\nthese replicated temporary tables are deleted on the replica.\n\nRESET REPLICA does not reset the heartbeat period or\nSSL_VERIFY_SERVER_CERT.\n\n*Note*:\n\nWhen used on an NDB Cluster replica SQL node, RESET REPLICA clears the\nmysql.ndb_apply_status table. You should keep in mind when using this\nstatement that ndb_apply_status uses the NDB storage engine and so is\nshared by all SQL nodes attached to the cluster.\n\nYou can override this behavior by issuing SET GLOBAL\n@@ndb_clear_apply_status=OFF prior to executing RESET REPLICA, which\nkeeps the replica from purging the ndb_apply_status table in such\ncases.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/reset-replica.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/reset-replica.html'),
(581, 'RESET SLAVE', 43, 'Syntax:\nRESET {SLAVE | REPLICA} [ALL] [channel_option]\n\nchannel_option:\n    FOR CHANNEL channel\n\nMakes the replica forget its position in the source\'s binary log. From\nMySQL 8.0.22, RESET SLAVE is deprecated and the alias RESET REPLICA\nshould be used instead. In releases before MySQL 8.0.22, use RESET\nSLAVE. The statement works in the same way as before, only the\nterminology used for the statement and its output has changed. Both\nversions of the statement update the same status variables when used.\nPlease see the documentation for RESET REPLICA for a description of the\nstatement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/reset-slave.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/reset-slave.html'),
(582, 'START REPLICA', 43, 'Syntax:\nSTART REPLICA [thread_types] [until_option] [connection_options] [channel_option]\n\nthread_types:\n    [thread_type [, thread_type] ... ]\n\nthread_type:\n    IO_THREAD | SQL_THREAD\n\nuntil_option:\n    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set\n          |   MASTER_LOG_FILE = \'log_name\', MASTER_LOG_POS = log_pos\n          |   SOURCE_LOG_FILE = \'log_name\', SOURCE_LOG_POS = log_pos\n          |   RELAY_LOG_FILE = \'log_name\', RELAY_LOG_POS = log_pos\n          |   SQL_AFTER_MTS_GAPS  }\n\nconnection_options:\n    [USER=\'user_name\'] [PASSWORD=\'user_pass\'] [DEFAULT_AUTH=\'plugin_name\'] [PLUGIN_DIR=\'plugin_dir\']\n\n\nchannel_option:\n    FOR CHANNEL channel\n\ngtid_set:\n    uuid_set [, uuid_set] ...\n    | \'\'\n\nuuid_set:\n    uuid:interval[:interval]...\n\nuuid:\n    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh\n\nh:\n    [0-9,A-F]\n\ninterval:\n    n[-n]\n\n    (n >= 1)\n\nSTART REPLICA starts the replication threads, either together or\nseparately. From MySQL 8.0.22, use START REPLICA in place of START\nSLAVE, which is deprecated from that release. In releases before MySQL\n8.0.22, use START SLAVE.\n\nSTART REPLICA requires the REPLICATION_SLAVE_ADMIN privilege (or the\ndeprecated SUPER privilege). START REPLICA causes an implicit commit of\nan ongoing transaction. See\nhttps://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\nFor the thread type options, you can specify IO_THREAD, SQL_THREAD,\nboth of these, or neither of them. Only the threads that are started\nare affected by the statement.\n\no START REPLICA with no thread type options starts all of the\n  replication threads, and so does START REPLICA with both of the\n  thread type options.\n\no IO_THREAD starts the replication receiver thread, which reads events\n  from the source server and stores them in the relay log.\n\no SQL_THREAD starts the replication applier thread, which reads events\n  from the relay log and executes them. A multithreaded replica (with\n  replica_parallel_workers or slave_parallel_workers > 0) applies\n  transactions using a coordinator thread and multiple applier threads,\n  and SQL_THREAD starts all of these.\n\n*Important*:\n\nSTART REPLICA sends an acknowledgment to the user after all the\nreplication threads have started. However, the replication receiver\nthread might not yet have connected to the source successfully, or an\napplier thread might stop when applying an event right after starting.\nSTART REPLICA does not continue to monitor the threads after they are\nstarted, so it does not warn you if they subsequently stop or cannot\nconnect. You must check the replica\'s error log for error messages\ngenerated by the replication threads, or check that they are running\nsatisfactorily with SHOW REPLICA STATUS. A successful START REPLICA\nstatement causes SHOW REPLICA STATUS to show Replica_SQL_Running=Yes,\nbut it might or might not show Replica_IO_Running=Yes, because\nReplica_IO_Running=Yes is only shown if the receiver thread is both\nrunning and connected. For more information, see\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-administration-stat\nus.html.\n\nThe optional FOR CHANNEL channel clause enables you to name which\nreplication channel the statement applies to. Providing a FOR CHANNEL\nchannel clause applies the START REPLICA statement to a specific\nreplication channel. If no clause is named and no extra channels exist,\nthe statement applies to the default channel. If a START REPLICA\nstatement does not have a channel defined when using multiple channels,\nthis statement starts the specified threads for all channels. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nThe replication channels for Group Replication\n(group_replication_applier and group_replication_recovery) are managed\nautomatically by the server instance. START REPLICA cannot be used at\nall with the group_replication_recovery channel, and should only be\nused with the group_replication_applier channel when Group Replication\nis not running. The group_replication_applier channel only has an\napplier thread and has no receiver thread, so it can be started if\nrequired by using the SQL_THREAD option without the IO_THREAD option.\n\nSTART REPLICA supports pluggable user-password authentication (see\nhttps://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html)\nwith the USER, PASSWORD, DEFAULT_AUTH and PLUGIN_DIR options, as\ndescribed in the following list. When you use these options, you must\nstart the receiver thread (IO_THREAD option) or all the replication\nthreads - you cannot start the replication applier thread (SQL_THREAD\noption) alone.\n\no USER\n\n  The user name for the account. You must set this if PASSWORD is used.\n  The option cannot be set to an empty or null string.\n\no PASSWORD\n\n  The password for the named user account.\n\no DEFAULT_AUTH\n\n  The name of the authentication plugin. The default is MySQL native\n  authentication.\n\no PLUGIN_DIR\n\n  The location of the authentication plugin.\n\n*Important*:\n\nThe password that you set using START REPLICA is masked when it is\nwritten to MySQL Server\'s logs, Performance Schema tables, and SHOW\nPROCESSLIST statements. However, it is sent in plain text over the\nconnection to the replica server instance. To protect the password in\ntransit, use SSL/TLS encryption, an SSH tunnel, or another method of\nprotecting the connection from unauthorized viewing, for the connection\nbetween the replica server instance and the client that you use to\nissue START REPLICA.\n\nThe UNTIL clause makes the replica start replication, then process\ntransactions up to the point that you specify in the UNTIL clause, then\nstop again. The UNTIL clause can be used to make a replica proceed\nuntil just before the point where you want to skip a transaction that\nis unwanted, and then skip the transaction as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-administration-skip\n.html. To identify a transaction, you can use mysqlbinlog with the\nsource\'s binary log or the replica\'s relay log, or use a SHOW BINLOG\nEVENTS statement.\n\nYou can also use the UNTIL clause for debugging replication by\nprocessing transactions one at a time or in sections. If you are using\nthe UNTIL clause to do this, start the replica with the\n--skip-slave-start option, or from MySQL 8.0.24, the skip_slave_start\nsystem variable, to prevent the SQL thread from running when the\nreplica server starts. Remove the option or system variable setting\nafter the procedure is complete, so that it is not forgotten in the\nevent of an unexpected server restart.\n\nThe SHOW REPLICA STATUS statement includes output fields that display\nthe current values of the UNTIL condition. The UNTIL condition lasts\nfor as long as the affected threads are still running, and is removed\nwhen they stop.\n\nThe UNTIL clause operates on the replication applier thread (SQL_THREAD\noption). You can use the SQL_THREAD option or let the replica default\nto starting both threads. If you use the IO_THREAD option alone, the\nUNTIL clause is ignored because the applier thread is not started.\n\nThe point that you specify in the UNTIL clause can be any one (and only\none) of the following options:\n\no SOURCE_LOG_FILE and SOURCE_LOG_POS (from MySQL 8.0.23), or\n  MASTER_LOG_FILE and MASTER_LOG_POS (to MySQL 8.0.22)\n\n  These options make the replication applier process transactions up to\n  a position in its relay log, identified by the file name and file\n  position of the corresponding point in the binary log on the source\n  server. The applier thread finds the nearest transaction boundary at\n  or after the specified position, finishes applying the transaction,\n  and stops there. For compressed transaction payloads, specify the end\n  position of the compressed Transaction_payload_event.\n\n  These options can still be used when the GTID_ONLY option was set on\n  the CHANGE REPLICATION SOURCE TO statement to stop the replication\n  channel from persisting file names and file positions in the\n  replication metadata repositories. The file names and file positions\n  are tracked in memory.\n\no RELAY_LOG_FILE and RELAY_LOG_POS\n\n  These options make the replication applier process transactions up to\n  a position in the replica\'s relay log, identified by the relay log\n  file name and a position in that file. The applier thread finds the\n  nearest transaction boundary at or after the specified position,\n  finishes applying the transaction, and stops there. For compressed\n  transaction payloads, specify the end position of the compressed\n  Transaction_payload_event.\n\n  These options can still be used when the GTID_ONLY option was set on\n  the CHANGE REPLICATION SOURCE TO statement to stop the replication\n  channel from persisting file names and file positions in the\n  replication metadata repositories. The file names and file positions\n  are tracked in memory.\n\no SQL_BEFORE_GTIDS\n\n  This option makes the replication applier start processing\n  transactions and stop when it encounters any transaction that is in\n  the specified GTID set. The encountered transaction from the GTID set\n  is not applied, and nor are any of the other transactions in the GTID\n  set. The option takes a GTID set containing one or more global\n  transaction identifiers as an argument (see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.ht\n  ml#replication-gtids-concepts-gtid-sets). Transactions in a GTID set\n  do not necessarily appear in the replication stream in the order of\n  their GTIDs, so the transaction before which the applier stops is not\n  necessarily the earliest.\n\no SQL_AFTER_GTIDS\n\n  This option makes the replication applier start processing\n  transactions and stop when it has processed all of the transactions\n  in a specified GTID set. The option takes a GTID set containing one\n  or more global transaction identifiers as an argument (see\n  https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.ht\n  ml#replication-gtids-concepts-gtid-sets).\n\n  With SQL_AFTER_GTIDS, the replication threads stop when they have\n  processed the transactions in the GTID set and encounter the first\n  transaction whose GTID is not part of the GTID set. For example,\n  executing START REPLICA UNTIL SQL_AFTER_GTIDS =\n  3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 causes the replica to\n  obtain all transactions just mentioned from the source, including all\n  of the transactions having the sequence numbers 11 through 56, and\n  then to stop without processing any additional transactions.\n\no SQL_AFTER_MTS_GAPS\n\n  For a multithreaded replica only (with replica_parallel_workers or\n  slave_parallel_workers > 0), this option makes the replica process\n  transactions up to the point where there are no more gaps in the\n  sequence of transactions executed from the relay log. When using a\n  multithreaded replica, there is a chance of gaps occurring in the\n  following situations:\n\n  o The coordinator thread is stopped.\n\n  o An error occurs in the applier threads.\n\n  o mysqld shuts down unexpectedly.\n\n  When a replication channel has gaps, the replica\'s database is in a\n  state that might never have existed on the source. The replica tracks\n  the gaps internally and disallows CHANGE REPLICATION SOURCE TO\n  statements that would remove the gap information if they executed.\n\n  Before MySQL 8.0.26, issuing START REPLICA on a multithreaded replica\n  with gaps in the sequence of transactions executed from the relay log\n  generates a warning. To correct this situation, the solution is to\n  use START REPLICA UNTIL SQL_AFTER_MTS_GAPS. See\n  https://dev.mysql.com/doc/refman/8.0/en/replication-features-transact\n  ion-inconsistencies.html for more information.\n\n  From MySQL 8.0.26, the process of checking for gaps in the sequence\n  of transactions is skipped entirely when GTID-based replication and\n  GTID auto-positioning (SOURCE_AUTO_POSITION=1) are in use for the\n  channel, because gaps in transactions can be resolved using GTID\n  auto-positioning. In that situation, START REPLICA UNTIL\n  SQL_AFTER_MTS_GAPS just stops the applier thread when it finds the\n  first transaction to execute, and does not attempt to check for gaps\n  in the sequence of transactions. You can also continue to use CHANGE\n  REPLICATION SOURCE TO statements as normal, and relay log recovery is\n  possible for the channel.\n\n  From MySQL 8.0.27, all replicas are multithreaded by default. When\n  replica_preserve_commit_order=ON or slave_preserve_commit_order=ON is\n  set for the replica, which is also the default setting from MySQL\n  8.0.27, gaps should not occur except in the specific situations\n  listed in the description for replica_preserve_commit_order and\n  slave_preserve_commit_order. If replica_preserve_commit_order=OFF or\n  slave_preserve_commit_order=OFF is set for the replica, which is the\n  default before MySQL 8.0.27, the commit order of transactions is not\n  preserved, so the chance of gaps occurring is much larger.\n\n  If GTIDs are not in use and you need to change a failed multithreaded\n  replica to single-threaded mode, you can issue the following series\n  of statements, in the order shown:\n\nSTART SLAVE UNTIL SQL_AFTER_MTS_GAPS;\nSET @@GLOBAL.slave_parallel_workers = 0;\nSTART SLAVE SQL_THREAD;\n\nOr from MySQL 8.0.26:\nSTART REPLICA UNTIL SQL_AFTER_MTS_GAPS;\nSET @@GLOBAL.replica_parallel_workers = 0;\nSTART REPLICA SQL_THREAD;\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/start-replica.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/start-replica.html'),
(583, 'START SLAVE', 43, 'Syntax:\nSTART {SLAVE | REPLICA} [thread_types] [until_option] [connection_options] [channel_option]\n\nthread_types:\n    [thread_type [, thread_type] ... ]\n\nthread_type:\n    IO_THREAD | SQL_THREAD\n\nuntil_option:\n    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set\n          |   MASTER_LOG_FILE = \'log_name\', MASTER_LOG_POS = log_pos\n          |   SOURCE_LOG_FILE = \'log_name\', SOURCE_LOG_POS = log_pos\n          |   RELAY_LOG_FILE = \'log_name\', RELAY_LOG_POS = log_pos\n          |   SQL_AFTER_MTS_GAPS  }\n\nconnection_options:\n    [USER=\'user_name\'] [PASSWORD=\'user_pass\'] [DEFAULT_AUTH=\'plugin_name\'] [PLUGIN_DIR=\'plugin_dir\']\n\n\nchannel_option:\n    FOR CHANNEL channel\n\ngtid_set:\n    uuid_set [, uuid_set] ...\n    | \'\'\n\nuuid_set:\n    uuid:interval[:interval]...\n\nuuid:\n    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh\n\nh:\n    [0-9,A-F]\n\ninterval:\n    n[-n]\n\n    (n >= 1)\n\nStarts the replication threads. From MySQL 8.0.22, START SLAVE is\ndeprecated and the alias START REPLICA should be used instead. The\nstatement works in the same way as before, only the terminology used\nfor the statement and its output has changed. Both versions of the\nstatement update the same status variables when used. Please see the\ndocumentation for START REPLICA for a description of the statement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/start-slave.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/start-slave.html'),
(584, 'STOP REPLICA', 43, 'Syntax:\nSTOP REPLICA [thread_types] [channel_option]\n\nthread_types:\n    [thread_type [, thread_type] ... ]\n\nthread_type: IO_THREAD | SQL_THREAD\n\nchannel_option:\n    FOR CHANNEL channel\n\nStops the replication threads. From MySQL 8.0.22, use STOP REPLICA in\nplace of STOP SLAVE, which is now deprecated. In releases before MySQL\n8.0.22, use STOP SLAVE.\n\nSTOP REPLICA requires the REPLICATION_SLAVE_ADMIN privilege (or the\ndeprecated SUPER privilege). Recommended best practice is to execute\nSTOP REPLICA on the replica before stopping the replica server (see\nhttps://dev.mysql.com/doc/refman/8.0/en/server-shutdown.html, for more\ninformation).\n\nLike START REPLICA, this statement may be used with the IO_THREAD and\nSQL_THREAD options to name the replication thread or threads to be\nstopped. Note that the Group Replication applier channel\n(group_replication_applier) has no replication I/O (receiver) thread,\nonly a replication SQL (applier) thread. Using the SQL_THREAD option\ntherefore stops this channel completely.\n\nSTOP REPLICA causes an implicit commit of an ongoing transaction. See\nhttps://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.\n\ngtid_next must be set to AUTOMATIC before issuing this statement.\n\nYou can control how long STOP REPLICA waits before timing out by\nsetting the system variable rpl_stop_replica_timeout (from MySQL\n8.0.26) or rpl_stop_slave_timeout (before MySQL 8.0.26). This can be\nused to avoid deadlocks between STOP REPLICA and other SQL statements\nusing different client connections to the replica. When the timeout\nvalue is reached, the issuing client returns an error message and stops\nwaiting, but the STOP REPLICA instruction remains in effect. Once the\nreplication threads are no longer busy, the STOP REPLICA statement is\nexecuted and the replica stops.\n\nSome CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO statements are\nallowed while the replica is running, depending on the states of the\nreplication threads. However, using STOP REPLICA prior to executing a\nCHANGE REPLICATION SOURCE TO | CHANGE MASTER TO statement in such cases\nis still supported. See [HELP CHANGE REPLICATION SOURCE TO], [HELP\nCHANGE MASTER TO], and\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-solutions-switch.html\n, for more information.\n\nThe optional FOR CHANNEL channel clause enables you to name which\nreplication channel the statement applies to. Providing a FOR CHANNEL\nchannel clause applies the STOP REPLICA statement to a specific\nreplication channel. If no channel is named and no extra channels\nexist, the statement applies to the default channel. If a STOP REPLICA\nstatement does not name a channel when using multiple channels, this\nstatement stops the specified threads for all channels. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for\nmore information.\n\nThe replication channels for Group Replication\n(group_replication_applier and group_replication_recovery) are managed\nautomatically by the server instance. STOP REPLICA cannot be used at\nall with the group_replication_recovery channel, and should only be\nused with the group_replication_applier channel when Group Replication\nis not running. The group_replication_applier channel only has an\napplier thread and has no receiver thread, so it can be stopped if\nrequired by using the SQL_THREAD option without the IO_THREAD option.\n\nWhen the replica is multithreaded (replica_parallel_workers or\nslave_parallel_workers is a nonzero value), any gaps in the sequence of\ntransactions executed from the relay log are closed as part of stopping\nthe worker threads. If the replica is stopped unexpectedly (for example\ndue to an error in a worker thread, or another thread issuing KILL)\nwhile a STOP REPLICA statement is executing, the sequence of executed\ntransactions from the relay log may become inconsistent. See\nhttps://dev.mysql.com/doc/refman/8.0/en/replication-features-transactio\nn-inconsistencies.html, for more information.\n\nWhen the source is using the row-based binary logging format, you\nshould execute STOP REPLICA or STOP REPLICA SQL_THREAD on the replica\nprior to shutting down the replica server if you are replicating any\ntables that use a nontransactional storage engine. If the current\nreplication event group has modified one or more nontransactional\ntables, STOP REPLICA waits for up to 60 seconds for the event group to\ncomplete, unless you issue a KILL QUERY or KILL CONNECTION statement\nfor the replication SQL thread. If the event group remains incomplete\nafter the timeout, an error message is logged.\n\nWhen the source is using the statement-based binary logging format,\nchanging the source while it has open temporary tables is potentially\nunsafe. This is one of the reasons why statement-based replication of\ntemporary tables is not recommended. You can find out whether there are\nany temporary tables on the replica by checking the value of\nReplica_open_temp_tables or Slave_open_temp_tables. When using\nstatement-based replication, this value should be 0 before executing\nCHANGE REPLICATION SOURCE TO | CHANGE MASTER TO. If there are any\ntemporary tables open on the replica, issuing a CHANGE REPLICATION\nSOURCE TO | CHANGE MASTER TO statement after issuing a STOP REPLICA\ncauses an ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO\n(https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html\n#error_er_warn_open_temp_tables_must_be_zero) warning.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/stop-replica.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/stop-replica.html'),
(585, 'STOP SLAVE', 43, 'Syntax:\nSTOP {SLAVE | REPLICA} [thread_types] [channel_option]\n\nthread_types:\n    [thread_type [, thread_type] ... ]\n\nthread_type: IO_THREAD | SQL_THREAD\n\nchannel_option:\n    FOR CHANNEL channel\n\nStops the replication threads. From MySQL 8.0.22, STOP SLAVE is\ndeprecated and the alias STOP REPLICA should be used instead. The\nstatement works in the same way as before, only the terminology used\nfor the statement and its output has changed. Both versions of the\nstatement update the same status variables when used. Please see the\ndocumentation for STOP REPLICA for a description of the statement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/stop-slave.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/stop-slave.html'),
(586, 'PREPARE', 44, 'Syntax:\nPREPARE stmt_name FROM preparable_stmt\n\nThe PREPARE statement prepares a SQL statement and assigns it a name,\nstmt_name, by which to refer to the statement later. The prepared\nstatement is executed with EXECUTE and released with DEALLOCATE\nPREPARE. For examples, see\nhttps://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html.\n\nStatement names are not case-sensitive. preparable_stmt is either a\nstring literal or a user variable that contains the text of the SQL\nstatement. The text must represent a single statement, not multiple\nstatements. Within the statement, ? characters can be used as parameter\nmarkers to indicate where data values are to be bound to the query\nlater when you execute it. The ? characters should not be enclosed\nwithin quotation marks, even if you intend to bind them to string\nvalues. Parameter markers can be used only where data values should\nappear, not for SQL keywords, identifiers, and so forth.\n\nIf a prepared statement with the given name already exists, it is\ndeallocated implicitly before the new statement is prepared. This means\nthat if the new statement contains an error and cannot be prepared, an\nerror is returned and no statement with the given name exists.\n\nThe scope of a prepared statement is the session within which it is\ncreated, which as several implications:\n\no A prepared statement created in one session is not available to other\n  sessions.\n\no When a session ends, whether normally or abnormally, its prepared\n  statements no longer exist. If auto-reconnect is enabled, the client\n  is not notified that the connection was lost. For this reason,\n  clients may wish to disable auto-reconnect. See Automatic\n  Reconnection Control\n  (https://dev.mysql.com/doc/c-api/8.0/en/c-api-auto-reconnect.html).\n\no A prepared statement created within a stored program continues to\n  exist after the program finishes executing and can be executed\n  outside the program later.\n\no A statement prepared in stored program context cannot refer to stored\n  procedure or function parameters or local variables because they go\n  out of scope when the program ends and would be unavailable were the\n  statement to be executed later outside the program. As a workaround,\n  refer instead to user-defined variables, which also have session\n  scope; see\n  https://dev.mysql.com/doc/refman/8.0/en/user-variables.html.\n\nBeginning with MySQL 8.0.22, a parameter used in a prepared statement\nhas its type determined when the statement is first prepared, and\nretains this type whenever EXECUTE is invoked for this prepared\nstatement (unless the statement is reprepared, as explained later in\nthis section). Rules for determining a parameter\'s type are listed\nhere:\n\no A parameter which is an operand of a binary arithmetic operator has\n  the same data type as the other operand.\n\no If both operands of a binary arithmetic operator are parameters, the\n  type of the parameters is decided by the context of the operator.\n\no If a parameter is the operand of a unary arithmetic operator, the\n  parameter\'s type is decided by the context of the operator.\n\no If an arithmetic operator has no type-determining context, the\n  derived type for any parameters involved is DOUBLE PRECISION. This\n  can happen, for example, when the parameter is a top-level node in a\n  SELECT list, or when it is part of a comparison operator.\n\no A parameter which is an operand of a character string operator has\n  the same derived type as the aggregated type of the other operands.\n  If all operands of the operator are parameters, the derived type is\n  VARCHAR; its collation is determined by the value of\n  collation_connection.\n\no A parameter which is an operand of a temporal operator has type\n  DATETIME if the operator returns a DATETIME, TIME if the operator\n  returns a TIME, and DATE if the operator returns a DATE.\n\no A parameter which is an operand of a binary comparison operator has\n  the same derived type as the other operand of the comparison.\n\no A parameter that is an operand of a ternary comparison operator such\n  as BETWEEN has the same derived type as the aggregated type of the\n  other operands.\n\no If all operands of a comparison operator are parameters, the derived\n  type for each of them is VARCHAR, with collation determined by the\n  value of collation_connection.\n\no A parameter that is an output operand of any of CASE, COALESCE, IF,\n  IFNULL, or NULLIF has the same derived type as the aggregated type of\n  the operator\'s other output operands.\n\no If all output operands of any of CASE, COALESCE, IF, IFNULL, or\n  NULLIF are parameters, or they are all NULL, the type of the\n  parameter is decided by the context of the operator.\n\no If the parameter is an operand of any of CASE, COALESCE(), IF, or\n  IFNULL, and has no type-determining context, the derived type for\n  each of the parameters involved is VARCHAR, and its collation is\n  determined by the value of collation_connection.\n\no A parameter which is the operand of a CAST() has the same type as\n  specified by the CAST().\n\no If a parameter is an immediate member of a SELECT list that is not\n  part of an INSERT statement, the derived type of the parameter is\n  VARCHAR, and its collation is determined by the value of\n  collation_connection.\n\no If a parameter is an immediate member of a SELECT list that is part\n  of an INSERT statement, the derived type of the parameter is the type\n  of the corresponding column into which the parameter is inserted.\n\no If a parameter is used as source for an assignment in a SET clause of\n  an UPDATE statement or in the ON DUPLICATE KEY UPDATE clause of an\n  INSERT statement, the derived type of the parameter is the type of\n  the corresponding column which is updated by the SET or ON DUPLICATE\n  KEY UPDATE clause.\n\no If a parameter is an argument of a function, the derived type depends\n  on the function\'s return type.\n\nFor some combinations of actual type and derived type, an automatic\nrepreparation of the statement is triggered, to ensure closer\ncompatibility with previous versions of MySQL. Repreparation does not\noccur if any of the following conditions are true:\n\no NULL is used as the actual parameter value.\n\no A parameter is an operand of a CAST(). (Instead, a cast to the\n  derived type is attempted, and an exception raised if the cast\n  fails.)\n\no A parameter is a string. (In this case, an implicit CAST(? AS\n  derived_type) is performed.)\n\no The derived type and actual type of the parameter are both INTEGER\n  and have the same sign.\n\no The parameter\'s derived type is DECIMAL and its actual type is either\n  DECIMAL or INTEGER.\n\no The derived type is DOUBLE and the actual type is any numeric type.\n\no Both the derived type and the actual type are string types.\n\no If the derived type is temporal and the actual type is temporal.\n  Exceptions: The derived type is TIME and the actual type is not TIME;\n  the derived type is DATE and the actual type is not DATE.\n\no The derived type is temporal and the actual type is numeric.\n\nFor cases other than those just listed, the statement is reprepared and\nthe actual parameter types are used instead of the derived parameter\ntypes.\n\nThese rules also apply to a user variable referenced in a prepared\nstatement.\n\nUsing a different data type for a given parameter or user variable\nwithin a prepared statement for executions of the statement subsequent\nto the first execution causes the statement to be reprepared. This is\nless efficient; it may also lead to the parameter\'s (or variable\'s)\nactual type to vary, and thus for results to be inconsistent, with\nsubsequent executions of the prepared statement. For these reasons, it\nis advisable to use the same data type for a given parameter when\nre-executing a prepared statement.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/prepare.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/prepare.html'),
(587, 'EXECUTE STATEMENT', 44, 'Syntax:\nEXECUTE stmt_name\n    [USING @var_name [, @var_name] ...]\n\nAfter preparing a statement with PREPARE, you execute it with an\nEXECUTE statement that refers to the prepared statement name. If the\nprepared statement contains any parameter markers, you must supply a\nUSING clause that lists user variables containing the values to be\nbound to the parameters. Parameter values can be supplied only by user\nvariables, and the USING clause must name exactly as many variables as\nthe number of parameter markers in the statement.\n\nYou can execute a given prepared statement multiple times, passing\ndifferent variables to it or setting the variables to different values\nbefore each execution.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/execute.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/execute.html'),
(588, 'DEALLOCATE PREPARE', 44, 'Syntax:\n{DEALLOCATE | DROP} PREPARE stmt_name\n\nTo deallocate a prepared statement produced with PREPARE, use a\nDEALLOCATE PREPARE statement that refers to the prepared statement\nname. Attempting to execute a prepared statement after deallocating it\nresults in an error. If too many prepared statements are created and\nnot deallocated by either the DEALLOCATE PREPARE statement or the end\nof the session, you might encounter the upper limit enforced by the\nmax_prepared_stmt_count system variable.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/deallocate-prepare.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/deallocate-prepare.html'),
(589, 'DROP PREPARE', 44, 'Syntax:\n{DEALLOCATE | DROP} PREPARE stmt_name\n\nTo deallocate a prepared statement produced with PREPARE, use a\nDEALLOCATE PREPARE statement that refers to the prepared statement\nname. Attempting to execute a prepared statement after deallocating it\nresults in an error. If too many prepared statements are created and\nnot deallocated by either the DEALLOCATE PREPARE statement or the end\nof the session, you might encounter the upper limit enforced by the\nmax_prepared_stmt_count system variable.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/deallocate-prepare.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/deallocate-prepare.html'),
(590, 'BEGIN END', 45, 'Syntax:\n[begin_label:] BEGIN\n    [statement_list]\nEND [end_label]\n\nBEGIN ... END syntax is used for writing compound statements, which can\nappear within stored programs (stored procedures and functions,\ntriggers, and events). A compound statement can contain multiple\nstatements, enclosed by the BEGIN and END keywords. statement_list\nrepresents a list of one or more statements, each terminated by a\nsemicolon (;) statement delimiter. The statement_list itself is\noptional, so the empty compound statement (BEGIN END) is legal.\n\nBEGIN ... END blocks can be nested.\n\nUse of multiple statements requires that a client is able to send\nstatement strings containing the ; statement delimiter. In the mysql\ncommand-line client, this is handled with the delimiter command.\nChanging the ; end-of-statement delimiter (for example, to //) permit ;\nto be used in a program body. For an example, see\nhttps://dev.mysql.com/doc/refman/8.0/en/stored-programs-defining.html.\n\nA BEGIN ... END block can be labeled. See [HELP labels].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/begin-end.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/begin-end.html'),
(591, 'LABELS', 45, 'Syntax:\n[begin_label:] BEGIN\n    [statement_list]\nEND [end_label]\n\n[begin_label:] LOOP\n    statement_list\nEND LOOP [end_label]\n\n[begin_label:] REPEAT\n    statement_list\nUNTIL search_condition\nEND REPEAT [end_label]\n\n[begin_label:] WHILE search_condition DO\n    statement_list\nEND WHILE [end_label]\n\nLabels are permitted for BEGIN ... END blocks and for the LOOP, REPEAT,\nand WHILE statements. Label use for those statements follows these\nrules:\n\no begin_label must be followed by a colon.\n\no begin_label can be given without end_label. If end_label is present,\n  it must be the same as begin_label.\n\no end_label cannot be given without begin_label.\n\no Labels at the same nesting level must be distinct.\n\no Labels can be up to 16 characters long.\n\nTo refer to a label within the labeled construct, use an ITERATE or\nLEAVE statement. The following example uses those statements to\ncontinue iterating or terminate the loop:\n\nCREATE PROCEDURE doiterate(p1 INT)\nBEGIN\n  label1: LOOP\n    SET p1 = p1 + 1;\n    IF p1 < 10 THEN ITERATE label1; END IF;\n    LEAVE label1;\n  END LOOP label1;\nEND;\n\nThe scope of a block label does not include the code for handlers\ndeclared within the block. For details, see [HELP DECLARE HANDLER].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/statement-labels.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/statement-labels.html'),
(592, 'DECLARE VARIABLE', 45, 'Syntax:\nDECLARE var_name [, var_name] ... type [DEFAULT value]\n\nThis statement declares local variables within stored programs. To\nprovide a default value for a variable, include a DEFAULT clause. The\nvalue can be specified as an expression; it need not be a constant. If\nthe DEFAULT clause is missing, the initial value is NULL.\n\nLocal variables are treated like stored routine parameters with respect\nto data type and overflow checking. See [HELP CREATE PROCEDURE].\n\nVariable declarations must appear before cursor or handler\ndeclarations.\n\nLocal variable names are not case-sensitive. Permissible characters and\nquoting rules are the same as for other identifiers, as described in\nhttps://dev.mysql.com/doc/refman/8.0/en/identifiers.html.\n\nThe scope of a local variable is the BEGIN ... END block within which\nit is declared. The variable can be referred to in blocks nested within\nthe declaring block, except those blocks that declare a variable with\nthe same name.\n\nFor examples of variable declarations, see\nhttps://dev.mysql.com/doc/refman/8.0/en/local-variable-scope.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/declare-local-variable.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/declare-local-variable.html'),
(593, 'CASE STATEMENT', 45, 'Syntax:\nCASE case_value\n    WHEN when_value THEN statement_list\n    [WHEN when_value THEN statement_list] ...\n    [ELSE statement_list]\nEND CASE\n\nOr:\n\nCASE\n    WHEN search_condition THEN statement_list\n    [WHEN search_condition THEN statement_list] ...\n    [ELSE statement_list]\nEND CASE\n\nThe CASE statement for stored programs implements a complex conditional\nconstruct.\n\n*Note*:\n\nThere is also a CASE operator, which differs from the CASE statement\ndescribed here. See\nhttps://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html.\nThe CASE statement cannot have an ELSE NULL clause, and it is\nterminated with END CASE instead of END.\n\nFor the first syntax, case_value is an expression. This value is\ncompared to the when_value expression in each WHEN clause until one of\nthem is equal. When an equal when_value is found, the corresponding\nTHEN clause statement_list executes. If no when_value is equal, the\nELSE clause statement_list executes, if there is one.\n\nThis syntax cannot be used to test for equality with NULL because NULL\n= NULL is false. See\nhttps://dev.mysql.com/doc/refman/8.0/en/working-with-null.html.\n\nFor the second syntax, each WHEN clause search_condition expression is\nevaluated until one is true, at which point its corresponding THEN\nclause statement_list executes. If no search_condition is equal, the\nELSE clause statement_list executes, if there is one.\n\nIf no when_value or search_condition matches the value tested and the\nCASE statement contains no ELSE clause, a Case not found for CASE\nstatement error results.\n\nEach statement_list consists of one or more SQL statements; an empty\nstatement_list is not permitted.\n\nTo handle situations where no value is matched by any WHEN clause, use\nan ELSE containing an empty BEGIN ... END block, as shown in this\nexample. (The indentation used here in the ELSE clause is for purposes\nof clarity only, and is not otherwise significant.)\n\nDELIMITER |\n\nCREATE PROCEDURE p()\n  BEGIN\n    DECLARE v INT DEFAULT 1;\n\n    CASE v\n      WHEN 2 THEN SELECT v;\n      WHEN 3 THEN SELECT 0;\n      ELSE\n        BEGIN\n        END;\n    END CASE;\n  END;\n  |\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/case.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/case.html'),
(594, 'IF STATEMENT', 45, 'Syntax:\nIF search_condition THEN statement_list\n    [ELSEIF search_condition THEN statement_list] ...\n    [ELSE statement_list]\nEND IF\n\nThe IF statement for stored programs implements a basic conditional\nconstruct.\n\n*Note*:\n\nThere is also an IF() function, which differs from the IF statement\ndescribed here. See\nhttps://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html.\nThe IF statement can have THEN, ELSE, and ELSEIF clauses, and it is\nterminated with END IF.\n\nIf a given search_condition evaluates to true, the corresponding THEN\nor ELSEIF clause statement_list executes. If no search_condition\nmatches, the ELSE clause statement_list executes.\n\nEach statement_list consists of one or more SQL statements; an empty\nstatement_list is not permitted.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/if.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/if.html'),
(595, 'ITERATE', 45, 'Syntax:\nITERATE label\n\nITERATE can appear only within LOOP, REPEAT, and WHILE statements.\nITERATE means \"start the loop again.\"\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/iterate.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/iterate.html'),
(596, 'LEAVE', 45, 'Syntax:\nLEAVE label\n\nThis statement is used to exit the flow control construct that has the\ngiven label. If the label is for the outermost stored program block,\nLEAVE exits the program.\n\nLEAVE can be used within BEGIN ... END or loop constructs (LOOP,\nREPEAT, WHILE).\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/leave.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/leave.html'),
(597, 'LOOP', 45, 'Syntax:\n[begin_label:] LOOP\n    statement_list\nEND LOOP [end_label]\n\nLOOP implements a simple loop construct, enabling repeated execution of\nthe statement list, which consists of one or more statements, each\nterminated by a semicolon (;) statement delimiter. The statements\nwithin the loop are repeated until the loop is terminated. Usually,\nthis is accomplished with a LEAVE statement. Within a stored function,\nRETURN can also be used, which exits the function entirely.\n\nNeglecting to include a loop-termination statement results in an\ninfinite loop.\n\nA LOOP statement can be labeled. For the rules regarding label use, see\n[HELP labels].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/loop.html\n\n', 'CREATE PROCEDURE doiterate(p1 INT)\nBEGIN\n  label1: LOOP\n    SET p1 = p1 + 1;\n    IF p1 < 10 THEN\n      ITERATE label1;\n    END IF;\n    LEAVE label1;\n  END LOOP label1;\n  SET @x = p1;\nEND;\n', 'https://dev.mysql.com/doc/refman/8.0/en/loop.html'),
(598, 'REPEAT LOOP', 45, 'Syntax:\n[begin_label:] REPEAT\n    statement_list\nUNTIL search_condition\nEND REPEAT [end_label]\n\nThe statement list within a REPEAT statement is repeated until the\nsearch_condition expression is true. Thus, a REPEAT always enters the\nloop at least once. statement_list consists of one or more statements,\neach terminated by a semicolon (;) statement delimiter.\n\nA REPEAT statement can be labeled. For the rules regarding label use,\nsee [HELP labels].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/repeat.html\n\n', 'mysql> delimiter //\n\nmysql> CREATE PROCEDURE dorepeat(p1 INT)\n       BEGIN\n         SET @x = 0;\n         REPEAT\n           SET @x = @x + 1;\n         UNTIL @x > p1 END REPEAT;\n       END\n       //\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> CALL dorepeat(1000)//\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT @x//\n+------+\n| @x   |\n+------+\n| 1001 |\n+------+\n1 row in set (0.00 sec)\n', 'https://dev.mysql.com/doc/refman/8.0/en/repeat.html'),
(599, 'RETURN', 45, 'Syntax:\nRETURN expr\n\nThe RETURN statement terminates execution of a stored function and\nreturns the value expr to the function caller. There must be at least\none RETURN statement in a stored function. There may be more than one\nif the function has multiple exit points.\n\nThis statement is not used in stored procedures, triggers, or events.\nThe LEAVE statement can be used to exit a stored program of those\ntypes.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/return.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/return.html'),
(600, 'WHILE', 45, 'Syntax:\n[begin_label:] WHILE search_condition DO\n    statement_list\nEND WHILE [end_label]\n\nThe statement list within a WHILE statement is repeated as long as the\nsearch_condition expression is true. statement_list consists of one or\nmore SQL statements, each terminated by a semicolon (;) statement\ndelimiter.\n\nA WHILE statement can be labeled. For the rules regarding label use,\nsee [HELP labels].\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/while.html\n\n', 'CREATE PROCEDURE dowhile()\nBEGIN\n  DECLARE v1 INT DEFAULT 5;\n\n  WHILE v1 > 0 DO\n    ...\n    SET v1 = v1 - 1;\n  END WHILE;\nEND;\n', 'https://dev.mysql.com/doc/refman/8.0/en/while.html'),
(601, 'CLOSE', 45, 'Syntax:\nCLOSE cursor_name\n\nThis statement closes a previously opened cursor. For an example, see\nhttps://dev.mysql.com/doc/refman/8.0/en/cursors.html.\n\nAn error occurs if the cursor is not open.\n\nIf not closed explicitly, a cursor is closed at the end of the BEGIN\n... END block in which it was declared.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/close.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/close.html'),
(602, 'DECLARE CURSOR', 45, 'Syntax:\nDECLARE cursor_name CURSOR FOR select_statement\n\nThis statement declares a cursor and associates it with a SELECT\nstatement that retrieves the rows to be traversed by the cursor. To\nfetch the rows later, use a FETCH statement. The number of columns\nretrieved by the SELECT statement must match the number of output\nvariables specified in the FETCH statement.\n\nThe SELECT statement cannot have an INTO clause.\n\nCursor declarations must appear before handler declarations and after\nvariable and condition declarations.\n\nA stored program may contain multiple cursor declarations, but each\ncursor declared in a given block must have a unique name. For an\nexample, see https://dev.mysql.com/doc/refman/8.0/en/cursors.html.\n\nFor information available through SHOW statements, it is possible in\nmany cases to obtain equivalent information by using a cursor with an\nINFORMATION_SCHEMA table.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/declare-cursor.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/declare-cursor.html'),
(603, 'FETCH', 45, 'Syntax:\nFETCH [[NEXT] FROM] cursor_name INTO var_name [, var_name] ...\n\nThis statement fetches the next row for the SELECT statement associated\nwith the specified cursor (which must be open), and advances the cursor\npointer. If a row exists, the fetched columns are stored in the named\nvariables. The number of columns retrieved by the SELECT statement must\nmatch the number of output variables specified in the FETCH statement.\n\nIf no more rows are available, a No Data condition occurs with SQLSTATE\nvalue \'02000\'. To detect this condition, you can set up a handler for\nit (or for a NOT FOUND condition). For an example, see\nhttps://dev.mysql.com/doc/refman/8.0/en/cursors.html.\n\nBe aware that another operation, such as a SELECT or another FETCH, may\nalso cause the handler to execute by raising the same condition. If it\nis necessary to distinguish which operation raised the condition, place\nthe operation within its own BEGIN ... END block so that it can be\nassociated with its own handler.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/fetch.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/fetch.html'),
(604, 'OPEN', 45, 'Syntax:\nOPEN cursor_name\n\nThis statement opens a previously declared cursor. For an example, see\nhttps://dev.mysql.com/doc/refman/8.0/en/cursors.html.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/open.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/open.html'),
(605, 'DECLARE CONDITION', 45, 'Syntax:\nDECLARE condition_name CONDITION FOR condition_value\n\ncondition_value: {\n    mysql_error_code\n  | SQLSTATE [VALUE] sqlstate_value\n}\n\nThe DECLARE ... CONDITION statement declares a named error condition,\nassociating a name with a condition that needs specific handling. The\nname can be referred to in a subsequent DECLARE ... HANDLER statement\n(see [HELP DECLARE HANDLER]).\n\nCondition declarations must appear before cursor or handler\ndeclarations.\n\nThe condition_value for DECLARE ... CONDITION indicates the specific\ncondition or class of conditions to associate with the condition name.\nIt can take the following forms:\n\no mysql_error_code: An integer literal indicating a MySQL error code.\n\n  Do not use MySQL error code 0 because that indicates success rather\n  than an error condition. For a list of MySQL error codes, see Server\n  Error Message Reference\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html).\n\no SQLSTATE [VALUE] sqlstate_value: A 5-character string literal\n  indicating an SQLSTATE value.\n\n  Do not use SQLSTATE values that begin with \'00\' because those\n  indicate success rather than an error condition. For a list of\n  SQLSTATE values, see Server Error Message Reference\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html).\n\nCondition names referred to in SIGNAL or use RESIGNAL statements must\nbe associated with SQLSTATE values, not MySQL error codes.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/declare-condition.html\n\n', '', 'https://dev.mysql.com/doc/refman/8.0/en/declare-condition.html'),
(606, 'DECLARE HANDLER', 45, 'Syntax:\nDECLARE handler_action HANDLER\n    FOR condition_value [, condition_value] ...\n    statement\n\nhandler_action: {\n    CONTINUE\n  | EXIT\n  | UNDO\n}\n\ncondition_value: {\n    mysql_error_code\n  | SQLSTATE [VALUE] sqlstate_value\n  | condition_name\n  | SQLWARNING\n  | NOT FOUND\n  | SQLEXCEPTION\n}\n\nThe DECLARE ... HANDLER statement specifies a handler that deals with\none or more conditions. If one of these conditions occurs, the\nspecified statement executes. statement can be a simple statement such\nas SET var_name = value, or a compound statement written using BEGIN\nand END (see [HELP BEGIN END]).\n\nHandler declarations must appear after variable or condition\ndeclarations.\n\nThe handler_action value indicates what action the handler takes after\nexecution of the handler statement:\n\no CONTINUE: Execution of the current program continues.\n\no EXIT: Execution terminates for the BEGIN ... END compound statement\n  in which the handler is declared. This is true even if the condition\n  occurs in an inner block.\n\no UNDO: Not supported.\n\nThe condition_value for DECLARE ... HANDLER indicates the specific\ncondition or class of conditions that activates the handler. It can\ntake the following forms:\n\no mysql_error_code: An integer literal indicating a MySQL error code,\n  such as 1051 to specify \"unknown table\":\n\nDECLARE CONTINUE HANDLER FOR 1051\n  BEGIN\n    -- body of handler\n  END;\n\n  Do not use MySQL error code 0 because that indicates success rather\n  than an error condition. For a list of MySQL error codes, see Server\n  Error Message Reference\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html).\n\no SQLSTATE [VALUE] sqlstate_value: A 5-character string literal\n  indicating an SQLSTATE value, such as \'42S01\' to specify \"unknown\n  table\":\n\nDECLARE CONTINUE HANDLER FOR SQLSTATE \'42S02\'\n  BEGIN\n    -- body of handler\n  END;\n\n  Do not use SQLSTATE values that begin with \'00\' because those\n  indicate success rather than an error condition. For a list of\n  SQLSTATE values, see Server Error Message Reference\n  (https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference\n  .html).\n\no condition_name: A condition name previously specified with DECLARE\n  ... CONDITION. A condition name can be associated with a MySQL error\n  code or SQLSTATE value. See [HELP DECLARE CONDITION].\n\no SQLWARNING: Shorthand for the class of SQLSTATE values that begin\n  with \'01\'.\n\nDECLARE CONTINUE HANDLER FOR SQLWARNING\n  BEGIN\n    -- body of handler\n  END;\n\no NOT FOUND: Shorthand for the class of SQLSTATE values that begin with\n  \'02\'. This is relevant within the context of cursors and is used to\n  control what happens when a cursor reaches the end of a data set. If\n  no more rows are available, a No Data condition occurs with SQLSTATE\n  value \'02000\'. To detect this condition, you can set up a handler for\n  it or for a NOT FOUND condition.\n\nDECLARE CONTINUE HANDLER FOR NOT FOUND\n  BEGIN\n    -- body of handler\n  END;\n\n  For another example, see\n  https://dev.mysql.com/doc/refman/8.0/en/cursors.html. The NOT FOUND\n  condition also occurs for SELECT ... INTO var_list statements that\n  retrieve no rows.\n\no SQLEXCEPTION: Shorthand for the class of SQLSTATE values that do not\n  begin with \'00\', \'01\', or \'02\'.\n\nDECLARE CONTINUE HANDLER FOR SQLEXCEPTION\n  BEGIN\n    -- body of handler\n  END;\n\nFor information about how the server chooses handlers when a condition\noccurs, see https://dev.mysql.com/doc/refman/8.0/en/handler-scope.html.\n\nIf a condition occurs for which no handler has been declared, the\naction taken depends on the condition class:\n\no For SQLEXCEPTION conditions, the stored program terminates at the\n  statement that raised the condition, as if there were an EXIT\n  handler. If the program was called by another stored program, the\n  calling program handles the condition using the handler selection\n  rules applied to its own handlers.\n\no For SQLWARNING conditions, the program continues executing, as if\n  there were a CONTINUE handler.\n\no For NOT FOUND conditions, if the condition was raised normally, the\n  action is CONTINUE. If it was raised by SIGNAL or RESIGNAL, the\n  action is EXIT.\n\nURL: https://dev.mysql.com/doc/refman/8.0/en/declare-handler.html\n\n', 'mysql> CREATE TABLE test.t (s1 INT, PRIMARY KEY (s1));\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> delimiter //\n\nmysql> CREATE PROCEDURE handlerdemo ()\n       BEGIN\n         DECLARE CONTINUE HANDLER FOR SQLSTATE \'23000\' SET @x2 = 1;\n         SET @x = 1;\n         INSERT INTO test.t VALUES (1);\n         SET @x = 2;\n         INSERT INTO test.t VALUES (1);\n         SET @x = 3;\n       END;\n       //\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> CALL handlerdemo()//\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> SELECT @x//\n    +------+\n    | @x   |\n    +------+\n    | 3    |\n    +------+\n    1 row in set (0.00 sec)\n', 'https://dev.mysql.com/doc/refman/8.0/en/declare-handler.html'),
