docs: fix broken links in CHANGELOG and design docs (pingcap#26043)

CHANGELOG.md

@@ -959,12 +959,12 @@ Enable hash partition by default; and enable range columns partition when there
     - Control whether to open the `general log`
     - Support modifying the log level online
     - Check the TiDB cluster information
-* [Add the `auto_analyze_ratio` system variables to contorl the ratio of Analyze](https://pingcap.com/docs/FAQ/#whats-the-trigger-strategy-for-auto-analyze-in-tidb)
-* [Add the `tidb_retry_limit` system variable to control the automatic retry times of transactions](https://pingcap.com/docs/sql/tidb-specific/#tidb-retry-limit)
-* [Add the `tidb_disable_txn_auto_retry` system variable to control whether the transaction retries automatically](https://pingcap.com/docs/sql/tidb-specific/#tidb-disable-txn-auto-retry)
-* [Support using `admin show slow` statement to obtain the slow queries ](https://pingcap.com/docs/sql/slow-query/#admin-show-slow-command)
-* [Add the `tidb_slow_log_threshold` environment variable to set the threshold of slow log automatically](https://pingcap.com/docs/sql/tidb-specific/#tidb_slow_log_threshold) 
-* [Add the `tidb_query_log_max_len` environment variable to set the length of the SQL statement to be truncated in the log dynamically](https://pingcap.com/docs/sql/tidb-specific/#tidb_query_log_max_len)
+* [Add the `auto_analyze_ratio` system variables to contorl the ratio of Analyze](https://docs.pingcap.com/tidb/stable/sql-faq#whats-the-trigger-strategy-for-auto-analyze-in-tidb)
+* [Add the `tidb_retry_limit` system variable to control the automatic retry times of transactions](https://docs.pingcap.com/tidb/stable/system-variables#tidb_retry_limit)
+* [Add the `tidb_disable_txn_auto_retry` system variable to control whether the transaction retries automatically](https://docs.pingcap.com/tidb/stable/system-variables/#tidb_disable_txn_auto_retry)
+* [Support using `admin show slow` statement to obtain the slow queries ](https://docs.pingcap.com/tidb/stable/identify-slow-queries/#admin-show-slow-command)
+* [Add the `tidb_slow_log_threshold` environment variable to set the threshold of slow log automatically](https://docs.pingcap.com/tidb/stable/system-variables#tidb_slow_log_threshold) 
+* [Add the `tidb_query_log_max_len` environment variable to set the length of the SQL statement to be truncated in the log dynamically](https://docs.pingcap.com/tidb/stable/system-variables#tidb_query_log_max_len)
 
 ### DDL
 * Support the parallel execution of the add index statement and other statements to avoid the time consuming add index operation blocking other operations

docs/design/2018-09-21-radix-hashjoin.md

@@ -11,7 +11,7 @@ This proposal proposes to implement radix hash join in TiDB, aimed to improve th
 
 Currently, TiDB uses `non-partitioning hash join` to implement `HashJoinExec`. This algorithm starts by building a **single global hash table** for the inner relation which is known as the `build phase`. After the hash table is built, `probe phase` assigns equal-sized sub-relations (chunks) of the outer relation to multiple threads to probe against the global hash table simultaneously.
 
-[Shatdal et al.](http://www.inf.uni-konstanz.de/dbis/teaching/ws0203/main-memory-dbms/download/CCA.pdf) identify that when the hash table is larger than the cache size, almost every access to the
+[Shatdal et al.](https://web.archive.org/web/20180417031602/http://www.inf.uni-konstanz.de/dbis/teaching/ws0203/main-memory-dbms/download/CCA.pdf) identify that when the hash table is larger than the cache size, almost every access to the
 hash table results in a cache miss. So the `build phase` and `probe phase` of `non-partitioning hash join` might cause considerable cache miss when writing or reading the single global hash table.
 
 Partitioning the hash table into cache-sized chunks can reduce cache misses and improve performance, `partition-based hash join` introduces the `partition phase ` for hash join. `Partition phase` partitions the input relations into small pairs of partitions where one of the partitions typically **fits into one of the CPU caches**. During the `build phase`, a **separate hash table** is built for each partition respectively. During the `probe phase`, a sub-partition of outer relation will only be probed against the corresponding hash table which can be totally stored in the CPU cache.

docs/design/2019-01-25-skyline-pruning.md

@@ -41,4 +41,4 @@ Since we need to decide whether the access path matches the physical property, w
 
 ## References
 
-- [The Skyline Operator](http://skylineresearch.in/skylineintro/The_Skyline_Operator.pdf)
+- [The Skyline Operator](https://www.cse.ust.hk/~dimitris/PAPERS/SIGMOD03-Skyline.pdf)

docs/design/2020-01-24-collations.md

@@ -23,7 +23,7 @@ In MySQL, collation is treated as an attribute of the character set: for each ch
   * It defines a total order on all characters of a character set.
   * It determines if padding is applied when comparing two strings.
   * It describes comparisons of logically identical but physically different byte sequences.
-Some examples of the effects of collation can be found in [this part](https://dev.mysql.com/doc/refman/8.0/en/charset-collation-effect.html) of the MySQL Manual and [this webpage](http://demo.icu-project.org/icu-bin/locexp?_=en_US&x=col).
+Some examples of the effects of collation can be found in [this part](https://dev.mysql.com/doc/refman/8.0/en/charset-collation-effect.html) of the MySQL Manual and [this webpage](https://web.archive.org/web/20171030065123/http://demo.icu-project.org/icu-bin/locexp?_=en_US&x=col).
 
 Several collation implementations are described in [this part](https://dev.mysql.com/doc/refman/8.0/en/charset-collation-implementations.html) of MySQL Manual: