orczhou.com

admin

  • 云数据库行业动态@2025-04-25

    ·

    admin

    标题：阿里云开源RDS MCP Server发布;火山云MySQL发布Sequence、Flashback Query等功能

    重要更新

    阿里云数据库发布开源RDS MCP Server，支持快速实例创建、实例状态诊断等功能：现已开源｜阿里云RDS发布MCP Server能力，解锁数据库“对话即运维”新体验。

    火山云数据库 MySQL 发布一系列重磅功能，包括了Sequence Engine[5]、Flashback Query[6]、5.7到8.0大版本升级等[7]。

    更新详情

    火山云(字节)
    • 云数据库 MySQL 支持对表/列级别进行账号权限控制[4]
    • 云数据库 MySQL 8.0 版本实例提供了 Sequence Engine，用于获取唯一递增序列值[5]
    • 云数据库 MySQL 8.0 实例中提供闪回查询（Flashback Query）功能[6]
    • 支持了云数据库 MySQL 5.7 到 8.0 的升级功能[7]
    • 云数据库 PostgreSQL 开始支持支持 17 [26]
    • 云数据库 PostgreSQL提供 1.5.2 版本的 pg_repack 插件 [27]
    • 在 PostgreSQL 13 及以上版本实例中提供 0.8.0 版本 pg_vector 插件 [28]
    • 云数据库 PostgreSQL 支持插件 pg_partman、pg_jobmon [30]
    • 缓存数据库 Redis 版支持了跨地域备份恢复到新实例[8]
    • 缓存数据库 Redis 版支持连接级别的读写分离策略[11]
    • 缓存数据库 Redis 版支持了 ExTimeSeries 数据结构[12]
    Azure(微软云)
    • Azure Database for PostgreSQL 17 性能管理服务器参数现支持修改 [9]
    • Azure Database for PostgreSQL 迁移服务支持时间序列数据库 [10]
    • Azure Cosmos DB 发布用于 NoSQL 的分片 DiskANN [14]
    • 基于 vCore 的 Azure Cosmos DB for MongoDB 支持 Mongo 8.0 [15]
    百度云
    • 托管 Redis 内存型支持按时间点恢复数据[34]
    AWS(亚马逊云)
    • Amazon MemoryDB 现已支持 Internet 协议版本 6 (IPv6) [42]
    腾讯云
    • TDSQL-C MySQL 版、云数据库 MySQL 只读分析引擎发布了全新内核版本1.2404.23.0与2.2410.5.0。[44][45]
    • 数据库管理 DMC 支持了云数据库 SQL Server[46]

    参考链接

  • 使用 Docker 工具安装不同版本的Oracle数据库

    ·

    admin

    Docker 大大简化了数据库的安装，特别是在产品测试阶段的时候，可以让开发者以最快速的方式体验技术产品，尤其是当这个技术产品已经非常复杂的时候。

    Oracle 官方提供了哪些镜像

    Oracle 镜像官方页面

    Oracle 在官方站点中列出了所有支持的产品，以及对应的仓库列表。 Oracle 镜像仓库的官方页面：

    仓库官方页： https://container-registry.oracle.com/

    找到软件对应的子仓库

    这里关注 Oracle Database 相关的仓库，故选择第一个仓库列表页。在这里可以看到有很多的子仓库，可以用于安装不同的 Oracle 数据库版本或组件：

    选择版本与镜像站点

    进入单个子仓库，在页面的最底下可以看到，该仓库有哪些版本的镜像可以使用，例如，这里选择了 express 子仓库，在页面最底端找到支持的版本列表：

    另外，这里还提供了一些可供选择的镜像列表，开发者可以根据自己的地理位置选择合适的镜像站点。

    安装 Oracle 数据库

    拉取镜像

    docker pull container-registry.oracle.com/database/express:latest
  or:  
docker pull container-registry.oracle.com/database/express:21.3.0-xe
  or:
docker pull container-registry.oracle.com/database/express:18.4.0-xe

    这里的测试选择了express:18.4.0-xe版本进行安装。查看本地的镜像：

    docker image ls
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
REPOSITORY                                            TAG         IMAGE ID      CREATED       SIZE
container-registry.oracle.com/mysql/community-server  9.1         f1f889678a73  6 months ago  606 MB
container-registry.oracle.com/database/express        18.4.0-xe   364598d20118  4 years ago   6.03 GB

    创建 Oracle 数据库的容器

    docker container create \
   -it \
   --name oracle-18ex \
   -p 1521:1521 \
   -e ORACLE_PWD=oracledocker \
   container-registry.oracle.com/database/express:18.4.0-xe

    启动容器

    docker start oracle-18ex

    观察启动状态

    docker logs -f oracle-18ex
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
ORACLE PASSWORD FOR SYS AND SYSTEM: oracledocker
Specify a password to be used for database accounts. Oracle recommends that the password entered should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit [0-9]. Note that the same password will be used for SYS, SYSTEM and PDBADMIN accounts:
Confirm the password:
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database XE.
Enter SYS user password:
****************
Enter SYSTEM user password:
*************
Enter PDBADMIN User Password:
*************
Prepare for db operation
7% complete
Copying database files
29% complete
Creating and starting Oracle instance
30% complete
31% complete
34% complete
38% complete
41% complete
43% complete
Completing Database Creation
47% complete
50% complete
Creating Pluggable Databases
54% complete
71% complete
Executing Post Configuration Actions
93% complete
Running Custom Scripts
100% complete
Database creation complete. For details check the logfiles at:
 /opt/oracle/cfgtoollogs/dbca/XE.
Database Information:
Global Database Name:XE
System Identifier(SID):XE
Look at the log file "/opt/oracle/cfgtoollogs/dbca/XE/XE.log" for further details.

Connect to Oracle Database using one of the connect strings:
     Pluggable database: bd127ae4faab/XEPDB1
     Multitenant container database: bd127ae4faab
Use https://localhost:5500/em to access Oracle Enterprise Manager for Oracle Database XE
The Oracle base remains unchanged with value /opt/oracle
#########################
DATABASE IS READY TO USE!
#########################
The following output is now a tail of the alert.log:
2025-04-17T03:40:43.663079+00:00
XEPDB1(3):Resize operation completed for file# 10, old size 358400K, new size 368640K
2025-04-17T03:40:44.483587+00:00
XEPDB1(3):CREATE SMALLFILE TABLESPACE "USERS" LOGGING  DATAFILE  '/opt/oracle/oradata/XE/XEPDB1/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED  EXTENT MANAGEMENT LOCAL  SEGMENT SPACE MANAGEMENT  AUTO
XEPDB1(3):Completed: CREATE SMALLFILE TABLESPACE "USERS" LOGGING  DATAFILE  '/opt/oracle/oradata/XE/XEPDB1/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED  EXTENT MANAGEMENT LOCAL  SEGMENT SPACE MANAGEMENT  AUTO
XEPDB1(3):ALTER DATABASE DEFAULT TABLESPACE "USERS"
XEPDB1(3):Completed: ALTER DATABASE DEFAULT TABLESPACE "USERS"
2025-04-17T03:40:44.930766+00:00
ALTER PLUGGABLE DATABASE XEPDB1 SAVE STATE
Completed: ALTER PLUGGABLE DATABASE XEPDB1 SAVE STATE

    登录容器中的 Oracle 数据库

    在上面的输出中可以看到，安装时会默认创建如下数据库：

    Database Information:
Global Database Name:XE
System Identifier(SID):XE

    根据在上述 docker 命令中指定的密码，则可以使用如下的命令登录数据数据库：

    docker exec -it oracle-18ex sqlplus sys/oracledocker@XE as sysdba
  or:
docker exec -it oracle-18ex sqlplus system/oracledocker@XE

    登录后，会有如下提示输入：

    Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.

SQL*Plus: Release 18.0.0.0.0 - Production on Thu Apr 17 03:56:27 2025
Version 18.4.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.

Last Successful login time: Thu Apr 17 2025 03:49:37 +00:00

Connected to:
Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0

SQL>

    授权协议与认证

    如果你要使用 Oracle 数据库的企业版的话，在拉取镜像前则需要先登录官网“同意”相关的协议，并使用docker login的方式进行认证，然后才可以拉取镜像。

    requested access to the resource is denied

    如果没有认证或提前在官网统一协议，则可能遇到如下报错：requested access to the resource is denied：

    docker pull container-registry.oracle.com/database/enterprise:12.2.0.1
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Trying to pull container-registry.oracle.com/database/enterprise:12.2.0.1...
Error: initializing source docker://container-registry.oracle.com/database/enterprise:12.2.0.1: reading manifest 12.2.0.1 in container-registry.oracle.com/database/enterprise: requested access to the resource is denied

    或者：invalid username/password: authentication required

    docker pull container-registry-tokyo.oracle.com/database/enterprise:12.2.0.1
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Trying to pull container-registry-tokyo.oracle.com/database/enterprise:12.2.0.1...
Error: initializing source docker://container-registry-tokyo.oracle.com/database/enterprise:12.2.0.1: unable to retrieve auth token: invalid username/password: authentication required

    解决上述问题，首先需要登录Oracle镜像的官方站点，并同意相关协议，然后使用docker login完成认证，后即可下载。

    登录Oracle仓库站点并同意协议

    例如，如果需要下载“Oracle Database Enterprise Edition”，则需要先进入对应仓库站点：链接，并在页面的右侧栏点击协议并同意协议：

    docker login

    同意协议后，就可以使用docker login登录账号并进行镜像的下载了。

    Enterprise Edition的Docker安装

    在参考 Oracle 企业版官方文档（参考）进行安装部署的时候，在 AlmaLinux 部署时会遇到如下的问题：

    docker exec -it oracle-1202ee sqlplus / as sysdba
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: crun: executable file `sqlplus` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

    当前的绕过方案是，进入容器的bash，然后再执行即可：

    [root@oracle-docker-test ~]# docker exec -it oracle-1202ee bash
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
[oracle@8bb1ec09ec5e /]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Fri Apr 18 02:37:30 2025

Copyright (c) 1982, 2016, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL>

    创建容器时的参数

    在创建容器的时候，可以使用命令行进行部分启动参数的配置。例如，默认启动时，是没有开启归档日志的（Archive Logs）的，则可以通过添加如下容器构建参数：

    -e ENABLE_ARCHIVELOG=true

    完整的命令：

    docker container create \
   -it \
   --name oracle-1202ee \
   -p 1521:1521 \
   -e ENABLE_ARCHIVELOG=true \
   -e ORACLE_PWD=oracledocker \
   container-registry.oracle.com/database/enterprise:12.2.0.1

    相关资源

  • 云数据库行业动态@2025-04-18

    ·

    admin

    标题：Google AlloyDB自持内置自然语言查询功能;达梦2024年营收为10.4亿,同比增长31%

    重要更新

    达梦发布2024年度报告，该年年度营收达10.4亿，同比增长31.49%，净利润为3.6亿。[1]

    Google AlloyDB 发布自然语言查询功能，该功能可以让开发者通过简单的配置，就可以在数据库内部实现自然语言转SQL并进行查询。[2]

    更新详情

    阿里云
    • RDS MySQL全面提升本地盘实例（含主实例和只读实例）的存储空间上限，最高支持16000 GB，满足用户存储扩容需求。[4]
    • RDS MySQL的秒级加列（Instant Add Column）通过变更数据字典的元数据来优化ADD COLUMN 操作。该功能避免了传统DDL操作对全表数据的修改或重建，实现加列操作在秒级内完成，且不受表数据量影响。[5]
    • RDS PostgreSQL ESSD云盘实例支持下载带表头信息的CSV格式备份文件，可用于数据分析或离线归档等需求。[6]
    火山云(字节)
    • veDB MySQL 支持闪回查询，通过闪回查询功能，能够直接查询过去某段时间时间内的历史数据。[7]
    • veDB MySQL 支持 RETURNING 语法，支持在执行 INSERT、REPLACE、UPDATE、DELETE 等 DML 语句时，直接返回受影响的行数据 [8]
    AWS(亚马逊云)
    • Bedrock 知识库现在支持 Aurora PostgreSQL 和 MongoDB Atlas 矢量存储的混合搜索 [18]
    • ElastiCache for Memcached 推出水平、垂直自动扩展功能[20][21]
    腾讯云
    • 数据库管理 DMC 支持了云数据库 SQL Server [22]
    • 云数据库 SQL Server 优化重启功能，支持选择重启的生效时间[23]

    参考链接

  • MySQL/InnoDB 的 隐式锁

    ·

    admin

    InnoDB 的锁容易被忽略的细节是关于“隐式锁”（即：implicit locks）的存在。表现上，有的锁是存在的，但在使用SHOW ENGINE INNODB STATUS或者performance_schema.data_locks中却查看不到。最为常见的隐式锁是在写入（INSERT）时，当前事务会持有该记录对应的锁，但是在系统中，通常是查看不到的。但，如果发生了该锁冲突（或竞争）时，系统中则可以看到此类锁信息。

    本文重现了较为常见的隐式锁场景，包括：数据写入（INSERT）时的隐式锁、根据主键操作是可能产生的二级索引隐式锁等。帮助开发者能够更系统的理解，InnoDB 的锁机制。

    写入数据产生的隐式锁

    准备数据

    DROP TABLE IF exists t1;

 CREATE TABLE `t1` (
  `id` int unsigned,
  `nick` varchar(32),
  `age` int,
  UNIQUE KEY `uk_n` (`nick`)
);
    mysql> desc t1;
+-------+--------------+------+-----+---------+
| Field | Type         | Null | Key | Default |
+-------+--------------+------+-----+---------+
| id    | int unsigned | YES  |     | NULL    |
| nick  | varchar(32)  | YES  | UNI | NULL    |
| age   | int          | YES  |     | NULL    |
+-------+--------------+------+-----+---------+

    mysql> INSERT INTO t1 VALUES (1, 'a' , 12),(20,'z',29);
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from t1;
+------+------+------+
| id   | nick | age  |
+------+------+------+
|    1 | a    |   12 |
|   20 | z    |   29 |
+------+------+------+
2 rows in set (0.00 sec)

    构建隐式锁

    mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t1 VALUES (8, 'h' , 32);
Query OK, 1 row affected (0.00 sec)

    查看锁信息：

    > SELECT 
    ENGINE_TRANSACTION_ID AS TRX_ID,
    OBJECT_NAME,
    INDEX_NAME,
    LOCK_TYPE,
    LOCK_MODE,
    LOCK_STATUS,
    LOCK_DATA 
  FROM performance_schema.data_locks;
+--------+-------------+------------+-----------+-----------+-------------+-----------+
| TRX_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
+--------+-------------+------------+-----------+-----------+-------------+-----------+
|  10165 | t1          | NULL       | TABLE     | IX        | GRANTED     | NULL      |
+--------+-------------+------------+-----------+-----------+-------------+-----------+

    可以看到，在 data_locks 表中没有任何关于事务中写入数据相关的锁。这是，因为这是一个隐式的锁，在没有任何锁竞争的情况下，系统并不会将该类型的锁展示出来（注：这可能与底层的存储和实现有关，隐式锁在实现上可能就没有“显式”的存储在锁相关的数据结构中）。

    构建锁竞争/隐式转显式

    这里通过在另一个事务中尝试并发写入一条冲突的记录，来构建锁竞争：

    mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO  t1 VALUES (9,'h',17);
...

    该事务执行时，则会陷入锁等待。这时，再次查看锁信息如下：

    +--------+-------------+------------+-----------+---------------+-------------+---------------------+
| TRX_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA           |
+--------+-------------+------------+-----------+---------------+-------------+---------------------+
|  10165 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL                |
|  10168 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL                |
|  10165 | t1          | uk_n       | RECORD    | X,REC_NOT_GAP | GRANTED     | 'h', 0x000000000214 |
|  10168 | t1          | uk_n       | RECORD    | S             | WAITING     | 'h', 0x000000000214 |
+--------+-------------+------------+-----------+---------------+-------------+---------------------

    这时候，可以看到事务10165，持有一个记录锁，该锁是一个排它记录锁（X,REC_NOT_GAP ），加锁对象是'h', 0x000000000214（注，这是一个唯一索引的入口，前面'h'是唯一索引值，后面的0x000000000214部分是该表的InnoDB内置rowid）。

    主键/二级索引操作相关的隐式锁

    InnoDB 的锁管理和实现确实一个超级复杂的部分（”mega-complicated“）。隐式锁的使用场景也非常多，如果对此不了解的话，那么在观察 InnoDB 的锁信息时，是会有很多的困惑的。这里再列举一类也算，较为常用的隐式锁：“主键索引/二级索引”相关的隐式说。即：

    • 当对记录进行操作时，即便是通过主键扫描，也可能对二级索引进行加锁
    • 当对记录进行操作时，即便是通过二级索引扫描，也可能对主键进行加锁

    这类场景的加锁，通常都是会存在隐式锁。

    主键操作时二级索引上的隐式锁

    在下面的测试中，我们先主键 id = 8的记录进行删除操作，然后通过系统表data_locks观察该事务是否持有二级索引相关的锁；而后，在另一个事务中，通过二级索引（nick = 'Henry'）对该记录进行操作（共享读），而后再重新观察前面事务的锁状态。

    在下面的测试可以观察到，在Session B没有开始前；在 Session A的DELETE语句是观测不到二级索引上的锁的；但当Session B尝试去锁定二级索引上的入口时，再次观察Session A上的锁信息，就可以看到，在Session A没有任何操作的情况下，多出了一个额外的、持有的二级索引上的锁，该锁原本是一个“隐式锁”，在发生锁竞争后，转化为一个“显式锁”。即便是在Session B因为等待操作或结束了，Session A持有的已经转化的“显式锁”也不会再回退了。详细测试如下。

    准备数据

    DROP TABLE IF exists t1;
 CREATE TABLE `t1` (
  `id` int unsigned,
  `nick` varchar(32),
  `age` int,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_n` (`nick`)
);
    mysql> INSERT INTO t1 VALUES (1,"Alice",12);
mysql> INSERT INTO t1 VALUES (8,"Henry",27);
mysql> INSERT INTO t1 VALUES (16,"Peter",15);
mysql> show variables like '%iso%';
+-----------------------+----------------+
| Variable_name         | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+

    构建隐式锁

    Session A

    mysql> START TRANSACTION;
mysql> DELETE FROM t1 WHERE id = 8;

mysql> SELECT
    ->     ENGINE_TRANSACTION_ID AS TRX_ID,
    ->     INDEX_NAME,LOCK_TYPE,
    ->     LOCK_MODE, LOCK_STATUS,
    ->     LOCK_DATA
    ->   FROM performance_schema.data_locks;
+--------+------------+-----------+---------------+-------------+-----------+
| TRX_ID | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+--------+------------+-----------+---------------+-------------+-----------+
|  10317 | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|  10317 | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 8         |
+--------+------------+-----------+---------------+-------------+-----------+

    Session B

    隐式锁转换为显式锁

    继续上述两个Sessions的操作：

    Session A

    Session B

    mysql> START TRANSACTION;
mysql> SELECT * FROM t1 WHERE nick = 'Henry' FOR SHARE;
( Waiting )
    ...(Query Locks From performance_schema.data_locks like above)...
+-----------------+------------+-----------+---------------+-------------+------------+
| TRX_ID          | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA  |
+-----------------+------------+-----------+---------------+-------------+------------+
|           10317 | NULL       | TABLE     | IX            | GRANTED     | NULL       |
| 421929568337920 | NULL       | TABLE     | IS            | GRANTED     | NULL       |
|           10317 | uk_n       | RECORD    | X,REC_NOT_GAP | GRANTED     | 'Henry', 8 |
| 421929568337920 | uk_n       | RECORD    | S,REC_NOT_GAP | WAITING     | 'Henry', 8 |
|           10317 | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 8          |
+-----------------+------------+-----------+---------------+-------------+------------+
    (... Abort last statement...)
ERROR 1205 (HY000): Lock wait timeout exceeded; 
try restarting transaction
    ...(Query Locks From performance_schema.data_locks like above)...
+--------+------------+-----------+---------------+-------------+------------+
| TRX_ID | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA  |
+--------+------------+-----------+---------------+-------------+------------+
|  10317 | NULL       | TABLE     | IX            | GRANTED     | NULL       |
|  10321 | NULL       | TABLE     | IS            | GRANTED     | NULL       |
|  10317 | uk_n       | RECORD    | X,REC_NOT_GAP | GRANTED     | 'Henry', 8 |
|  10317 | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 8          |
+--------+------------+-----------+---------------+-------------+------------+

    最后

    一些理解

    “隐式锁”可以理解为，在某些条件下，这里一定是存在“锁”的，所以，既然一定是存在的，并且这类场景可能还比较广泛，那么为了节省存储空间与操作，就省略了此类“锁”的表示。例如，通常，如果事务写入了一条数据，那么该事务一定是持有该数据的排它锁的。

    但，当真的有其他事务也尝试去获取该“隐式锁”的时候，那么为了便于进行锁检测与管理，则会重新将该锁表示出来。并且，也不再有必要重新转化为隐式锁。

    所以，如果有人问，你是否可以把当前数据库的所有的锁情况，都打印或记录下来，这是做不到的，也是没有必要的。事实上，“隐式锁”是广泛存在的，但因为通常并没有那么锁竞争，这些“隐式锁”也就一直不会被表示出来。

    一块拼图

    通常，隐式锁是可以被忽略的，如上述示例，这可能是一个没有任何竞争的锁。但，当出现对应的锁竞争时，则会变得可见。一般地，是可以不用关注隐式锁的，但，如果希望能够对 InnoDB 锁有非常系统的了解，这也是一块重要的“拼图”。

  • 云数据库行业动态@2025-04-11

    ·

    admin

    标题：DBaaS服务商Tessell获 $6000万融资; OceanBase开发者大会几乎5月于广州举行

    重要更新

    多云数据库平台服务商Tessell获 $6000万 容灾。此次融资将用于进一步扩大市场覆盖，并计划推出基于 AI 驱动的对话式数据库管理服务[1]。

    2025 OceanBase开发者大会将于5月17日广州举行。本届大会以「当 SQL 遇见 AI」为主题，会上，OceanBase 还将重磅发布面向 AI 时代的一体化产品矩阵，并分享 TP、AP、KV 及 AI 能力的最新实践成果。[2]

    更新详情

    阿里云
    • PolarDB 库表恢复功能支持恢复速度配置，根据所占用的IOPS越多，实际恢复速度越快。[5]
    • PolarDB 账号管理新增全局只读账号[6]
    Azure(微软云)
    • 适用于基于 vCore 的 Azure Cosmos DB for MongoDB 的 Power BI 连接器发布（预览版）[8]
    • “I/O 性能分析”支持了Azure 虚拟机上的 SQL Server[11]
    GCP(谷歌云)
    • BigQuery 数据准备功能现已正式发布 (GA)，它提供 Gemini 提供的 AI 驱动的数据清理、转换和数据扩充建议。支持使用 Dataform 进行可视化数据准备流程和流程调度。[14]
    • Cloud SQL 现已支持Enterprise Plus 推荐器。根据您的应用程序工作负载和资源利用率，推荐器可以识别升级到 Cloud SQL Enterprise Plus 版本后性能提升情况 [16]
    • BigQuery ML 现已支持以下生成式 AI 函数，可让您使用 Vertex AI Gemini 模型分析文本。[28]
    • BigQuery 迁移评估现已包含对 Amazon Redshift Serverless 的支持 [34]
    • 您现在可以集成 Cloud SQL for MySQL 和 Vertex AI，这允许您使用 Vertex AI 中托管的模型和生成向量嵌入[36]
    • Spanner 现在支持以下 GoogleSQL JSON mutator 函数 [65]
    • Spanner 向量索引和近似最近邻 (ANN) 距离函数（基于 GoogleSQL 方言）现已正式发布 [70]
    • 当您创建 Cloud SQL for SQL Server 实例时，版本SQL Server 2022 Standard 现在是默认版本[71]
    • Langchain 现已支持 Spanner ANN 索引[72]
    Oracle云
    • 性能中心中的 SQL 历史记录支持数据库的SQL执行查看 [73]
    火山云(字节)
    • 数据库传输服务 DTS 支持通过物理备份迁移的方式将本地数据迁移至云数据库 SQL Server 版。[76]
    • DTS 在订阅 MySQL 类型的数据到消息队列 Kafka 版或专有网络 Kafka 进行消费时，支持自定义表投递在 Kafka 中的 Topic。[77]
    百度云
    • PegaDB支持升级小版本[79]
    • PegaDB支持实例重启
    AWS(亚马逊云)
    • RDS for Oracle 支持 BYOL 的 m6id 和 r6id 实例类[80]
    • RDS 在数据库预览环境中支持 MariaDB 11.8[81]
    • Bedrock 知识库现在支持 Aurora PostgreSQL 和 MongoDB Atlas 矢量存储的混合搜索[82]
    • 宣布推出 Amazon ElastiCache for Memcached 的水平自动扩展功能[84]
    • Aurora PostgreSQL 支持 pgvector 0.8.0[90]
    • Amazon Neptune 宣布提供 99.99% 可用性服务等级协议[96]
    腾讯云
    • TDSQL-C MySQL 、云数据库 MySQL 针对数据库审计进行了如下优化。审计日志文件列表，增加生成进度展示。[108]
    • TDSQL-C MySQL 版发布可用区迁移功能，当集群的业务区域需要迁移时，通过可用区迁移可快速实现。[110]
    • TDSQL-C MySQL 版数据库审计支持日志投递至 Ckafka 消息队列，可采集实例的数据库审计日志[111]
    • 云数据库 SQL Server 监控功能更新：新增监控指标：“闩锁等待延迟”、“每秒锁超时次数”、磁盘队列长度等[113]

    参考链接

  • 云数据库RDS MySQL性能测试与对比@2025年04月

    ·

    admin

    本文是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，最新的测试：云数据库RDS MySQL的性能。

    Sysbench QPS 详细数据

    dataaliyunawsazurebaidugooglehuaweioracletencent
    467491657141717761655275329876118
    8948333042820326028954989500411196
    161453363955418609452069263734319249
    322208212295964610483742715601788130337
    4827974162951251113599848219787758334849
    6433061177041513716364920921697762635951
    9635588208431866919334965922855825734147
    12838226223112096420061970422303804634271
    192401352253023274209601045623323780637142
    256401902236924643214121063823572785338175
    384419142209725153211041050623785800939298
    512415962179325700212791076823910838138840

    Latency (Event) 详细数据

    如下表格分别为：平均延迟 和 95%延迟数据。单位为：毫秒/ms。

    dataaliyunawsazurebaidugooglehuaweioracletencent
    410.6743.4450.8240.5443.5026.1524.1011.77
    815.1843.5751.0644.1749.7328.8628.7712.86
    1619.8245.0353.1547.2555.3231.0939.2214.96
    3226.0846.8559.7054.9477.5436.9273.0818.99
    4830.8853.0269.0563.53101.8443.66113.9324.79
    6434.8465.0676.1070.40125.0753.09151.0332.04
    9648.5582.9092.5489.37178.8875.60209.2550.60
    12860.27103.25109.87114.84237.39103.29286.2967.22
    19286.10153.37148.44164.86330.38148.15442.4993.04
    256114.65205.96186.90215.17433.06195.43586.49120.68
    384164.88312.70274.71327.48657.65290.43862.47175.84
    512221.51422.68358.43432.99855.41385.231098.68237.15
    dataaliyunawsazurebaidugooglehuaweioracletencent
    413.4646.6358.9256.8457.8731.3736.2413.46
    816.4146.6361.0861.0875.8234.9541.8515.00
    1620.0051.0264.4766.8490.7837.5669.2918.28
    3228.1653.8577.1980.03144.9744.98116.8025.28
    4862.1964.47104.8494.10189.9353.85176.7333.72
    64108.6878.60130.13102.97223.3470.55262.6445.79
    96155.8099.33167.44132.49277.21121.08325.98134.90
    128183.21132.49193.38170.48350.33144.97427.07150.29
    192227.40219.36240.02240.02475.79215.44623.33170.48
    256325.98287.38297.92303.33623.33308.841050.76196.89
    384411.96434.83458.96442.73926.33539.712539.17248.83
    512539.71569.67580.02580.021191.92559.502880.27320.17

    MySQL 参数对比表格

    dataaliyunawsazurebaidugooglehuaweioracletencent
    have_sslDISABLEDYESYESDISABLEDYESDISABLEDYESDISABLED
    innodb_buffer_pool_size9.75GB11GB24GB12GB11GB9GB17GB12GB
    innodb_doublewriteONOFFOFFONONONONON
    innodb_flush_log_at_trx_commit11111111
    innodb_flush_methodO_DIRECTO_DIRECTfsyncfsyncO_DIRECTO_DIRECTO_DIRECTO_DIRECT
    innodb_io_capacity200002002002000500012000125020000
    innodb_read_io_threads44NA84424
    innodb_write_io_threads44NA84444
    log_binONOFFONONONONONON
    performance_schemaOFFOFFONOFFONOFFONOFF
    rpl_semi_sync_master_enabledONNANAONNAONNAON
    rpl_semi_sync_master_timeout1000NANA10000NA10000NA10000
    sync_binlog11110001111
    thread_pool_size8NA8NANANA164
    version8.0.368.0.408.0.40-azure8.0.32-2.0.0.28.0.37-google8.0.28-2310038.0.40-u3-cloud8.0.30-txsql
    instance_typemysql.x4.large.2cdb.m6i.xlargeGP_Standard_D8ads_v54db-custom-4-16384rds.mysql.x1.xlarge.4.haMySQL.44c
    storage_typecloud_essdio1NAcloud_enhaNACLOUDSSDNAEXCLUSIVE
    storage_size100100100100100100100100
    storage_iopsNA30003000NANANANANA
    cpu_capacity172.3110.9139.873.846.4162.686.8128.5