Merge pull request #5004 from hariramt/task/DocUpdate/DocsUpdate-May18

[MySQL] Task/doc update/docs update may18

Author: markingmyname

articles/mysql/concepts-version-policy.md

@@ -103,7 +103,7 @@ A: Azure Database for MySQL enables you to carry out in-place major version upgr
 
 __Q: Are there any expected downtime or performance impacts during a major version upgrade?__
 
-A: Yes, there's some downtime during the major version upgrade process. The specific duration varies depending on factors such as the size and complexity of the database. We recommend conducting a test upgrade in a nonproduction environment to assess the expected downtime and evaluate potential performance. To minimize downtime for your applications during the upgrade, you can explore the option of [performing a minimal downtime major version upgrade using read replica](flexible-server/how-to-upgrade.md#perform-minimal-downtime-major-version-upgrade-using-read-replicas).
+A: Yes, there's some downtime during the major version upgrade process. The specific duration varies depending on factors such as the size and complexity of the database. We recommend conducting a test upgrade in a nonproduction environment to assess the expected downtime and evaluate potential performance. To minimize downtime for your applications during the upgrade, you can explore the [recommended major version upgrade procedure across major versions](flexible-server/how-to-upgrade.md#recommended-major-version-upgrade-procedure-across-major-versions).
 
 __Q: Can I roll back to a previous major version after upgrading?__
 

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

@@ -19,7 +19,7 @@ ai-usage: ai-assisted
 
 - Q: **Will this cause downtime of the server, and if so, how long?**
 
-    A. To have minimal downtime during upgrades, follow the steps mentioned under [Perform minimal downtime major version upgrade using read replicas](how-to-upgrade.md#perform-minimal-downtime-major-version-upgrade-using-read-replicas). The server is unavailable during the upgrade process, so we recommend you perform this operation during your planned maintenance window. The estimated downtime depends on the database size, storage size provisioned (IOPs provisioned), and the number of tables on the database. The upgrade time is directly proportional to the number of tables on the server. To estimate the downtime for your server environment, we recommend first performing an upgrade on a restored copy of the server.
+    A. To have minimal downtime during upgrades, follow the steps mentioned under [Recommended major version upgrade procedure across major versions](flexible-server/how-to-upgrade.md#recommended-major-version-upgrade-procedure-across-major-versions). The server is unavailable during the upgrade process, so we recommend you perform this operation during your planned maintenance window. The estimated downtime depends on the database size, storage size provisioned (IOPs provisioned), and the number of tables on the database. The upgrade time is directly proportional to the number of tables on the server. To estimate the downtime for your server environment, we recommend first performing an upgrade on a restored copy of the server.
 
 - Q: **I'm using an HA server. Can I expect a near zero downtime experience for a major version upgrade, similar to routine maintenance?**
 
@@ -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
 
-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