update links

Author: Blargian

knowledgebase/memory-limit-exceeded-for-query.mdx

@@ -38,7 +38,7 @@ help ensure queries do not OOM. The latter sorting setting helps address similar
 issues with memory-intensive sorts. This can be particularly important in
 distributed environments where a coordinating node receives sorted responses
 from child shards. In this case, the coordinating server can be asked to sort a
-dataset larger than its available memory. With [`max_bytes_before_external_sort`](/sql-reference/statements/select/order-by/#implementation-details),
+dataset larger than its available memory. With [`max_bytes_before_external_sort`](/operations/settings/settings#max_bytes_before_external_group_by),
 sorting can be allowed to spill over to disk. This setting is also helpful for
 cases where the user has an `ORDER BY` after a `GROUP BY` with a `LIMIT`,
 especially in cases where the query is distributed.
@@ -52,7 +52,7 @@ This algorithm loads the right-hand table of the `JOIN` into an in-memory hash
 table, against which the left-hand table is then evaluated. To minimize memory,
 users should thus place the smaller table on the right side. This approach still
 has limitations in memory-bound cases, however. In these cases, `partial_merge`
-join can be enabled via the [`join_algorithm`](/operations/settings/settings#settings-join_algorithm)
+join can be enabled via the [`join_algorithm`](/operations/settings/settings#join_algorithm)
 setting. This derivative of the [sort-merge algorithm](https://en.wikipedia.org/wiki/Sort-merge_join),
 first sorts the right table into blocks and creates a min-max index for them.
 It then sorts parts of the left table by the join key and joins them over the