Merge branch 'MicrosoftDocs:main' into troubleshoot-slow-queries-ec

Author: JaredMSFT

articles/cosmos-db/vector-search.md

@@ -155,12 +155,12 @@ A few points to consider:
 
 - The `flat` and `quantizedFlat` index types use Azure Cosmos DB's index to store and read each vector when performing a vector search. Vector searches with a `flat` index are brute-force searches and produce 100% accuracy or recall. That is, it's guaranteed to find the most similar vectors in the dataset. However, there's a limitation of `505` dimensions for vectors on a flat index.
 
-- The `quantizedFlat` index stores quantized (compressed) vectors on the index. Vector searches with `quantizedFlat` index are also brute-force searches, however their accuracy might be slightly less than 100% since the vectors are quantized before adding to the index. However, vector searches with `quantized flat` should have lower latency, higher throughput, and lower RU cost than vector searches on a `flat` index. This is a good option for smaller scenarios, or scenarios where you're using query filters to narrow down the vector search to a relatively small set of vectors. `quantizedFlat` is recommended when the number of vectors to be indexed is somewhere around 50,000 or fewer per physical partition. However, this is just a general guideline and actual performance should be tested as each scenario can be different.
+- The `quantizedFlat` index stores quantized (compressed) vectors on the index. Vector searches with `quantizedFlat` index are also brute-force searches, however their accuracy might be slightly less than 100% since the vectors are quantized before adding to the index. However, vector searches with `quantized flat` should have lower latency, higher throughput, and lower RU cost than vector searches on a `flat` index. This is a good option for smaller scenarios, or scenarios where you're using query filters to narrow down the vector search to a relatively small set of vectors. `quantizedFlat` is recommended when the number of vectors scoped to your search is 50,000 or fewer. However, this is just a general guideline and actual performance should be tested as each scenario can be different.
 
-- The `diskANN` index is a separate index defined specifically for vectors using [DiskANN](https://www.microsoft.com/research/publication/diskann-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node/), a suite of high performance vector indexing algorithms developed by Microsoft Research. DiskANN indexes can offer some of the lowest latency, highest throughput, and lowest RU cost queries, while still maintaining high accuracy. In general, DiskANN is the most performant of all index types if there are more than 50,000 vectors per physical partition.
+- The `diskANN` index is a separate index defined specifically for vectors using [DiskANN](https://www.microsoft.com/research/publication/diskann-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node/), a suite of high performance vector indexing algorithms developed by Microsoft Research. DiskANN indexes can offer some of the lowest latency, highest throughput, and lowest RU cost queries, while still maintaining high accuracy. In general, DiskANN is the most performant of all index types if your search query is scoped to more than 50,000 vectors. 
 
 > [!NOTE]
->  In general, you can add new path configurations or remove existing ones, but you cannot change the settings of a vector emebdding policy or vector indexing policy. To do so you must first drop the existing vector policy and index, then add it back with new configuration. 
+> You can add new path configurations or remove existing ones, but you cannot change the settings of a vector embedding policy or vector indexing policy directly. To do so you must first drop the existing vector policy and/or index, then add it back with new configuration. 
 
 Here are examples of valid vector index policies:
 

articles/mysql/TOC.yml

@@ -24,6 +24,8 @@
           items:
             - name: Release notes index
               href: flexible-server/release-notes/release-notes-index.md
+            - name: March 2026
+              href: flexible-server/release-notes/march-2026.md              
             - name: January 2026
               href: flexible-server/release-notes/january-2026.md
             - name: October 2025

articles/mysql/concepts-version-policy.md

@@ -1,16 +1,15 @@
 ---
 title: Version Support Policy
 description: Describes the policy around MySQL major and minor versions in Azure Database for MySQL
-author: xboxeer
-ms.author: yuzheng1
+author: moabuham 
+ms.author: moabuham 
 ms.reviewer: maghan
-ms.date: 06/27/2025
+ms.date: 03/27/2026
 ms.service: azure-database-mysql
 ms.subservice: flexible-server
 ms.topic: concept-article
 ms.custom:
   - fasttrack-edit
-  - ignite-2024
 ---
 
 # Azure Database for MySQL version support policy
@@ -24,7 +23,7 @@ Azure Database for MySQL was developed from the [MySQL Community Edition](https:
 Azure Database for MySQL currently supports the following major and minor versions of MySQL:
 
 | Version | Current minor version | Release status |
-| :--- | :--- | :--- |
+| --- | --- | --- |
 | MySQL Version 5.7 | [5.7.44](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-44.html) | GA |
 | MySQL Version 8.0 | [8.0.42](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-42.html) | GA |
 | MySQL Version 8.4 | [8.4.5](https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-5.html) | GA |
@@ -55,9 +54,9 @@ During the Extended Support period, Microsoft prioritizes the service's availabi
 
 > [!NOTE]  
 > Extended Support is automatically applied and charged to servers running on legacy MySQL versions after standard Support ends. To opt out of Extended Support and avoid charges, customers must upgrade to a supported major version of the software. For more information or to provide feedback, contact [Ask Azure Database For MySQL](mailto:AskAzureDBforMySQL@service.microsoft.com).
-> 
+>
 > Servers in stopped state will not be charged for extended support. The charge will only apply to servers in succeeded state.
-> 
+>
 > Pricing is available on the [pricing page](https://azure.microsoft.com/pricing/details/mysql/?cdn=disable)
 
 ## Innovation release version support
@@ -77,10 +76,17 @@ The following restrictions apply only after the extended support period has ende
 
 - No further security or support updates are provided for the retired version. Azure Database for MySQL can't patch the retired database engine for any bugs or security issues, and support for database engine-related issues are no longer be available. However, Azure continues performing periodic maintenance and patching for the host, OS, containers, and other service-related components.
 - You can't create new database servers for the retired version. However, you can perform point-in-time recoveries and create read replicas for your existing servers.
-New service capabilities developed by Azure Database for MySQL might only be available for supported database server versions.
+  New service capabilities developed by Azure Database for MySQL might only be available for supported database server versions.
 - Uptime S.L.A.s apply solely to Azure Database for MySQL service-related issues and not to any downtime caused by database engine-related bugs.
 - In the extreme event of a serious threat to the service caused by the MySQL database engine vulnerability identified in the retired database version, Azure might choose to stop the compute node of your database server from securing the service first. You're asked to upgrade the server before bringing it online. During the upgrade process, your data is always protected by automatic backups performed on the service, which can be used to restore it to an older version if desired.
 
+## Retired MySQL plugins support in Azure Database for MySQL
+
+- According to the MySQL public documentation, the [mysql_native_password](https://dev.mysql.com/doc/refman/8.4/en/native-pluggable-authentication.html) authentication plugin was deprecated in MySQL 8.0.34. However, this plugin remains enabled in Azure Database for MySQL across all versions in Azure database for MySQL.
+- For MySQL 8.4, the caching_sha2_password plugin is the default authentication plugin. All new user accounts use the caching_sha2_password plugin for authentication.
+  Existing user accounts that use the mysql_native_password plugin will continue to be supported.
+- It is recommended to change the authentication plugin for the existing user accounts to caching_sha2_password authentication plugin instead of the mysql_native_password plugin either before or after upgrade to MySQL 8.4.
+
 ## Frequently asked questions (FAQ)
 
 __Q: What happens if I don't upgrade my Azure Database for MySQL server to a supported major version after standard support ends?__
@@ -117,7 +123,7 @@ __Q: What happens to my data during the upgrade?__
 
 A: While your data remains unaffected during the upgrade process, it's highly advisable to create a backup before proceeding with the upgrade. This precautionary measure helps mitigate the risk of potential data loss due to any unforeseen complications.
 
-__Q: What is Azure Database for MySQL – Extended Support?__
+__Q: What is Azure Database for MySQL - Extended Support?__
 
 A: Extended Support is a feature offering that allows customers to continue running MySQL versions that have reached community end-of-life (end of support), with continued access to SLA-backed availability, security updates, and technical support.