From 222faa4346b92f608d2ee4628e41a546d180ef7a Mon Sep 17 00:00:00 2001 From: raymonder jin Date: Tue, 13 Dec 2022 22:50:52 +0800 Subject: [PATCH] docs: fix typos (#39870) --- br/COMPATIBILITY_TEST.md | 2 +- docs/design/2019-11-05-index-advisor.md | 2 +- docs/design/2020-01-24-collations.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/br/COMPATIBILITY_TEST.md b/br/COMPATIBILITY_TEST.md index b5580835baee8..44984ebcd2bfa 100644 --- a/br/COMPATIBILITY_TEST.md +++ b/br/COMPATIBILITY_TEST.md @@ -3,7 +3,7 @@ ## Background We had some incompatibility issues in the past, which made BR cannot restore backed up data in some situations. -So we need a test workflow to check the compatiblity. +So we need a test workflow to check the compatibility. ## Goal diff --git a/docs/design/2019-11-05-index-advisor.md b/docs/design/2019-11-05-index-advisor.md index 53abab5ba0d5a..5606d9bd9a942 100644 --- a/docs/design/2019-11-05-index-advisor.md +++ b/docs/design/2019-11-05-index-advisor.md @@ -57,7 +57,7 @@ for { Note that executing `Swap and Re-evaluate` algorithm is necessary as the `reduced_cost` sometimes is a joint effect of several indexes and it's hard to tell each index's independent contribution to the final `reduced_cost`. For example, assume there is an extremely slow query in input workload and the desired indexes for this query is `a` and `b`. However, the number of allowed recommended indexes for the whole workload is limited and for some reason, `a` ranks top `n` in the final score list while `b` is not. But there are chances that without `b`, `a` can no more optimize that extremely slow query. ---------------------------------------------- -### A quick exmaple for single-column index recommendation +### A quick example for single-column index recommendation **Workload**: diff --git a/docs/design/2020-01-24-collations.md b/docs/design/2020-01-24-collations.md index af7c9e30b2f26..d610514ed76d5 100644 --- a/docs/design/2020-01-24-collations.md +++ b/docs/design/2020-01-24-collations.md @@ -233,7 +233,7 @@ The following features of the general collation algorithm will be supported: * Tertiary Weight i.e. case * PAD / NOPAD -All of them are supported by `text/collate` package of Go, so it is possible to map Go collations to some of UCA-based collations in MySQL like `utf8mb4_unicode_ci`/`utf8mb4_0900_ai_ci`, if we ignore the differences between UCA versions: current `text/collate` uses UCA version `6.2.0` and it is not changable. However, the collations in MySQL are with different UCA versions marked in the names, for example, `utf8mb4_0900_ai_ci` uses version `9.0`. +All of them are supported by `text/collate` package of Go, so it is possible to map Go collations to some of UCA-based collations in MySQL like `utf8mb4_unicode_ci`/`utf8mb4_0900_ai_ci`, if we ignore the differences between UCA versions: current `text/collate` uses UCA version `6.2.0` and it is not changeable. However, the collations in MySQL are with different UCA versions marked in the names, for example, `utf8mb4_0900_ai_ci` uses version `9.0`. For non-standard UCA implementations in MySQL, i.e. the `utf8mb4_general_ci`. The implementation depends on our choice to the [Compatibility with MySQL](#compatibility-with-mysql) chapter, if a 100% compatibility of `utf8mb4_general_ci` is chosen, we need to implement it by our hands.