MySQL默认隔离级别为什么是RR
曾多次听到“MySQL为什么选择RR为默认隔离级别”的问题,其实这是个历史遗留问题,当前以及解决,但是MySQL的各个版本沿用了原有习惯。历史版本中的问题是什么,本次就通过简单的测试来说明一下。
1、 准备工作
1.1 部署主从
部署一套主从架构的集群,创建过程较简单,可以参考历史文章部署 MySQL主从复制搭建 部署一主一从即可。
1.2 创建测试表及数据
在主库中创建表及测试数据
mysql> create table users(id int primary key auto_increment,user_name varchar(20),c_id tinyint(4),c_note varchar(50),key c_id(c_id)) engine=innodb;
Query OK, 0 rows affected (0.01 sec) mysql> insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0 mysql> create table class(c_id int primary key ,c_name varchar(1),c_note varchar(50)) engine=innodb;
Query OK, 0 rows affected (0.00 sec) mysql> insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 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:3306 12:14:27>truncate table users;
Query OK, 0 rows affected (0.08 sec) root@testdb:3306 12:14:29>truncate table class;
Query OK, 0 rows affected (0.04 sec) root@testdb:3306 12:14:50>insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙 权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0 root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 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 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.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); |
2 | delete from class where c_id=2; |
3 | update users set c_note='t2' where c_id in (select c_id from class); |
与主库执行的顺序是一致的,因此,主从的结果是一致的。
3、 RC隔离级别
3.1 ROW格式
为了和之前的步骤一致,先初始化数据
root@testdb:3306 12:14:27>truncate table users;
Query OK, 0 rows affected (0.08 sec) root@testdb:3306 12:14:29>truncate table class;
Query OK, 0 rows affected (0.04 sec) root@testdb:3306 12:14:50>insert into users values(1,'刘备',2,null),(2,'曹操',1,null),(3,'孙 权',3,null),(4,'关羽',2,null),(5,'司马懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0 root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吴',null),(4,'晋','');
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 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 A | SESSION 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组合下数据的操作,否则将报如下错误:
Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.
因此单纯根据步骤讲解
步骤 | SESSION A | SESSION 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; |
|
3 | mysql>update users set c_note='t2' where c_id in (select c_id from class); | |
4 | commit; |
因为binlog是按照commit时间的顺序保存,因此上述步骤在binlog里会以如下顺序存储:
binlog里的顺序 | 语句内容 |
1 |
delete from class where c_id=2; |
2 | update users set c_note='t1' where c_id in (select c_id from class); |
3 | update 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(会带来更多的锁等待),具体可以视情况选择。
reapeatable read
MySQL默认隔离级别为什么是RR的更多相关文章
- MySQL 中隔离级别 RC 与 RR 的区别
1. 数据库事务ACID特性 数据库事务的4个特性: 原子性(Atomic): 事务中的多个操作,不可分割,要么都成功,要么都失败: All or Nothing. 一致性(Consistency): ...
- InnoDB在MySQL默认隔离级别下解决幻读
1.结论 在RR的隔离级别下,Innodb使用MVVC和next-key locks解决幻读,MVVC解决的是普通读(快照读)的幻读,next-key locks解决的是当前读情况下的幻读. 2.幻读 ...
- mysql事务隔离级别和MVCC
一.三种问题: 脏读(Drity Read):事务A更新记录但未提交,事务B查询出A未提交记录. 不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致,这可能是两次 ...
- 查询mysql事务隔离级别
查询mysql事务隔离级别 查询mysql事务隔离级别 分类: DB2011-11-26 13:12 2517人阅读 评论(0) 收藏 举报 mysqlsessionjava 1.查看当前会话隔离 ...
- mysql 数据库隔离级别
select @@tx_isolation; 4种隔离级别 1.read uncommitted 2.read committed 3.repeatable read(MySQL默认隔离级别) 4. ...
- 查询和设置mysql事务隔离级别
1.查看当前会话隔离级别 select @@tx_isolation; 2.查看系统当前隔离级别 select @@global.tx_isolation; 3.设置当前会话隔离级别 set sess ...
- Mysql事务隔离级别和锁机制
一.Spring支持四种事务隔离级别: 1.ISOLATION_READ_UNCOMMITTED(读未提交):这是事务最低的隔离级别,它充许令外一个事务可以看到这个事务未提交的数据. 2.ISOLAT ...
- 【不错】MySQL 事务隔离级别
一.事务描述 1.事务的四个特性 ACID 1. A:原子性 = 一个事务或者都成功.或者都失败: 2. C:一致性 = 在整个事务的生命周期里面,查询到的数据是一致的: MVCC多版本并发控制:利用 ...
- mysql的默认隔离级别
原文:https://www.cnblogs.com/rjzheng/p/10510174.html 知识点总结 ------------------------------------------- ...
随机推荐
- Canvas 使用及应用
Canvas canvas 是 HTML5 当中我最喜欢的所有新特性中我最喜欢的一个标签了.因为它太强大了,各种有意思的特效都可以实现. 1. canvas 的基本使用方法 - 它是一个行内块元素 - ...
- JS 增删改查操作XML
效果图: <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <titl ...
- 三个值得期待的JavaScript新功能!
让我们来看看JavaScript中一些有用的即将推出的功能.您将看到他们的语法,链接以及时了解他们的进度,我们将编写一个小型测试套件,以展示如何立即开始使用这些提案! JavaScript是如何更新迭 ...
- 对JS中事件委托的理解
什么是事件委托: 事件委托——给父元素绑定事件,用来监听子元素的冒泡事件,并找到是哪个子元素的事件.(不理解冒泡的可以去百度下) 定义:利用事件冒泡处理动态元素事件绑定的方法,专业术语叫事件委托. 使 ...
- 【猫狗数据集】pytorch训练猫狗数据集之创建数据集
猫狗数据集的分为训练集25000张,在训练集中猫和狗的图像是混在一起的,pytorch读取数据集有两种方式,第一种方式是将不同类别的图片放于其对应的类文件夹中,另一种是实现读取数据集类,该类继承tor ...
- JavaScript对象(一)
Part One:对象的创建对象的创建,可以使用new Object() 或者 Object.creat(),该方法为静态函数 var foo = Object.create({x:1,y:2}); ...
- 字符串、bute[]数组和十六进制字符串的相互转换
1.字符串转换成十六进制字符串 public static String str2HexStr(String str) { if (EncodingUtil.isEmpty(str)) { retur ...
- 三星最先进EUV产线投用
近日,三星宣布,在韩国华城工业园新开一条专司 EUV(极紫外光刻)技术的晶圆代工产线 V1,最次量产 7nm. 据悉,V1 产线/工厂 2018 年 2 月动工,2019 年下半年开始测试晶圆生产,首 ...
- Java安装和配置
一. Java安装和配置 1.JDK下载地址: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-21331 ...
- AndroidStudio提高编译速度的几种方法
第一种: 减少依赖库的使用,让代码更加精简.对于一些必须依赖的库要尽量使用jar包或者依赖库,这样他每次就会在本地直接加载,而不是每次翻墙检查更新 第二种: 打开Android Studio,选择菜单 ...