diff --git a/content/en/docs/22.0/reference/compatibility/mysql-compatibility.md b/content/en/docs/22.0/reference/compatibility/mysql-compatibility.md
index ef3f48c30..9e311bde6 100644
--- a/content/en/docs/22.0/reference/compatibility/mysql-compatibility.md
+++ b/content/en/docs/22.0/reference/compatibility/mysql-compatibility.md
@@ -4,228 +4,223 @@ weight: 1
 aliases: ['/docs/reference/mysql-server-protocol/', '/docs/reference/mysql-compatibility/']
 ---
 
-Vitess supports MySQL and gRPC server protocol. This allows Vitess to be a drop-in replacement for MySQL Server without any changes to application code.
-As Vitess is a distributed system, it is important to understand the differences between Vitess and MySQL on compatibility.
+## Introduction
+
+Vitess supports MySQL and gRPC server protocols, allowing it to serve as a drop-in replacement for MySQL Server without changes to application code. However, because Vitess is a distributed system, there are compatibility differences to be aware of.
+
+## Table of Contents
+1. [Transaction and Isolation Levels](#transaction-and-isolation-levels)
+2. [SQL Support](#sql-support)
+   1. [DDL](#ddl)
+   2. [Join, Subqueries, Union, Aggregation, Grouping, Having, Ordering, Limit Queries](#join-subqueries-union-aggregation-grouping-having-ordering-limit-queries)
+   3. [Prepared Statements](#prepared-statements)
+   4. [Stored Procedures](#stored-procedures)
+   5. [Views](#views)
+   6. [Temporary Tables](#temporary-tables)
+   7. [USE Statements](#use-statements)
+   8. [Common Table Expressions (CTEs)](#common-table-expressions)
+   9. [Window Functions](#window-functions)
+   10. [Killing Running Queries](#killing-running-queries)
+   11. [SELECT ... INTO Statement](#select--into-statement)
+   12. [LOAD DATA Statement](#load-data-statement)
+   13. [Create/Drop Database](#createdrop-database)
+   14. [User Defined Functions (UDFs)](#user-defined-functions)
+   15. [LAST_INSERT_ID](#last_insert_id)
+3. [Cross-shard Transactions](#cross-shard-transactions)
+4. [Auto Increment](#auto-increment)
+5. [Character Set and Collation](#character-set-and-collation)
+6. [Data Types](#data-types)
+7. [SQL Mode](#sql-mode)
+8. [Network Protocol](#network-protocol)
+   1. [Authentication Plugins](#authentication-plugins)
+   2. [Transport Security](#transport-security)
+   3. [X Dev API](#x-dev-api)
+9. [Workload](#workload)
 
-## Transaction Model
+---
 
-Vitess provides MySQL default semantics i.e. `REPEATABLE READ` for single-shard transactions. For multi-shard transactions the semantics change to `READ COMMITTED`.
-The clients can change the shard level transaction mode with `SET` statement on a connection.
+## Transaction and Isolation Levels
 
-## SQL Support
+Vitess offers MySQL default semantics (`REPEATABLE READ`) for single-shard transactions. For multi-shard transactions, the semantics change to `READ COMMITTED`.
 
-The following describes some differences in query handling between Vitess and MySQL.
-The Vitess team maintains a list of [unsupported queries](https://github.com/vitessio/vitess/blob/main/go/vt/vtgate/planbuilder/testdata/unsupported_cases.json) which is kept up-to-date as we add support for new constructs.
+- You can change the isolation level at the shard level using the `SET` statement on a connection.
+- `START TRANSACTION` supports modifiers like `WITH CONSISTENT SNAPSHOT`, `READ WRITE`, and `READ ONLY`, but they apply only to the next transaction.
+- `SET TRANSACTION` is currently supported only for changing the isolation level at the session scope in Vitess (affecting shard-level isolation, not global Vitess).
 
-This is an area of active development in Vitess. Any unsupported query can be raised as an issue in the [Vitess GitHub Project](https://github.com/vitessio/vitess/issues/new/choose).
+---
 
-### DDL
+## SQL Support
 
-Vitess supports all DDL queries. It offers both [managed, online schema changes](../../../user-guides/schema-changes/managed-online-schema-changes) and non-managed DDL.
-It is recommended to use Vitess's managed schema changes, which offer non-blocking, trackable, failure agnostic, revertible, concurrent changes, and more. Read more about [making schema changes](../../../user-guides/schema-changes).
+While Vitess is mostly compatible with MySQL, there are some limitations. A current list of unsupported queries is maintained in the [Vitess GitHub repo](https://github.com/vitessio/vitess/blob/main/go/vt/vtgate/planbuilder/testdata/unsupported_cases.json).
 
-### Join, Subqueries, Union, Aggregation, Grouping, Having, Ordering, Limit Queries
+### DDL
 
-Vitess supports most of these types of queries. It is recommended to leave [schema tracking](../../features/schema-tracking) enabled in order to fully utilize the available support.
+Vitess supports all DDL queries:
+- **Managed, online schema changes** (non-blocking, revertible, etc.).
+- **Non-managed DDL** is also supported.
 
-### Prepared Statements
+Refer to [making schema changes](../../../user-guides/schema-changes) for more details.
 
-Vitess supports prepared statements via both the MySQL binary protocol and the [`PREPARE`, `EXECUTE` and `DEALLOCATE` SQL statements](https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html).
+### Join, Subqueries, Union, Aggregation, Grouping, Having, Ordering, Limit Queries
 
-### Start Transaction
-There are multiple ways to start a transaction like `begin`, `start transaction` and `start transaction [transaction_characteristic [, transaction_characteristic] ...]` with several modifiers that control transaction characteristics.
-```sql
-transaction_characteristic: {
-    WITH CONSISTENT SNAPSHOT
-  | READ WRITE
-  | READ ONLY
-}
-```
-The scope of these modifications is limited to the next transaction only.
-These modifications have a special purpose and more can be read about in the [MySQL reference manual](https://dev.mysql.com/doc/refman/8.0/en/commit.html).
+Vitess supports most of these query types. For the best experience:
+- Leave [schema tracking](../../features/schema-tracking) enabled to leverage full support.
 
-### Set Transaction
-Set Transaction statement is used to change the isolation level or access mode for transactions.
-Vitess as of now **only** supports modification of isolation level at the session scope.
-The change in isolation level only changes the shard level transaction isolation level and not the global Vitess level.
+### Prepared Statements
 
-More details about the isolation level can be read in the [MySQL reference manual](https://dev.mysql.com/doc/refman/8.0/en/set-transaction.html).
+Vitess supports:
+- Prepared statements via MySQL binary protocol.
+- SQL statements: [`PREPARE`, `EXECUTE`, `DEALLOCATE`](https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html).
 
 ### Stored Procedures
 
-Calling stored procedures using CALL is only supported for:
-
-* unsharded keyspaces
-* if you directly target a specific shard
-
-There are further limitations to calling stored procedures using CALL:
+You can call stored procedures (`CALL`) with the following limitations:
+- Must be on an **unsharded keyspace** or target a **specific shard**.
+- No results can be returned.
+- Only `IN` parameters are supported.
+- Transaction state cannot be changed by the procedure.
 
-* The stored procedure CALL cannot return any results
-* Only IN parameters are supported
-* If you use transactions, the transaction state cannot be changed by the stored procedure.
-
-  For example, if there is a transaction open at the beginning of the CALL, a transaction must still be open after the procedure finishes. Likewise, if no transaction is open at the beginning of the CALL, the stored procedure must not leave an open transaction after execution finishes.
-
-CREATE PROCEDURE is not supported. You have to create the procedure directly on the underlying MySQL servers and not through Vitess.
+`CREATE PROCEDURE` is not supported through Vitess; create procedures on the underlying MySQL servers directly.
 
 ### Views
-Views are supported for sharded keyspaces as an experimental feature, it has to be enabled using: `--enable-views` on VTGate and `--queryserver-enable-views` on VTTablet. Views are only readable.
 
-Here is an example of how to create a view:
+Views are supported for **sharded keyspaces** as an experimental feature:
+- Enable with `--enable-views` on VTGate and `--queryserver-enable-views` on VTTablet.
+- Views are only readable (no updatable views).
+- All tables referenced by the view must belong to the same keyspace.
 
-```sql
-CREATE VIEW my_view AS SELECT id, col FROM user
-```
-
-When using the view in a `SELECT` statement it will be rewritten to a derived table:
-
-```sql
--- the query:
-SELECT id FROM my_view
--- will be rewritten to:
-SELECT id FROM (SELECT id, col FROM user) as my_view;
-```
-
-> **Limitations**:
->
-> - The table referenced by the view must belong to the same keyspace as the view's.
->
-> - Views are only readable. Updatable views are not supported.
-
-The [RFC for views support](https://github.com/vitessio/vitess/issues/11559) is available on GitHub.
+See the [Views RFC](https://github.com/vitessio/vitess/issues/11559) for more details.
 
 ### Temporary Tables
 
-Vitess has limited support for temporary tables. It works only for unsharded keyspaces.
-
-If the user creates a temporary table then the session will start using reserved connections for any query sent on that session.
-
-The query plans generated by this session will not be cached. It will still continue to use the query plan cached from other non-temporary table sessions.
+Vitess has limited support for temporary tables, only for **unsharded keyspaces**:
+- Creating a temporary table forces the session to start using [reserved connections](../../query-serving/reserved-conn).
+- Query plans in this session won’t be cached.
 
 ### USE Statements
 
-Vitess allows you to select a keyspace using the MySQL `USE` statement, and corresponding binary API used by client libraries. SQL statements can refer to a table in another keyspace by using the standard _dot_ notation:
-
+Vitess allows selecting a keyspace (and shard/tablet-type) using the MySQL `USE` statement:
 ```sql
-SELECT * FROM my_other_keyspace.table;
+USE `mykeyspace:-80@rdonly`
 ```
 
-Vitess extends this functionality further by allowing you to select a specific shard and tablet-type within a `USE` statement (backticks are important):
+Or refer to another keyspace’s table via standard dot notation:
 
 ```sql
--- `KeyspaceName:shardKeyRange@tabletType`
-USE `mykeyspace:-80@rdonly`
+SELECT * 
+FROM other_keyspace.table;
 ```
 
-A similar effect can be achieved by using a database name like `mykeyspace:-80@rdonly` in your MySQL application client connection string.
-
-### Common Table Expressions 
-Non-recursive CTEs are supported in Vitess.
-Currently, Vitess has experimental support for recursive CTEs. Users are encouraged to test this feature and provide feedback.
+### Common Table Expressions
+ - Non-recursive CTEs are supported.
+ - Recursive CTEs have experimental support; feedback is encouraged.
 
 ### Window Functions
-Vitess does not yet support Window Functions.
-
-### Killing running queries
 
-In v18, Vitess introduced the ability to terminate running queries using the [`KILL` command](https://dev.mysql.com/doc/refman/8.0/en/kill.html) through VTGate.
-To execute a "kill connection" or "kill query" statement, the client needs to establish a new connection.
-This behavior is similar to when a user on the MySQL shell client terminates a command by pressing ctrl+c.
+Window Functions are not currently supported in Vitess.
 
-The [RFC](https://github.com/vitessio/vitess/issues/13438) highlights the current limitation of the `Kill statement` support. 
+### Killing Running Queries
 
-Alternatively, 
-- [query_timeout_ms](../../../user-guides/configuration-advanced/comment-directives/#query-timeouts-query_timeout_ms) query comment directive can be set to define a query timeout. This ensures that the query either returns a result or aborts within the specified time.
-- [mysql_server_query_timeout](../../programs/vtgate/) command-line flag can be set on VTGate to establish a default timeout.
+Starting with Vitess v18, you can terminate running queries with the KILL command through VTGate:
+ - Issue `KILL connection` or `KILL query` from a new client connection (similar to `ctrl+c` in MySQL shell).
+ - You can also ask Vitess to kill queries that run beyond a specified timeout. The timeout can be set per query or globally.
+ - `query_timeout_ms` (per-query timeouts).
+ - `mysql_server_query_timeout command-line` flag (global default timeout).
 
-Vitess does have strict query timeouts for OLTP workloads (see below).
+### SELECT … INTO Statement
 
-### Workload
+Vitess supports `SELECT ... INTO DUMPFILE` and `SELECT ... INTO OUTFILE` for unsharded keyspaces:
+ - Position of `INTO` must be at the end of the query.
+ - For sharded keyspaces, you must specify the exact shard with a `USE` statement.
 
-By default, Vitess applies specific limitations on the execution time and the number of rows a query can return.
-These limitations can be modified by adjusting the parameters like `queryserver-config-query-timeout`, `queryserver-config-transaction-timeout` and more in [vttablet](../../programs/vttablet/).
-This default workload mode is referred as `OLTP`. This can be disabled by switching to `OLAP` mode by executing the following SQL statement:
-
-```sql
-set workload = olap;
-```
+### LOAD DATA Statement
 
-### SELECT ... INTO Statement
+`LOAD DATA` (the counterpart to `SELECT ... INTO OUTFILE`) is supported only in unsharded keyspaces:
+ - Must be used similarly to the `SELECT ... INTO` statement.
+ - For sharded keyspaces, use the USE Statement to target an exact shard.
 
-The `SELECT ... INTO` form of `SELECT` in MySQL enables a query result to be stored in variables or written to a file. Vitess supports `SELECT ... INTO DUMFILE` and `SELECT ... INTO OUTFILE` constructs for unsharded keyspaces but does not support storing results in variable. Moreover, the position of `INTO` must be towards the end of the query and not in the middle. An example of a correct query is as follows:
-```sql
-SELECT * FROM <tableName> INTO OUTFILE 'x.txt' FIELDS TERMINATED BY ';' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\t' LINES TERMINATED BY '\n'
-```
-For sharded keyspaces this statement can still be used but only after specifying the exact shard with a [USE Statement](#use-statements).
+### Create/Drop Database
 
-### LOAD DATA Statement
+Vitess does not support `CREATE DATABASE` or `DROP DATABASE` by default:
+ - A plugin mechanism ([`DBDDLPlugin`](https://github.com/vitessio/vitess/blob/release-21.0/go/vt/vtgate/engine/dbddl.go#L53) interface) exists for provisioning databases.
+ - The plugin must handle database creation, topology updates, and VSchema updates.
+ - Register the plugin with `DBDDLRegister` and specify `--dbddl_plugin=myPluginName` when running vtgate.
 
-`LOAD DATA` is the complement of `SELECT ... INTO OUTFILE` that reads rows from a text file into a table at a very high speed. Just like `SELECT ... INTO` statement, `LOAD DATA` is also supported in unsharded keyspaces. An example of a correct query is as follows:
-```sql
-LOAD DATA INFILE 'x.txt' INTO REPLACE TABLE <tableName> FIELDS TERMINATED BY ';' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\t' LINES TERMINATED BY '\n'
-```
-For sharded keyspaces this statement can still be used but only after specifying the exact shard with a [USE Statement](#use-statements).
+### User Defined Functions
 
-### Create/Drop Database
+Vitess can track UDFs if you enable the `--enable-udfs` flag on VTGate. More details on creating UDFs can be found in the MySQL Docs.
 
-Vitess does not support CREATE and DROP DATABASE queries out of the box.
+### LAST_INSERT_ID
 
-However, a plugin mechanism is available that can be used to provision databases.
-The plugin has to take care of creating and dropping the database, and update the topology & VSchema so that Vitess can start receiving queries for the new keyspace.
+Vitess supports `LAST_INSERT_ID` both for returning the last auto-generated ID and for the form `LAST_INSERT_ID(expr)`, which sets the session’s last-insert-id value.
 
-The plugin should implement the `DBDDLPlugin` interface, and be saved into a new file in the `go/vt/vtgate/engine/` directory.
+**Example**:
 
-```go
-type DBDDLPlugin interface {
-	CreateDatabase(ctx context.Context, name string) error
-	DropDatabase(ctx context.Context, name string) error
-}
+```sql
+insert into test (id) values (null); -- Inserts a row with an auto-generated ID
+select LAST_INSERT_ID(); -- Returns the last auto-generated ID
+SELECT LAST_INSERT_ID(123); -- Sets the session’s last-insert-id value to 123
+SELECT LAST_INSERT_ID(); -- Returns 123
 ```
 
-It must then register itself by calling `DBDDLRegister`.
-You can take a look at the `dbddl_plugin.go` in the engine package for an example of how it's done.
-Finally, you need to add a command line flag to vtgate to have it use the new plugin: `--dbddl_plugin=myPluginName`
+**Limitation**: When using `LAST_INSERT_ID(expr)` as a SELECT expression in *ordered queries*, MySQL sets the session’s `LAST_INSERT_ID` value based on the *last row returned*. 
+Vitess, however, does **not** guarantee which row’s value will be used.
 
-### User Defined Functions
-VTGates can now track user-defined functions (UDFs) and use them during planning.
-To enable this feature, set the `--enable-udfs` flag on VTGate.
-More details on how to add UDFs can be found in [MySQL Docs](https://dev.mysql.com/doc/extending-mysql/8.0/en/adding-loadable-function.html).
+**Example**:
+
+```sql
+SELECT LAST_INSERT_ID(col) 
+FROM table 
+ORDER BY foo;
+```
 
 ## Cross-shard Transactions
 
 Vitess supports multiple [transaction modes](../../../user-guides/configuration-advanced/shard-isolation-atomicity): `SINGLE`, `MULTI` and `TWOPC` .
-
-The default mode is MULTI i.e. multi-shard transactions as best-effort. A transaction that affects only one shard will be fully ACID complaint.
-When a transactions affects multiple shards, any failure on one or more shards will rollback the effect of that query.
-Committing the multi-shard transaction issues commits to the participating shards in a particular order. This allows the application or user to undo the effects of partial commits in case of failures.
+ - Default: `MULTI` — multi-shard transactions on a best-effort basis.
+ - A single-shard transaction is fully ACID-compliant.
+ - Multi-shard commits are done in a specific order; partial commits can be manually undone if needed.
 
 ## Auto Increment
 
-Tables in sharded keyspaces should not be defined using the `auto_increment` column attribute, as the values generated will not be unique across shards.
-It is recommended to use [Vitess Sequences](../../features/vitess-sequences) instead. The semantics are very similar to `auto_increment` and the differences are documented.
+Avoid the `auto_increment` column attribute in sharded keyspaces; values won’t be unique across shards.
+Use [Vitess Sequences](../../../user-guides) instead — they behave similarly to `auto_increment`.
 
 ## Character Set and Collation
 
-Vitess supports ~99% of MySQL collations. More details can be found [here](../../../user-guides/configuration-basic/collations).
+Vitess supports ~99% of MySQL collations. For details, see the [collations documentation](../../../user-guides/configuration-basic/collations).
 
 ## Data Types
 
-Vitess supports all of the data types available in MySQL. Using the `FLOAT` data type as part of a `PRIMARY KEY` is strongly discouraged, since features such as filtered replication and VReplication will not correctly be able to detect which rows should be included as part of a modification.
+Vitess supports all MySQL data types. Using `FLOAT` as part of a `PRIMARY KEY` is discouraged because it can break features like filtered replication and VReplication.
 
 ## SQL Mode
 
-Vitess behaves similar to the `STRICT_TRANS_TABLES` sql mode, and does not recommend changing the SQL Mode setting.
+Vitess behaves similarly to `STRICT_TRANS_TABLES` and does not recommend changing the SQL Mode.
 
 ## Network Protocol
 
 ### Authentication Plugins
 
-Vitess supports both 5.7 and 8.0 authentication. E.g. `mysql_native_password`, `caching_sha2_password`, etc.
+Vitess supports MySQL authentication plugins, such as `mysql_native_password` and `caching_sha2_password`.
 
 ### Transport Security
 
-To configure VTGate to support `TLS` set `--mysql_server_ssl_cert` and `--mysql_server_ssl_key`. Client certificates can also be mandated by setting `--mysql_server_ssl_ca`. If there is no CA specified then TLS is optional.
+To enable TLS on VTGate:
+ - Set `--mysql_server_ssl_cert` and `--mysql_server_ssl_key`.
+ - Optionally require client certificates with `--mysql_server_ssl_ca`.
+ - If no CA is specified, TLS is optional.
 
 ### X Dev API
 
-Vitess does not support [X Dev API](https://dev.mysql.com/doc/x-devapi-userguide/en/).
+Vitess does not support the X Dev API.
+
+## Workload
+
+By default, Vitess applies strict limitations on execution time and row counts, often referred to as OLTP mode:
+ - These parameters can be tweaked with `queryserver-config-query-timeout`, `queryserver-config-transaction-timeout`, and [others](../../programs/vttablet) on vttablet.
+ - You can switch to OLAP mode by issuing:
+
+```sql
+SET workload = olap;
+```