Added Known issues, recommended MVU approach and minor change to release notes

Author: hariramt

articles/mysql/flexible-server/how-to-upgrade-faq.md

@@ -66,6 +66,32 @@ Until the upstream fix is available, take the following precautions before and a
 - Set the session or server `time_zone` explicitly, and write datetime values without an inline offset so the server applies the configured timezone consistently.
 - Validate a representative sample of newly inserted rows after the upgrade to confirm that stored values match the expected values.
 
+### Performance regression for IN() queries on indexed string columns after upgrading to 8.4
+
+In MySQL 8.4, a query that uses an `IN()` predicate on an indexed non-binary string column (for example, `VARCHAR` with a `utf8mb4` or `utf8mb3` non-binary collation such as `utf8mb4_0900_ai_ci`) can deteriorate to a full table or index scan when at least one value in the `IN()` list is longer than the column's defined length, or longer than a prefix index's defined length. Queries that previously used efficient index range scans on the same data in MySQL 5.7 or 8.0 might experience performance degradation after upgrading to 8.4.
+
+This is a known MySQL community bug. For more information, see [MySQL Bug #118009](https://bugs.mysql.com/bug.php?id=118009).
+
+#### Resolution
+
+Until the fix is available on Azure Database for MySQL Flexible Server, use one or more of the following mitigations:
+
+- Audit application queries that use `IN()` on indexed string columns, and filter or truncate values on the application side so that none of the values exceed the column's defined length (or the prefix index length).
+- For affected queries, split the `IN()` list into multiple shorter `IN()` lists or `OR` conditions that exclude oversized values, so the optimizer can continue to use index range scans.
+- Use binary collations (for example, `utf8mb4_bin`) or the `latin1` character set for affected columns, because these collations aren't impacted by this regression. Evaluate the change against your application's sorting and comparison requirements before adopting it.
+- Review query plans by using `EXPLAIN` after the upgrade to identify queries that have switched from `range` to `ALL` or `index` access, and prioritize them for mitigation.
+
+### Slowness or high CPU usage for SELECT queries with very large IN() lists after upgrading to 8.0 or 8.4
+
+After upgrading to MySQL 8.0 or 8.4, `SELECT` queries that use an `IN()` predicate with an extremely large set of values (for example, several thousand or more values in a single `IN()` list) might exhibit significantly higher query latency and CPU usage compared to the same workload on MySQL 5.7. The optimizer's handling of very large `IN()` lists is more expensive in 8.0 and 8.4, and the cost grows with the number of values in the list.
+
+#### Resolution
+
+- Reduce the number of values passed in the `IN()` list. Where possible, refactor the application to send a smaller, more selective set of values per query.
+- For workloads that need to filter against a large set of values, load the values into a temporary or staging table and use a `JOIN` against that table instead of a single large `IN()` list.
+- Batch the query into multiple smaller queries with shorter `IN()` lists and combine the results in the application layer.
+- Test the refactored queries on a read replica or restored copy of the server before applying changes to the primary.
+
 ## Related content
 
 - [Major version upgrade in Azure Database for MySQL](how-to-upgrade.md)

articles/mysql/flexible-server/how-to-upgrade.md

@@ -171,13 +171,15 @@ To perform a major version upgrade of an Azure Database for MySQL Flexible Serve
 
 1. Go to your primary server and perform a major version upgrade.
 
-## Perform minimal downtime major version upgrade using read replicas
+## Recommended major version upgrade procedure across major versions using Read replica or Point-in-time restore (PITR)
 
-To perform a major version upgrade of an Azure Database for MySQL Flexible Server with minimal downtime using read replica servers, perform the following steps.
+To perform a major version upgrade of an Azure Database for MySQL Flexible Server with minimal downtime using read replica servers or PITR, perform the following steps.
+
+### Using a Read replica
 
 1. Select your existing Azure Database for MySQL Flexible Server instance in the Azure portal.
 
-1. Create a [read replica](how-to-read-replicas-portal.md) from your primary server.
+1. Create a [read replica](how-to-read-replicas-portal.md) from your existing primary server.
 
 1. [Upgrade](#perform-a-planned-major-version-upgrade-using-the-azure-cli) your read replica to the target major version.
 
@@ -196,11 +198,21 @@ To perform a major version upgrade of an Azure Database for MySQL Flexible Serve
 
 1. Set Server Parameter read_only to **0** (OFF) to start writing on the promoted primary.
 
-1. Point your application to the new primary (former replica) running the target version. Each server has a unique connection string. Update your application to point to the (former) replica instead of the source.
+1. Update your application to point to the new primary (former replica) running the target version. Each server has a unique connection string.
 
     > [!NOTE]  
     > This scenario only incurs downtime during steps 4 through 7.
 
+### Using Point-in-time restore (PITR)
+
+1. Perform PITR of your existing Azure Database for MySQL Flexible Server.
+
+1. Upgrade the PITR instance to the target version.
+
+1. Test and tune your production load/queries on the upgraded PITR instance until the result is satisfactory.
+
+1. Update your application to point to the new primary (PITR instance) running the target version. Each server has a unique connection string.
+
 ## Related content
 
 - [Frequently asked questions (FAQs)](how-to-upgrade-faq.md)

articles/mysql/flexible-server/release-notes/may-2026.md

@@ -35,7 +35,7 @@ This version doesn't include any engine version changes.
 
 - TLS certificates are now automatically renewed earlier in their lifecycle (at 84% of validity) and all certificates follow the same renewal schedule, reducing the chance of connection issues caused by certificate expiry.
 
-- During this scheduled maintenance window, a few servers migrate from the current architecture to a dedicated Standard Load Balancer (SLB) - based architecture. The candidate servers are communicated through the usual maintenance notifications. This enhancement adds a dedicated SLB to HA configurations for servers created with public access or private endpoints. By managing the MySQL data traffic path, the SLB eliminates the need for DNS changes during failovers, significantly reducing failover time. There's a brief extra downtime (of around 30 seconds) while this migration is performed. This feature isn't supported by servers using private access with a virtual network integration.
+- During this scheduled maintenance window, a few HA-enabled servers migrate from the current architecture to a dedicated Standard Load Balancer (SLB) - based architecture. The candidate servers are communicated through the usual maintenance notifications. This enhancement adds a dedicated SLB to HA configurations for servers created with public access or private endpoints. By managing the MySQL data traffic path, the SLB eliminates the need for DNS changes during failovers, significantly reducing failover time. There's a brief extra downtime (of around 30 seconds) while this migration is performed. This feature isn't supported by servers using private access with a virtual network integration.
 
 ## Known issues fixes