From b4bc0f1406359a5963c41a28275930653eed0c69 Mon Sep 17 00:00:00 2001 From: spencerkee Date: Sun, 1 Nov 2020 21:52:17 -0500 Subject: [PATCH] cherry pick #4117 to release-3.1 Signed-off-by: ti-srebot --- auto-random.md | 46 +++++- ...up-and-restore-using-dumpling-lightning.md | 86 +++++++++++ ...up-and-restore-using-mydumper-lightning.md | 4 +- basic-sql-operations.md | 6 +- blocklist-control-plan.md | 16 +- character-set-and-collation.md | 143 ++++++++++++++++++ 6 files changed, 284 insertions(+), 17 deletions(-) create mode 100644 backup-and-restore-using-dumpling-lightning.md diff --git a/auto-random.md b/auto-random.md index 60dfb0d657c60..509b2ed70a315 100644 --- a/auto-random.md +++ b/auto-random.md @@ -21,7 +21,11 @@ Take the following created table as an example: {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int primary key auto_increment, b varchar(255)) +======= +CREATE TABLE t (a bigint PRIMARY KEY AUTO_INCREMENT, b varchar(255)) +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` On this `t` table, you execute a large number of `INSERT` statements that do not specify the values of the primary key as below: @@ -29,7 +33,7 @@ On this `t` table, you execute a large number of `INSERT` statements that do not {{< copyable "sql" >}} ```sql -insert into t(b) values ('a'), ('b'), ('c') +INSERT INTO t(b) VALUES ('a'), ('b'), ('c') ``` In the above statement, values of the primary key (column `a`) are not specified, so TiDB uses the continuous auto-increment row values as the row IDs, which might cause write hotspot in a single TiKV node and affect the performance. To avoid such performance decrease, you can specify the `AUTO_RANDOM` attribute rather than the `AUTO_INCREMENT` attribute for the column `a` when you create the table. See the follow examples: @@ -37,7 +41,11 @@ In the above statement, values of the primary key (column `a`) are not specified {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int primary key auto_random, b varchar(255)) +======= +CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM, b varchar(255)) +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` or @@ -45,10 +53,20 @@ or {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int auto_random, b varchar(255), primary key (a)) ``` Then execute the `INSERT` statement such as `INSERT INTO t(b) values...`. Now the results will be as follows: +======= +CREATE TABLE t (a bigint AUTO_RANDOM, b varchar(255), PRIMARY KEY (a)) +``` + +Then execute the `INSERT` statement such as `INSERT INTO t(b) VALUES...`. Now the results will be as follows: + ++ Implicitly allocating values: If the `INSERT` statement does not specify the values of the integer primary key column (column `a`) or specify the value as `NULL`, TiDB automatically allocates values to this column. These values are not necessarily auto-increment or continuous but are unique, which avoids the hotspot problem caused by continuous row IDs. ++ Explicitly inserting values: If the `INSERT` statement explicitly specifies the values of the integer primary key column, TiDB saves these values, which works similarly to the `AUTO_INCREMENT` attribute. Note that if you do not set `NO_AUTO_VALUE_ON_ZERO` in the `@@sql_mode` system variable, TiDB will automatically allocate values to this column even if you explicitly specify the value of the integer primary key column as `0`. +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) + If the `INSERT` statement does not specify the values of the integer primary key column (column `a`) or specify the value as `NULL`, TiDB automatically assigns values to this column. These values are not necessarily auto-increment or continuous but are unique, which avoids the hotspot problem caused by continuous row IDs. + If the `INSERT` statement explicitly specifies the values of the integer primary key column, TiDB saves these values, which works similarly to the `AUTO_INCREMENT` attribute. Note that if you do not set `NO_AUTO_VALUE_ON_ZERO` in the `@@sql_mode` system variable, TiDB will automatically assign values to this column even if you explicitly specify the value of the integer primary key column as `0`. @@ -62,7 +80,11 @@ To use different number of shard bits, append a pair of parentheses to `AUTO_RAN {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int primary key auto_random(3), b varchar(255)) +======= +CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM(3), b varchar(255)) +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` In the above `CREATE TABLE` statement, `3` shard bits are specified. The range of the number of shard bits is `[1, field_max_bits)`. `field_max_bits` is the length of bits occupied by the primary key column. @@ -72,7 +94,7 @@ After creating the table, use the `SHOW WARNINGS` statement to see the maximum n {{< copyable "sql" >}} ```sql -show warnings +SHOW WARNINGS ``` ``` @@ -85,14 +107,18 @@ show warnings In addition, for tables with the `AUTO_RANDOM` attribute, the value of the corresponding `TIDB_ROW_ID_SHARDING_INFO` column in the `information_schema.tables` system table is `PK_AUTO_RANDOM_BITS=x`. `x` is the number of shard bits. +<<<<<<< HEAD You can use `select last_insert_id ()` to see the last implicit ID assigned by TiDB. For example: +======= +Values allocated to the `AUTO_RANDOM` column affect `last_insert_id()`. You can use `SELECT last_insert_id ()` to get the ID that TiDB last implicitly allocates. For example: +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) {{< copyable "sql" >}} ```sql -insert into t (b) values ("b") -select * from t; -select last_insert_id() +INSERT INTO t (b) VALUES ("b") +SELECT * FROM t; +SELECT last_insert_id() ``` You might see the following result: @@ -117,18 +143,26 @@ TiDB supports parsing the version comment syntax. See the following example: {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int primary key /*T![auto_rand] auto_random */) +======= +CREATE TABLE t (a bigint PRIMARY KEY /*T![auto_rand] auto_random */) +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` {{< copyable "sql" >}} ```sql +<<<<<<< HEAD create table t (a int primary key auto_random) +======= +CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM) +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` The above two statements have the same meaning. -In the result of `show create table`, the `AUTO_RANDOM` attribute is commented out. This comment includes an attribute identifier (for example, `/*T![auto_rand] auto_random */`). Here `auto_rand` represents the `AUTO_RANDOM` attribute. Only the version of TiDB that implements the feature corresponding to this identifier can parse the SQL statement fragment properly. +In the result of `SHOW CREATE TABLE`, the `AUTO_RANDOM` attribute is commented out. This comment includes an attribute identifier (for example, `/*T![auto_rand] auto_random */`). Here `auto_rand` represents the `AUTO_RANDOM` attribute. Only the version of TiDB that implements the feature corresponding to this identifier can parse the SQL statement fragment properly. This attribute supports forward compatibility, namely, downgrade compatibility. TiDB of earlier versions that do not implement this feature ignore the `AUTO_RANDOM` attribute of a table (with the above comment) and can also use the table with the attribute. diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md new file mode 100644 index 0000000000000..2159ef7ced61e --- /dev/null +++ b/backup-and-restore-using-dumpling-lightning.md @@ -0,0 +1,86 @@ +--- +title: Use Dumpling and TiDB Lightning for Data Backup and Restoration +summary: Introduce how to use Dumpling and TiDB Lightning to backup and restore full data of TiDB. +aliases: ['/docs/dev/export-or-backup-using-dumpling/','/tidb/dev/export-or-backup-using-dumpling'] +--- + +# Use Dumpling and TiDB Lightning for Data Backup and Restoration + +This document introduces in detail how to use Dumpling and TiDB Lightning to backup and restore full data of TiDB. For incremental backup and replication to downstream, refer to [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md). + +Suppose that the TiDB server information is as follows: + +|Server Name|Server Address|Port|User|Password| +|----|-------|----|----|--------| +|TiDB|127.0.0.1|4000|root|*| + +Use the following tools for data backup and restoration: + +- [Dumpling](/dumpling-overview.md): to export data from TiDB +- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md): to import data into TiDB + +## Best practices for full backup and restoration using Dumpling/TiDB Lightning + +To quickly backup and restore data (especially large amounts of data), refer to the following recommendations: + +* Keep the exported data file as small as possible. It is recommended to use the `-F` option of Dumpling to set the file size. If you use TiDB Lightning to restore data, it is recommended that you set the value of `-F` to `256m`. +* If some of the exported tables have many rows, you can enable concurrency in the table by setting the `-r` option. + +## Backup data from TiDB + +Use the following `dumpling` command to backup data from TiDB. + +{{< copyable "shell-regular" >}} + +```bash +./bin/dumpling -h 127.0.0.1 -P 4000 -u root -t 32 -F 256m -T test.t1 -T test.t2 -o ./var/test +``` + +In this command: + +- `-T test.t1 -T test.t2` means that only the two tables `test`.`t1` and `test`.`t2` are exported. For more methods to filter exported data, refer to [Filter exported data](/dumpling-overview.md#filter-the-exported-data). +- `-t 32` means that 32 threads are used to export the data. +- `-F 256m` means that a table is partitioned into chunks, and one chunk is 256MB. + +Starting from v4.0.0, Dumpling can automatically extends the GC time if it can access the PD address of the TiDB cluster. But for TiDB earlier than v4.0.0, you need to manually modify the GC time. Otherwise, you might bump into the following error: + +```log +Could not read data from testSchema.testTable: GC life time is shorter than transaction duration, transaction starts at 2019-08-05 21:10:01.451 +0800 CST, GC safe point is 2019-08-05 21:14:53.801 +0800 CST +``` + +The steps to manually modify the GC time are as follows: + +1. Before executing the `dumpling` command, query the [GC](/garbage-collection-overview.md) value of the TiDB cluster and execute the following statement in the MySQL client to adjust it to a suitable value: + + {{< copyable "sql" >}} + + ```sql + SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + ``` + + ```sql + +-----------------------+------------------------------------------------------------------------------------------------+ + | VARIABLE_NAME | VARIABLE_VALUE | + +-----------------------+------------------------------------------------------------------------------------------------+ + | tikv_gc_life_time | 10m0s | + +-----------------------+------------------------------------------------------------------------------------------------+ + 1 rows in set (0.02 sec) + ``` + + {{< copyable "sql" >}} + + ```sql + UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + ``` + +2. After executing the `dumpling` command, restore the GC value of the TiDB cluster to the initial value in step 1: + + {{< copyable "sql" >}} + + ```sql + UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + ``` + +## Restore data into TiDB + +To restore data into TiDB, use TiDB Lightning to import the exported data. See [TiDB Lightning Tutorial](/tidb-lightning/tidb-lightning-backends.md). diff --git a/backup-and-restore-using-mydumper-lightning.md b/backup-and-restore-using-mydumper-lightning.md index 577035fa7c9cc..cd74c21ac2820 100644 --- a/backup-and-restore-using-mydumper-lightning.md +++ b/backup-and-restore-using-mydumper-lightning.md @@ -80,7 +80,7 @@ Then execute two more commands: {{< copyable "sql" >}} ```sql - update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time'; + UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; ``` 2. After running the `mydumper` command, adjust GC value of the TiDB cluster to its original value in step 1. @@ -88,7 +88,7 @@ Then execute two more commands: {{< copyable "sql" >}} ```sql - update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time'; + UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; ``` ## Restore data into TiDB diff --git a/basic-sql-operations.md b/basic-sql-operations.md index e862d37541347..231f6993d4db1 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -49,7 +49,11 @@ To delete a database, use the `DROP DATABASE` statement: {{< copyable "sql" >}} ```sql +<<<<<<< HEAD DROP DATABASE samp_db; +======= +USE mysql; +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ``` ## Create, show, and drop a table @@ -175,7 +179,7 @@ To show all the indexes in a table, use the `SHOW INDEX` statement: {{< copyable "sql" >}} ```sql -SHOW INDEX from person; +SHOW INDEX FROM person; ``` ### Delete an index diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 27b1c6507c5b7..199cf93f00a8a 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -42,7 +42,7 @@ You can use the blocklist of optimization rules to disable some of them if some {{< copyable "sql" >}} ```sql - insert into mysql.opt_rule_blacklist values("join_reorder"), ("topn_push_down"); + INSERT INTO mysql.opt_rule_blacklist VALUES("join_reorder"), ("topn_push_down"); ``` Executing the following SQL statement can make the above operation take effect immediately. The effective range includes all old connections of the corresponding TiDB server: @@ -62,7 +62,7 @@ You can use the blocklist of optimization rules to disable some of them if some {{< copyable "sql" >}} ```sql - delete from mysql.opt_rule_blacklist where name in ("join_reorder", "topn_push_down"); + DELETE FROM mysql.opt_rule_blacklist WHERE name IN ("join_reorder", "topn_push_down"); ``` {{< copyable "sql" >}} @@ -95,7 +95,7 @@ The schema of `mysql.expr_pushdown_blacklist` is shown as follows: {{< copyable "sql" >}} ```sql -desc mysql.expr_pushdown_blacklist; +DESC mysql.expr_pushdown_blacklist; ``` ```sql @@ -153,7 +153,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S {{< copyable "sql" >}} ```sql - explain select * from t where a < 2 and a > 2; + EXPLAIN SELECT * FROM t WHERE a < 2 AND a > 2; ``` ```sql @@ -172,7 +172,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S {{< copyable "sql" >}} ```sql - insert into mysql.expr_pushdown_blacklist values('<','tikv',''), ('>','tikv',''); + INSERT INTO mysql.expr_pushdown_blacklist VALUES('<','tikv',''), ('>','tikv',''); ``` ```sql @@ -195,7 +195,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S {{< copyable "sql" >}} ```sql - explain select * from t where a < 2 and a > 2; + EXPLAIN SELECT * FROM t WHERE a < 2 and a > 2; ``` ```sql @@ -214,7 +214,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S {{< copyable "sql" >}} ```sql - delete from mysql.expr_pushdown_blacklist where name = '>'; + DELETE FROM mysql.expr_pushdown_blacklist WHERE name = '>'; ``` ```sql @@ -236,7 +236,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S {{< copyable "sql" >}} ```sql - explain select * from t where a < 2 and a > 2; + EXPLAIN SELECT * FROM t WHERE a < 2 AND a > 2; ``` ```sql diff --git a/character-set-and-collation.md b/character-set-and-collation.md index 15399a9a8a105..a10c291344bcd 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -110,13 +110,31 @@ ALTER DATABASE db_name `DATABASE` can be replaced with `SCHEMA` here. +<<<<<<< HEAD Different databases can use different character sets and collations. Use the `character_set_database` and `collation_database` to see the character set and collation of the current database: +======= +Different databases can use different character sets and collations. Use the `character_set_database` and `collation_database` to see the character set and collation of the current database: + +{{< copyable "sql" >}} + +```sql +CREATE SCHEMA test1 CHARACTER SET utf8mb4 COLLATE uft8mb4_general_ci; +``` +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) ```sql mysql> create schema test1 character set utf8 COLLATE uft8_general_ci; Query OK, 0 rows affected (0.09 sec) +<<<<<<< HEAD mysql> use test1; +======= +```sql +USE test1; +``` + +```sql +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) Database changed mysql> SELECT @@character_set_database, @@collation_database; +--------------------------|----------------------+ @@ -126,8 +144,24 @@ mysql> SELECT @@character_set_database, @@collation_database; +--------------------------|----------------------+ 1 row in set (0.00 sec) +<<<<<<< HEAD mysql> create schema test2 character set latin1 COLLATE latin1_general_ci; Query OK, 0 rows affected (0.09 sec) +======= +```sql +CREATE SCHEMA test2 CHARACTER SET latin1 COLLATE latin1_bin; +``` + +```sql +Query OK, 0 rows affected (0.09 sec) +``` + +{{< copyable "sql" >}} + +```sql +USE test2; +``` +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117) mysql> use test2; Database changed @@ -258,4 +292,113 @@ For the specified `utf8` or `utf8mb4` character set, TiDB only supports the vali To disable this error reporting, use `set @@tidb_skip_utf8_check=1;` to skip the character check. +<<<<<<< HEAD For more information, see [Connection Character Sets and Collations in MySQL](https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html). +======= +## Collation support framework + +The syntax support and semantic support for the collation are influenced by the [`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) configuration item. The syntax support and semantic support are different. The former indicates that TiDB can parse and set collations. The latter indicates that TiDB can correctly use collations when comparing strings. + +Before v4.0, TiDB provides only the [old framework for collations](#old-framework-for-collations). In this framework, TiDB supports syntactically parsing most of the MySQL collations but semantically takes all collations as binary collations. + +Since v4.0, TiDB supports a [new framework for collations](#new-framework-for-collations). In this framework, TiDB semantically parses different collations and strictly follows the collations when comparing strings. + +### Old framework for collations + +Before v4.0, you can specify most of the MySQL collations in TiDB, and these collations are processed according to the default collations, which means that the byte order determines the character order. Different from MySQL, TiDB deletes the space at the end of the character according to the `PADDING` attribute of the collation before comparing characters, which causes the following behavior differences: + +{{< copyable "sql" >}} + +```sql +CREATE TABLE t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci PRIMARY KEY); +Query OK, 0 rows affected +INSERT INTO t VALUES ('A'); +Query OK, 1 row affected +INSERT INTO t VALUES ('a'); +Query OK, 1 row affected # In TiDB, it is successfully executed. In MySQL, because utf8mb4_general_ci is case-insensitive, the `Duplicate entry 'a'` error is reported. +INSERT INTO t1 VALUES ('a '); +Query OK, 1 row affected # In TiDB, it is successfully executed. In MySQL, because comparison is performed after the spaces are filled in, the `Duplicate entry 'a '` error is returned. +``` + +### New framework for collations + +In TiDB 4.0, a complete framework for collations is introduced. This new framework supports semantically parsing collations and introduces the `new_collations_enabled_on_first_bootstrap` configuration item to decide whether to enable the new framework when a cluster is first initialized. If you initialize the cluster after the configuration item is enabled, you can check whether the new collation is enabled through the `new_collation_enabled` variable in the `mysql`.`tidb` table: + +{{< copyable "sql" >}} + +```sql +SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled'; +``` + +```sql ++----------------+ +| VARIABLE_VALUE | ++----------------+ +| True | ++----------------+ +1 row in set (0.00 sec) +``` + +Under the new framework, TiDB support the `utf8_general_ci`, `utf8mb4_general_ci`, `utf8_unicode_ci`, and `utf8mb4_unicode_ci` collations which are compatible with MySQL. + +When one of `utf8_general_ci`, `utf8mb4_general_ci`, `utf8_unicode_ci`, and `utf8mb4_unicode_ci` is used, the string comparison is case-insensitive and accent-insensitive. At the same time, TiDB also corrects the collation's `PADDING` behavior: + +{{< copyable "sql" >}} + +```sql +CREATE TABLE t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci PRIMARY KEY); +Query OK, 0 rows affected (0.00 sec) +INSERT INTO t VALUES ('A'); +Query OK, 1 row affected (0.00 sec) +INSERT INTO t VALUES ('a'); +ERROR 1062 (23000): Duplicate entry 'a' for key 'PRIMARY' # TiDB is compatible with the case-insensitive collation of MySQL. +INSERT INTO t VALUES ('a '); +ERROR 1062 (23000): Duplicate entry 'a ' for key 'PRIMARY' # TiDB modifies the `PADDING` behavior to be compatible with MySQL. +``` + +> **Note:** +> +> The implementation of padding in TiDB is different from that in MySQL. In MySQL, padding is implemented by filling in spaces. In TiDB, padding is implemented by cutting out the spaces at the end. The two approaches are the same in most cases. The only exception is when the end of the string contains characters that are less than spaces (0x20). For example, the result of `'a' < 'a\t'` in TiDB is `1`, but in MySQL, `'a' < 'a\t'` is equivalent to `'a ' < 'a\t'`, and the result is `0`. + +## Coercibility values of collations in expressions + +If an expression involves multiple clauses of different collations, you need to infer the collation used in the calculation. The rules are as follows: + ++ The coercibility value of the explicit `COLLATE` clause is `0`. ++ If the collations of two strings are incompatible, the coercibility value of the concatenation of two strings with different collations is `1`. ++ The collation of the column, `CAST()`, `CONVERT()`, or `BINARY()` has a coercibility value of `2`. ++ The system constant (the string returned by `USER ()` or `VERSION ()`) has a coercibility value of `3`. ++ The coercibility value of constants is `4`. ++ The coercibility value of numbers or intermediate variables is `5`. ++ `NULL` or expressions derived from `NULL` has a coercibility value of `6`. + +When inferring collations, TiDB prefers using the collation of expressions with lower coercibility values. If the coercibility values of two clauses are the same, the collation is determined according to the following priority: + +binary > utf8mb4_bin > (utf8mb4_general_ci = utf8mb4_unicode_ci) > utf8_bin > (utf8_general_ci = utf8_unicode_ci) > latin1_bin > ascii_bin + +TiDB cannot infer the collation and reports an error in the following situations: + +- If the collations of two clauses are different and the coercibility value of both clauses is `0`. +- If the collations of two clauses are incompatible and the returned type of expression is `String`. + +## `COLLATE` clause + +TiDB supports using the `COLLATE` clause to specify the collation of an expression. The coercibility value of this expression is `0`, which has the highest priority. See the following example: + +{{< copyable "sql" >}} + +```sql +SELECT 'a' = _utf8mb4 'A' collate utf8mb4_general_ci; +``` + +```sql ++-----------------------------------------------+ +| 'a' = _utf8mb4 'A' collate utf8mb4_general_ci | ++-----------------------------------------------+ +| 1 | ++-----------------------------------------------+ +1 row in set (0.00 sec) +``` + +For more details, see [Connection Character Sets and Collations](https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html). +>>>>>>> 8595ca53... Capitalize sql keywords in several files (#4117)