Fix busted links

Author: rmloveland

src/current/v25.3/alter-table.md

@@ -1852,7 +1852,7 @@ Suppose that you are storing the data for users of your application in a table c
 );
 ~~~
 
-The primary key of this table is on the `name` column. This is a poor choice, as some users likely have the same name, and all primary keys enforce a `UNIQUE` constraint on row values of the primary key column. Per our [best practices]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#use-functions-to-generate-unique-ids), you should instead use a [`UUID`]({% link {{ page.version.version }}/uuid.md %}) for single-column primary keys, and populate the rows of the table with generated, unique values.
+The primary key of this table is on the `name` column. This is a poor choice, as some users likely have the same name, and all primary keys enforce a `UNIQUE` constraint on row values of the primary key column. Per our [best practices]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#use-functions-to-automatically-generate-unique-ids), you should instead use a [`UUID`]({% link {{ page.version.version }}/uuid.md %}) for single-column primary keys, and populate the rows of the table with generated, unique values.
 
 You can add a column and change the primary key with a couple of `ALTER TABLE` statements:
 

src/current/v25.3/liquibase.md

@@ -351,7 +351,7 @@ Suppose that you want to change the primary key of the `accounts` table from a s
     ALTER TABLE account ADD COLUMN unique_id UUID NOT NULL DEFAULT gen_random_uuid();
     ~~~
 
-    This statement adds [a new `unique_id` column]({% link {{ page.version.version }}/alter-table.md %}#add-column) to the `accounts` table, with the default value as [a randomly-generated UUID]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#use-functions-to-generate-unique-ids).
+    This statement adds [a new `unique_id` column]({% link {{ page.version.version }}/alter-table.md %}#add-column) to the `accounts` table, with the default value as [a randomly-generated UUID]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#use-functions-to-automatically-generate-unique-ids).
 
 1. In the `changelog-main.xml` file, add the following after the second `changeSet` element:
 

src/current/v25.3/performance-best-practices-overview.md

@@ -68,11 +68,11 @@ The best practices for generating unique IDs in a distributed database like Cock
 
 To create unique and non-sequential IDs, we recommend the following approaches (listed in order from best to worst performance):
 
-| Approach                                                                             | Pros                                             | Cons                                                                                    |
-|--------------------------------------------------------------------------------------+--------------------------------------------------+-----------------------------------------------------------------------------------------|
-| 1. [Use multi-column primary keys](#use-multi-column-primary-keys)                   | Potentially fastest, if done right               | Complex, requires up-front design and testing to ensure performance                     |
-| 2. [Use functions to generate unique IDs](#use-functions-to-generate-unique-ids)             | Good performance; spreads load well; easy choice | May leave some performance on the table; requires other columns to be useful in queries |
-| 3. [Use `INSERT` with the `RETURNING` clause](#use-insert-with-the-returning-clause-to-generate-unique-ids) | Easy to query against; familiar design           | Slower performance than the other options; higher chance of [transaction contention](#transaction-contention)      |
+| Approach                                                                                                    | Pros                                             | Cons                                                                                                          |
+|-------------------------------------------------------------------------------------------------------------+--------------------------------------------------+---------------------------------------------------------------------------------------------------------------|
+| 1. [Use multi-column primary keys](#use-multi-column-primary-keys)                                          | Potentially fastest, if done right               | Complex, requires up-front design and testing to ensure performance                                           |
+| 2. [Use functions to generate unique IDs](#use-functions-to-automatically-generate-unique-ids)              | Good performance; spreads load well; easy choice | May leave some performance on the table; requires other columns to be useful in queries                       |
+| 3. [Use `INSERT` with the `RETURNING` clause](#use-insert-with-the-returning-clause-to-generate-unique-ids) | Easy to query against; familiar design           | Slower performance than the other options; higher chance of [transaction contention](#transaction-contention) |
 
 Traditional approaches using monotonically increasing [`INT`]({% link {{ page.version.version }}/int.md %}) or [`SERIAL`]({% link {{ page.version.version }}/serial.md %}) data types will create [hotspots](#hotspots) for both reads and writes in a distributed database like CockroachDB. {% include {{page.version.version}}/performance/use-hash-sharded-indexes.md %}