首页 > 问答 > 关键词  > MySQL最新资讯  > 正文

为什么MySQL默认隔离级别是RR

2020-07-02 11:35 · 稿源:数据库干货铺

曾多次听到“MySQL为什么选择RR为默认隔离级别”的问题,其实这是个历史遗留问题,当前以及解决,但是MySQL的各个版本沿用了原有习惯。历史版本中的问题是什么,本次就通过简单的测试来说明一下。

1、 准备工作

1.1 部署主从

部署一套主从架构的集群,创建过程较简单,可以参考历史文章部署MySQL主从复制搭建部署一主一从即可。

1.2 创建测试表及数据

在主库中创建表及测试数据

mysql>createtableusers(idintprimarykeyauto_increment,user_namevarchar(20),c_idtinyint(4),c_notevarchar(50),keyc_id(c_id))engine=innodb;
QueryOK,0rowsaffected(0.01sec)
mysql>insertintousersvalues(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
QueryOK,5rowsaffected(0.00sec)
Records:5Duplicates:0Warnings:0mysql>createtableclass(c_idintprimarykey,c_namevarchar(1),c_notevarchar(50))engine=innodb;
QueryOK,0rowsaffected(0.00sec)
mysql>insertintoclassvalues(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
QueryOK,4rowsaffected(0.00sec)
Records:4Duplicates:0Warnings:0

2、 RR隔离级别

MySQL默认的隔离级别为 RR(Repeatable Read),在此隔离级别下,对比binlog格式为ROW、STATEMENT是否会造成主从数据不一致

2.1 ROW格式

其实不用测试大家也应该对RR级别下ROW格式的binlog有信心,但是,万事皆需实践检验。

步骤说明如下:

  • 步骤1 - 分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RR,binlog为ROW格式)
  • 步骤2 - SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3- SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时无法更新,处于阻塞状态,因为在RR级别下需要保证重复读。达到所等待超时时间后将会报错。
  • 步骤4- SESSION A 提交事务(此步骤也可以在步骤 3 时操作,结果不一样,后续步骤中将采用此方式)
  • 步骤5- SESSION B 重启事务,再次删除class表中 c_id等于 2 的记录,此时提交可以成功了,成功删除了一条记录
  • 步骤6- SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2,有 2 条记录因为c_id不存在与class表中,因此不会更新
  • 步骤7- 分别在SESSON A和SESSION B查看users表中的内容,结果一致
  • 步骤8- 在从库查看users表中的内容,数据与主库一致

具体步骤如下:

步骤SESSION A

SESSION B

1

mysql>show variables like '%iso%';

+-----------------------+-----------------+

| Variable_name | Value |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

mysql>show variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.00 sec)

mysql>show variables like '%iso%';

+-----------------------+-----------------+

| Variable_name | Value |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

mysql>show variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.01 sec)

2

mysql>set autocommit=0;

mysql>update users set c_note='t1' where c_id in (select c_id from class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5 Changed: 5 Warnings: 0

3

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql>delete from class where c_id=2;

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

4

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

5

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql>delete from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

6

mysql>update users set c_note='t2' where c_id in (select c_id from class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3 Changed: 3 Warnings: 0

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

7

mysql>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

mysql>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

8

在从库查看数据

root@testdb:3307 12:02:20>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

2.2 STATEMENT格式

为了和之前的步骤一致,先初始化数据

root@testdb:330612:14:27>truncatetableusers;
QueryOK,0rowsaffected(0.08sec)
root@testdb:330612:14:29>truncatetableclass;
QueryOK,0rowsaffected(0.04sec)
root@testdb:330612:14:50>insertintousersvalues(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
QueryOK,5rowsaffected(0.00sec)
Records:5Duplicates:0Warnings:0root@testdb:330612:15:10>insertintoclassvalues(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
QueryOK,4rowsaffected(0.00sec)
Records:4Duplicates:0Warnings:0

再将binlog日志格式改为STATAMENT格式(全局及会话级都改一下,或者修改全局变量后重新登录也行,当然 只改会话级别的也可以测试),然后 再次进行测试。

步骤说明如下:

  • 步骤1 - 分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RR,binlog为STATENENT格式)
  • 步骤2 - SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3- SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时无法更新,处于阻塞状态,立即进行步骤4
  • 步骤4- SESSION A 在SESSION B执行commit的动作,则SESSION B的删除操作可以执行通过,但注意class表的数据两个SESSION中查看到的是不一样的
  • 步骤5- 此时SESSION B执行commit,否则后面session A 更新数据时也会阻塞。此时如果SESSION A不执行commit,查看class表的结果也是不一样的,如步骤中的情况
  • 步骤6- SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2,另外 2 条记录虽然本此时查看class表中存在对应的c_id,但是不会更新,此时提交事务,然后再次查看class的内容,结果和SESSION B 查看的结果一致了(幻读)
  • 步骤7- 在从库查看users、class表中的内容,数据与主库一致
步 骤SESSION ASESSION B
1

mysql>show variables like '%iso%';

+-----------------------+-----------------+

| Variable_name | Value |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

mysql>show variables like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)

mysql>show variables like '%iso%';

+-----------------------+-----------------+

| Variable_name | Value |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

mysql>show variables like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)

2

root@testdb:3306 12:37:04>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:37:17>update users set c_note='t1' where c_id in (select c_id from class);

Query OK, 5 rows affected, 1 warning (0.00 sec)

Rows matched: 5 Changed: 5 Warnings: 1

3

root@testdb:3306 12:28:25>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:38:06>delete from class where c_id=2;

Query OK, 1 row affected (4.74 sec)

4

root@testdb:3306 12:38:09>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:38:13>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t1 |

| 3 | 孙 权 | 3 | t1 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t1 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 12:39:07>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 2 | 蜀 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

4 rows in set (0.00 sec)

5

root@testdb:3306 12:38:13>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:39:56>select * from class ;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.00 sec)

6

root@testdb:3306 12:52:23>update users set c_note='t2' where c_id in (select c_id from class);

Query OK, 3 rows affected, 1 warning (0.00 sec)

Rows matched: 3 Changed: 3 Warnings: 1

root@testdb:3306 12:52:45>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 2 | 蜀 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

4 rows in set (0.00 sec)

root@testdb:3306 12:52:49>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙 权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.01 sec)

root@testdb:3306 12:53:03>commit;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 12:53:06>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙 权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 12:53:11>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.00 sec)

7

查看从库数据

root@testdb:3307 12:44:22>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.01 sec)

root@testdb:3307 12:57:07>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙 权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

也就是此时主从结果也是一致的,原因在于,binlog里存储的语句顺序如下:

binlog里的顺序语句内容
1

update users set c_note='t1' where c_id in (select c_id from class);

2delete from class where c_id=2;
3update users set c_note='t2' where c_id in (select c_id from class);

与主库执行的顺序是一致的,因此,主从的结果是一致的。

3、 RC隔离级别

3.1 ROW格式

为了和之前的步骤一致,先初始化数据

root@testdb:330612:14:27>truncatetableusers;
QueryOK,0rowsaffected(0.08sec)
root@testdb:330612:14:29>truncatetableclass;
QueryOK,0rowsaffected(0.04sec)
root@testdb:330612:14:50>insertintousersvalues(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
QueryOK,5rowsaffected(0.00sec)
Records:5Duplicates:0Warnings:0root@testdb:330612:15:10>insertintoclassvalues(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
QueryOK,4rowsaffected(0.00sec)
Records:4Duplicates:0Warnings:0

再将binlog日志格式改为STATAMENT格式(全局及会话级都改一下,或者修改全局变量后重新登录也行,当然 只改会话级别的也可以测试),然后 再次进行测试。

步骤说明如下:

  • 步骤1 - 分别查看两个会话中的事务隔离级别及binlog格式(隔离级别均为RC,binlog为ROW格式)
  • 步骤2 - SESSION A 开启事务,更新users 表中c_id字段存在于class表中的记录,结果为 5 条记录均更新,并将c_note内容更新为 t1
  • 步骤3- SESSION B 开启事务,准备删除class表中 c_id等于 2 的记录,此时不会像RR事务隔离级别那样处于阻塞状态,而是可以直接执行通过
  • 步骤4- 此时SESSION A查看class数据还是删除前的,因为session B 暂未提交
  • 步骤5- SESSION B 提交事务,
  • 步骤6- 更新users 表中c_id字段存在于class表中的记录,结果为 3 条记录更新成功,并将c_note内容更新为 t2
  • 步骤7- 在从库查看users、class表中的内容,数据与主库一致
步 骤SESSION ASESSION B
1

root@testdb:3306 01:25:24>show variables like '%iso%';

+-----------------------+----------------+

| Variable_name | Value |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

root@testdb:3306 01:25:36>show variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.01 sec)

root@testdb:3306 01:24:57>show variables like '%iso%';

+-----------------------+----------------+

| Variable_name | Value |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

root@testdb:3306 01:25:39>show variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.00 sec)

2

root@testdb:3306 01:27:55>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 01:28:27>update users set c_note='t1' where c_id in (select c_id from class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5 Changed: 5 Warnings: 0

3

root@testdb:3306 01:26:07>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

root@testdb:3306 01:28:37>delete from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

4

root@testdb:3306 01:28:27>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 2 | 蜀 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

4 rows in set (0.00 sec)

5

root@testdb:3306 01:28:41>commit;

Query OK, 0 rows affected (0.00 sec)

6

root@testdb:3306 01:28:59>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.01 sec)

root@testdb:3306 01:29:13>update users set c_note='t2' where c_id in (select c_id from class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3 Changed: 3 Warnings: 0

root@testdb:3306 01:29:26>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.00 sec)

root@testdb:3306 01:29:31>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙 权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3306 01:29:38>commit;

7

查看从库数据

root@testdb:3307 01:40:32>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

| 1 | 刘备 | 2 | t1 |

| 2 | 曹操 | 1 | t2 |

| 3 | 孙 权 | 3 | t2 |

| 4 | 关羽 | 2 | t1 |

| 5 | 司马懿 | 1 | t2 |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

root@testdb:3307 01:40:35>select * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

| 1 | 魏 | NULL |

| 3 | 吴 | NULL |

| 4 | 晋 | |

+------+--------+--------+

3 rows in set (0.00 sec)

也就是此时主从结果也是一致的。

3.2 STATEMENT格式

因为当前版本已经不支持RC+STATEMENT组合下数据的操作,否则将报如下错误:

Cannotexecutestatement:impossibletowritetobinarylogsinceBINLOG_FORMAT=STATEMENTandatleastonetableusesastorageenginelimitedtorow-basedlogging.InnoDBislimitedtorow-loggingwhentransactionisolationlevelisREADCOMMITTEDorREADUNCOMMITTED.

因此单纯根据步骤讲解

步骤SESSION ASESSION B
1

mysql>set autocommit=0;

mysql>update users set c_note='t1' where c_id in (select c_id from class);

2

mysql>set autocommit=0;

mysql>delete from class where c_id=2;

mysql>commit;

3mysql>update users set c_note='t2' where c_id in (select c_id from class);
4commit;

因为binlog是按照commit时间的顺序保存,因此上述步骤在binlog里会以如下顺序存储:

binlog里的顺序语句内容
1

delete from class where c_id=2;

2update users set c_note='t1' where c_id in (select c_id from class);
3update users set c_note='t2' where c_id in (select c_id from class);

从库通过binlog应用后,最终的结果将导致主库的数据不一样(具体案例后续安装低版本后演示)。

因而,此种场景下很容易导致数据不一样。

4、总结

通过上述的实践,可以发现在RR级别下,binlog为任何格式均不会造成主从数据不一致的情况出现,但是当低版本MySQL使用RC+STATEMENT组合时(MySQL5.1. 5 前只有statement格式)将会导致主从数据不一致。当前这个历史遗漏问题以及解决,大家可以将其设置为RC+ROW组合的方式(例如ORACLE等数据库隔离级别就是RC),而不是必须使用RR(会带来更多的锁等待),具体可以视情况选择。

本文转载自微信公众号【数据库干货铺】。

举报

  • 相关推荐
  • 忆联 Docker+MySQL 流控方案:打造安全高效存储底座,释放 AI 极致性能

    文章探讨了在AI时代背景下,基于Docker部署MySQL数据库的高效解决方案。通过Docker容器化技术,MySQL实现了灵活部署、资源高效利用和稳定隔离性,成为AI应用的首选数据库方案。测试结果显示,采用PCIe5.0企业级SSD配合Namespace技术和QoS优化策略,能精准控制性能偏差在2%以内,在混合读写场景下更可控制在1%以内。该方案显著提升了存储资源管理效率,为AI应用提供稳定可靠的数据存储支持,同时降低企业TCO成本,推动数据价值释放。

  • 再获认可!腾讯云凭借NDR入选Forrester最新研报

    国际权威机构Forrester发布《网络分析与可见性解决方案报告》,腾讯云凭借旗下NDR产品在威胁检测、自动化响应等方面的优势连续第二年入选。报告指出,随着数字化转型深入,企业面临东西向流量攻击、AI驱动攻击等新型威胁,NAV解决方案能提供全网流量实时洞察,快速发现威胁。腾讯云NDR具备检测场景全、响应快、阻断率高等优势,覆盖公有云和线下机房全流量检测,支持2000余项漏洞检测,并采用AI算法提升威胁发现能力。报告建议企业根据规模选择合适的NAV供应商,腾讯云以"云原生接入、全流量检测、全流量可视"三大创新突破,助力企业构建高级威胁防护能力。

  • StarRocks 优化实践:揭秘毫秒级实时分析的三大核心技术

    StarRocks是一款高性能实时分析数据库,通过三大核心技术解决海量数据分析难题:1)向量化执行引擎,采用批处理方式减少CPU开销,支持SIMD指令集加速计算;2)CBO优化器,基于统计信息智能选择最优执行计划,支持复杂查询改写和物化视图优化;3)列式存储结构,结合稀疏索引和Bitmap索引提升I/O效率。其企业级产品镜舟数据库在此基础上增强多租户隔离、RBAC权限控制等特性

  • 微软迈出激进一大步!新账户将默认无密码

    快科技5月2日消息,微软正在加速推进无密码登录的进程,自5月2日起,新注册的微软账户将默认采用无密码模式,不再要求用户设置传统密码。取而代之的是,用户可以使用Passkey(通行密钥)、推送通知和安全密钥等更安全、更便捷的登录方式。微软还对登录界面进行了优化,调整后的界面优先展示无密码和Passkey登录选项,使用户能够更顺畅地完成无密码登录。微软强调,新用户将有多种无密码选项可供选择,且无需设置传统密码,同时,现有用户也可以访问账户设置删除密码,转向无密码登录方式。不过微软仍保留了传统密码设置的选项,用户可以根

  • 7个月ARR 1.2亿美元,昆仑万维靠“短剧+AI”找到了新增长点

    据某头部媒体发布的行业白皮书显示,海外短剧月均用户已达2000-4000万,未来短剧预计将覆盖亿级的海外用户,市场规模或突破百亿美元。正是在这一行业窗口期,昆仑万维以“后来者”姿态切入赛道,却迅速在全球市场中突围,吸引了我

  • Mythik获1500万美元种子轮融资,要成为“东方迪士尼”

    如果取得成功,Mythik 可能引领一个新时代:一个以文化为根、在全球范围受到喜爱的内容创作高峰,让印度以及更广泛的东方世界不再只是内容的消费者,而是登上世界舞台的顶级内容创作者……

  • MYAI密发仪Pro新品闪耀2025美沃斯双展,引领AI一站式养发新风潮

    2025年5月9-11日,2025美沃斯国际医学美容大会将在杭州国际博览中心举行。会前,MYAI品牌携新品"MYAI密发仪Pro"亮相Moly Gala 2025中国时尚美学盛典,斩获"年度最佳新锐品牌"奖项。该产品整合AI头皮检测系统、专家级分型方案定制及光电生物科技,首创"院线检测+个性化定制"一站式头皮健康管理方案。产品采用660nm环形红光和EMS微电流技术,新增1064nm透皮胶原原光技术,并植入太赫兹芯片实现四效合一。MYAI主张"先检测再定制"理念,基于40万头皮样本数据库,通过AI算法提供个性化养发方案。品牌创始人表示将持续推出分型防脱精华矩阵,满足不同用户需求。该产品创新性地将AI科技与专业养发结合,推动行业向智能化、精准化发展。

  • 官宣!店小秘ERP荣膺Wildberries跨境电商核心合作伙伴

    店小秘ERP2025 年 4 月 15 日,“开启万亿蓝海新丝路”——Wildberries跨境电商 2025 中国官宣大会在深圳盛大举办。店小秘ERP凭借卓越的技术服务,获颁Wildberries核心合作伙伴称号!作为俄罗斯及独联体地区TOP1 的电商平台之一,Wildberries跨境电商对合作伙伴的遴选十分严格,此番认证是对店小秘ERP的高度认可。Wildberries卖家借助店小秘ERP,可实现分拨组包、批量打单、自动分配物流�

  • 如何在Cherry Studio中配置MCP工具服务?国内MCP服务有哪些?

    在当今数字化时代,AI助手已成为提升工作效率和创造力的重要工具。CherryStudio作为一个全能的AI客户端,支持多平台,并提供了丰富的功能,如大模型对话、AI绘图和AI翻译等。查看调用参数和返回结果点击MCP状态栏,查看调用参数和返回结果,便于分析结果的可靠性。

  • 镜舟科技基于 StarRocks 构建湖仓一体架构,支撑某大型电网企业国产化升级

    某大型电网企业联合镜舟科技与腾讯云,基于开源分析型数据库StarRocks及腾讯TBDS大数据平台,构建电力行业国产化湖仓一体架构。该项目实现PB级电力数据统一管理,解决数据链路复杂、资源瓶颈、高并发查询等五大挑战,查询性能提升近8600倍。方案采用分层架构:Flink实时数据处理层、TBDS数据湖存储层、StarRocks分析加速层及可视化应用层,完成全栈国产化适配验证,支持业务平滑迁移。通过统一元数据目录和实时入湖机制,形成完整数据处理闭环,为能源行业核心系统国产化升级提供可复制的技术范本。