Skip to content

faq, sql-statements: update out of date info (#3418) #3438

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 29, 2020
Merged

faq, sql-statements: update out of date info (#3418) #3438

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
46f3ab4
cherry pick #3418 to release-2.1
Jul 28, 2020
67766cb
Delete sql-faq.md
Jul 28, 2020
863231e
Update tidb-faq.md
Jul 28, 2020
cc90407
Update tidb-faq.md
Jul 28, 2020
8ca7760
Update tidb-faq.md
Jul 28, 2020
1edf94b
Merge branch 'release-2.1' into release-2.1-d4f13c983c02
ti-srebot Jul 29, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions faq/tidb-faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,9 +76,11 @@ Currently, [TiDB documentation](https://pingcap.com/docs/) is the most important

See [The System Variables](/system-variables.md).

#### Does TiDB support `select for update`?
#### Does TiDB support `SELECT FOR UPDATE`?

Yes. But it differs from MySQL in syntax. As a distributed database, TiDB uses the optimistic lock. `select for update` does not lock data when the transaction is started, but checks conflicts when the transaction is committed. If the check reveals conflicts, the committing transaction rolls back.
Yes. By default TIDB 2.1 uses optimistic locking, and `SELECT FOR UPDATE` does not lock data when the transaction is started. A check for conflicts occurs when the transaction is committed. If the check reveals conflicts, the committing transaction rolls back.

The default changes to pessimistic locking in TiDB 3.0, where `SELECT FOR UPDATE` execution behaves similar to MySQL.

#### Can the codec of TiDB guarantee that the UTF-8 string is memcomparable? Is there any coding suggestion if our key needs to support UTF-8?

Expand Down Expand Up @@ -117,9 +119,9 @@ It is recommended to use the official standard statements when modifying the use

The auto-increment ID feature in TiDB is only guaranteed to be automatically incremental and unique but is not guaranteed to be allocated sequentially. Currently, TiDB is allocating IDs in batches. If data is inserted into multiple TiDB servers simultaneously, the allocated IDs are not sequential. When multiple threads concurrently insert data to multiple `tidb-server` instances, the auto-increment ID of the later inserted data may be smaller. TiDB allows specifying `AUTO_INCREMENT` for the integer field, but allows only one `AUTO_INCREMENT` field in a single table. For details, see [MySQL Compatibility](/mysql-compatibility.md#auto-increment-id).

#### How to modify the `sql_mode` in TiDB except using the `set` command?
#### How do I modify the `sql_mode` in TiDB?

The configuration method of TiDB `sql_mode` is different from that of MySQL `sql_mode`. TiDB does not support using the configuration file to configure `sql\_mode` of the database; it only supports using the `set` command to configure `sql\_mode` of the database. You can use `set @@global.sql_mode = 'STRICT_TRANS_TABLES';` to configure it.
TiDB supports modifying the `sql_mode` as a [system variable](/system-variables.md), as in MySQL. Currently, TiDB does not permit modifying the sql mode in a configuration file, but system variable changes made with [`SET GLOBAL`](/sql-statements/sql-statement-set-variable.md) propagate to all TiDB servers in the cluster and persist across restarts.

#### Does TiDB support modifying the MySQL version string of the server to a specific one that is required by the security vulnerability scanning tool?

Expand Down Expand Up @@ -582,9 +584,9 @@ Trigger strategy: `auto analyze` is automatically triggered when the number of p

When the modified number or the current total row number is larger than `tidb_auto_analyze_ratio`, the `analyze` statement is automatically triggered. The default value of `tidb_auto_analyze_ratio` is 0.5, indicating that this feature is enabled by default. To ensure safety, its minimum value is 0.3 when the feature is enabled, and it must be smaller than `pseudo-estimate-ratio` whose default value is 0.8, otherwise pseudo statistics will be used for a period of time. It is recommended to set `tidb_auto_analyze_ratio` to 0.5.

#### How to use a specific index with hint in a SQL statement?
#### Can I use hints to override the optimizer behavior?

Its usage is similar to MySQL:
TiDB supports multiple [hints](/optimizer-hints.md) to override the default query optimizer behavior. The basic usage is similar to MySQL, with several TiDB specific extensions:

{{< copyable "sql" >}}

Expand Down
6 changes: 5 additions & 1 deletion sql-statements/sql-statement-set-variable.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,11 @@ mysql> SHOW SESSION VARIABLES LIKE 'sql_mode';

## MySQL compatibility

This statement is understood to be fully compatible with MySQL. Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub.
The following behavior differences apply:

* Changes made with `SET GLOBAL` will be propagated to all TiDB instances in the cluster. This differs from MySQL, where changes do not propagate to replicas.
* TiDB presents several variables as both readable and settable. This is required for MySQL compatibility, because it is common for both applications and connectors to read MySQL variables. For example: JDBC connectors both read and set query cache settings, despite not relying on the behavior.
* Changes made with `SET GLOBAL` will persist through TiDB server restarts. This means that `SET GLOBAL` in TiDB behaves more similar to `SET PERSIST` as available in MySQL 8.0 and above.

## See also

Expand Down