设置兼容级别 / 功能版本

Oracle

-- Raise the COMPATIBLE initialization parameter (irreversible!):
ALTER SYSTEM SET COMPATIBLE = '19.0.0' SCOPE=SPFILE;
-- Then restart the instance. To see the current value:
SHOW PARAMETER compatible;

COMPATIBLE 参数决定启用哪个版本的功能和文件格式。一旦提升并重启实例，就无法回退（降级被阻止）；因此在确认升级成功之前应逐步提升。

PostgreSQL

# Not applicable: PostgreSQL has no database compatibility level.
# If legacy behavior is needed, set the relevant GUCs (e.g. SET standard_conforming_strings=off)
# or manage the major migration with dump/restore.

PostgreSQL 没有类似 SQL Server/Oracle 的“兼容级别”概念；版本行为直接与二进制版本绑定。版本间迁移使用 pg_dump/pg_restore 或 pg_upgrade。

MySQL

# Not applicable: MySQL has no configurable database compatibility level.
# Behavioral differences are managed with sql_mode:
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';

MySQL 没有基于版本的兼容级别；SQL 行为主要取决于二进制版本和 sql_mode 设置。可微调 sql_mode 以保留旧应用的行为。

SQL Server

-- Set the database compatibility level (e.g. SQL Server 2022 = 160):
ALTER DATABASE Sales SET COMPATIBILITY_LEVEL = 160;
-- To see the current value:
SELECT name, compatibility_level FROM sys.databases;

COMPATIBILITY_LEVEL 决定查询优化器和语言功能按哪个版本的行为运行（150=2019，160=2022）。实例升级后，数据库可保持在旧级别；建议逐步提升并监控执行计划回归。可以再次降低。

MongoDB

// Set the Feature Compatibility Version (FCV):
db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })
// Read the current value:
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

FCV 控制随版本而来的持久化数据格式变更和新功能何时启用。在二进制升级完成、集群稳定后再提升；只有当同一二进制版本仍支持较低的 FCV 时才能降低。

Redis

# Not applicable: Redis has no compatibility level / feature version concept.
# Behavior depends directly on the running binary version.

Redis 没有可配置的兼容级别；功能集完全取决于运行的版本。兼容性仅在 RDB/AOF 文件格式层面向前保持。

Elasticsearch

# Not applicable: Elasticsearch has no configurable compatibility level.
# An index is tied to the format of the version it was created in; very old indices
# cannot be read in the new version and require a reindex.

Elasticsearch 没有兼容级别设置；每个索引都带有其创建时所在大版本的格式。上一大版本中创建的索引可以读取，更早的索引则必须用 _reindex 迁移到新版本。