MySQL Binlog 【ROW】和【STATEMENT】选择(转)
前言：
二进制日记录了数据库执行更改的操作，如Insert，Update，Delete等。不包括Select等不影响数据库记录的操作，因为没有对数据进行修改。二进制主要的功能有：复制（Replication）和恢复（Recovery）。具体的二进制里面的格式表示的意思请见这篇文章。
MySQL记录的日志有三种模式：STATEMENT、ROW、MIXED，这3个到底有什么区别呢？对Replication有什么区别呢？本文开始进行一些说明，如有遗漏请大家补充。
一，大小：日志产生量。
Client1:
Client2:
Client3:
除了binlog_format不一样之外，其他都是一样的。先看下事务操作的日志大小（物理）。删除数据：
delete from me_info where id < 2153269;
查看他们日志的大小：发现ROW 和 其他2个大小不一致，而MIXED和STATEMENT一致。通过mysqlbinlog 发现他们记录的格式ROW不同于STATEMENT和MIXED。
-rw-rw---- 1 mysql adm 3.7M 2012-12-31 16:19 mysql-bin.000001
-rw-rw---- 1 mysql adm 207 2012-12-31 16:19 mysql-bin2.000001
-rw-rw---- 1 mysql adm 207 2012-12-31 16:19 mysql-bin3.000001
小结1：
通过上面的说明得出一点是ROW格式比MIX和STATEMENT要大，原因是ROW记录的是记录更新后的值（不需要记录上下文信息），而其他2个模式记录的只是一个逻辑的SQL语句（需要记录上下文信息），具体格式可以看这里的ROW日志信息。因为上面的表删除了3W的记录，ROW模式会记录每一条删除语句，所以日志会很大。这也说明将格式设置成ROW，对于磁盘空间的要求增加了，而复制采用传输二进制日志方式实现的，所以复制的网络开销也有增加。所以最后的结果是：ROW>STATEMENT=MIXED
二，复制：对复制产生的影响
表：
root@127.0.0.1 : rep_test 05:38:06>desc user;
+---------------+--------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------------------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| username | varchar(20) | NO | UNI | | |
| status | int(4) | YES | MUL | NULL | |
…………………………………………
…………………………………………
…………………………………………
+---------------+--------------+------+-----+---------------------+----------------+
42 rows in set (0.03 sec)
1，磁盘IOPS，网卡流量，cpu:
一个更新脚本，更新一个字符串字段。
import MySQLdb
from random import choice
from random import randint
def get_str(n):
A=''
for i in range(n):
A=A+chr(97+randint(0,25))
return A if __name__ =='__main__':
pwd = get_str(16)
conn = MySQLdb.connect(host='localhost',user='root',passwd='123456',charset='utf8',db='rep_test')
for i in xrange(1000000):
query ="update user set password = '%s' where id =%d" %(pwd,i)
cursor = conn.cursor()
cursor.execute(query)
print query
print 'OK'
执行脚本,查看网卡流量：{iftop、ifstat、dstat -N eth0 }
STATEMENT下主从的情况：
STATEMENT
-rw-rw---- 1 mysql adm 128M 2013-01-15 09:29 mysql-bin.000001
主：
----total-cpu-usage---- -dsk/total- --net/eth0- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
50 16 31 0 0 2| 0 0 | 362k 1184k| 0 0 | 12k 48k
45 15 37 2 0 2| 0 6892k| 196k 1041k| 0 0 | 11k 45k
58 20 21 0 0 2| 0 0 | 332k 1088k| 0 0 | 10k 46k
52 17 31 0 0 2| 0 0 | 353k 1122k| 0 0 | 12k 45k
52 19 28 0 0 2| 0 84k| 308k 1032k| 0 0 | 10k 42k
50 17 31 0 0 2| 0 0 | 360k 1171k| 0 0 | 12k 47k
44 17 33 4 0 1| 0 9560k| 350k 1092k| 0 0 | 11k 44k
49 18 31 0 0 2| 0 0 | 355k 1111k| 0 0 | 11k 46k
47 24 27 0 0 3| 0 0 | 357k 1144k| 0 0 | 11k 48k
64 18 17 0 0 2| 0 76k| 264k 985k| 0 0 |7621 43k
56 16 26 0 0 1| 0 0 | 365k 1146k| 0 0 | 11k 47k
49 16 31 3 0 2|4096B 6820k| 341k 1071k| 0 0 | 10k 44k
51 23 25 0 0 2| 0 0 | 357k 1170k| 0 0 | 11k 48k
56 17 25 0 0 1| 0 0 | 334k 1068k| 0 0 | 11k 44k
50 15 32 1 0 3| 0 2132k| 375k 1170k| 0 0 | 12k 47k
46 18 33 0 0 2| 0 2048k| 374k 1180k| 0 0 | 12k 47k
59 16 23 0 0 2| 0 0 | 362k 1168k| 0 0 | 10k 49k
48 13 29 9 0 1|4096B 12M| 271k 889k| 0 0 |8581 37k
48 19 32 0 0 2| 0 0 | 385k 1209k| 0 0 | 12k 49k
59 18 21 0 0 2| 0 92k| 311k 1022k| 0 0 |8799 44k
47 20 31 0 0 2| 0 0 | 375k 1190k| 0 0 | 12k 48k
50 18 30 0 0 3| 0 0 | 313k 1086k| 0 0 | 10k 44k
59 19 20 0 0 3| 0 16k| 360k 1134k| 0 0 |9620 48k 从：
----total-cpu-usage---- -dsk/total- --net/eth0- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
64 12 18 0 0 6| 0 512B|1204k 381k| 0 0 | 19k 16k
48 14 33 0 0 6| 0 0 |1134k 357k| 0 0 | 17k 16k
30 18 46 0 0 6| 0 0 |1070k 319k| 0 0 | 13k 14k
45 18 34 0 0 4| 0 0 |1069k 326k| 0 0 | 13k 15k
70 11 15 0 0 3| 0 33k|1156k 363k| 0 0 | 12k 15k
42 12 43 0 0 3| 0 512B|1092k 338k| 0 0 | 14k 17k
34 16 46 0 0 4| 0 0 |1195k 349k| 0 0 | 15k 17k
56 11 14 15 0 5| 0 52M| 973k 177k| 0 0 |7848 7420
69 10 16 0 0 5| 0 0 |1107k 352k| 0 0 | 12k 15k
31 14 49 0 0 5| 0 41k|1066k 316k| 0 0 | 13k 16k
39 18 39 0 0 4| 0 512B|1117k 340k| 0 0 | 13k 15k
60 13 20 0 0 7| 0 0 |1105k 349k| 0 0 | 17k 14k
61 14 18 1 0 7| 0 9216B|1189k 377k| 0 0 | 18k 15k
32 12 52 0 0 5| 0 0 |1109k 344k| 0 0 | 15k 17k
34 20 42 0 0 4| 0 33k|1068k 319k| 0 0 | 13k 14k
63 14 17 0 0 6| 0 512B|1063k 304k| 0 0 | 15k 12k
61 10 22 0 0 7| 0 0 |1071k 340k| 0 0 | 17k 14k
36 19 42 0 0 4| 0 0 |1141k 354k| 0 0 | 15k 18k
26 17 53 0 0 4| 0 0 |1125k 347k| 0 0 | 15k 18k
58 15 18 1 0 8| 0 141k|1119k 347k| 0 0 | 17k 14k
62 12 18 0 0 7| 0 512B|1173k 374k| 0 0 | 18k 15k
33 17 43 0 0 6| 0 0 |1182k 367k| 0 0 | 17k 19k
27 15 55 0 0 3| 0 0 | 889k 273k| 0 0 | 12k 14k
从上面信息可以看出：产生了128M的二进制日志，在复制期间，Master网卡出去（send）流量平均1M左右，Slave网卡接收（recv）流量平均1M左右，Master的CPU空闲30左右，Slave的CPU空闲30~40，磁盘读写都比较小。
ROW下主从的情况：
ROW:
-rw-rw---- 1 mysql adm 706M 2013-01-15 09:37 mysql-bin.000002
主：
----total-cpu-usage---- -dsk/total- --net/eth0- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
53 20 25 0 0 2| 0 4096k| 189k 4376k| 0 0 | 11k 43k
55 16 29 0 0 1| 0 8176k| 232k 4644k| 0 0 | 12k 45k
64 19 13 1 0 2| 0 5548k| 234k 3379k| 0 0 |7497 36k
50 19 26 3 0 3| 0 26M| 322k 4692k| 0 0 | 12k 47k
52 19 27 0 0 2| 0 0 | 311k 4638k| 0 0 | 12k 46k
52 18 28 0 0 1| 0 0 | 276k 4157k| 0 0 | 10k 42k
55 20 24 0 0 2| 0 0 | 308k 4353k| 0 0 | 11k 44k
57 16 23 2 0 1|4096B 4624k| 262k 3772k| 0 0 |9495 39k
47 16 29 7 0 2| 0 21M| 229k 3982k| 0 0 | 10k 40k
54 14 31 1 0 1| 0 16k| 296k 4572k| 0 0 | 12k 45k
50 20 29 0 0 2| 0 0 | 322k 4595k| 0 0 | 12k 44k
54 15 31 0 0 1| 0 0 | 308k 4461k| 0 0 | 11k 45k
58 20 20 0 0 1| 0 0 | 154k 4133k| 0 0 |8725 43k
58 16 23 1 0 2| 0 60k| 293k 4133k| 0 0 |9969 42k
59 16 24 0 0 2| 0 4096k| 283k 4388k| 0 0 | 11k 44k
50 18 30 0 0 3| 0 4096k| 184k 4681k| 0 0 | 12k 46k
50 19 28 1 0 1| 0 4072k| 306k 4716k| 0 0 | 12k 46k
53 19 27 0 0 2| 0 31M| 329k 4701k| 0 0 | 12k 47k
51 19 28 1 0 2| 0 100k| 306k 4560k| 0 0 | 12k 45k
50 17 31 0 0 2| 0 0 | 307k 4587k| 0 0 | 12k 45k
53 19 26 1 0 2| 0 28k| 279k 4120k| 0 0 | 10k 42k
52 16 30 0 0 2| 0 0 | 323k 4628k| 0 0 | 12k 46k
47 17 28 9 0 1|4096B 26M| 106k 3751k| 0 0 |8305 39k 从：
----total-cpu-usage---- -dsk/total- --net/eth0- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
71 19 7 0 0 4| 0 0 |4635k 319k| 0 0 | 12k 13k
53 18 24 0 0 4| 0 0 |3844k 264k| 0 0 | 15k 21k
47 31 12 0 0 10| 0 178k|4710k 173k| 0 0 | 16k 16k
58 27 8 0 0 7| 0 0 |4332k 180k| 0 0 | 14k 11k
60 12 25 0 0 3| 0 25k|2918k 206k| 0 0 | 11k 9933
49 19 28 0 0 4| 0 0 |4200k 292k| 0 0 | 22k 29k
33 28 35 0 1 3| 0 0 |4434k 297k| 0 0 | 26k 37k
48 25 21 0 0 6| 0 33k|4238k 283k| 0 0 | 18k 24k
67 14 16 0 0 3| 0 0 |3682k 254k| 0 0 |9446 12k
43 24 30 0 0 4| 0 0 |4461k 305k| 0 0 | 23k 33k
32 29 35 0 0 4| 0 0 |4273k 293k| 0 0 | 27k 40k
58 21 17 0 0 4| 0 0 |4012k 275k| 0 0 | 14k 20k
67 16 14 0 0 3|4096B 161k|4135k 285k| 0 0 | 11k 13k
39 34 21 0 0 6| 0 0 |4255k 185k| 0 0 | 17k 20k
40 32 13 8 0 7| 0 26M|4198k 164k| 0 0 | 15k 14k
77 18 0 0 0 5| 0 0 |4560k 277k| 0 0 | 11k 9888
57 20 16 0 0 7| 0 0 |4707k 328k| 0 0 | 17k 22k
35 29 31 0 1 4| 0 33k|4571k 298k| 0 0 | 26k 36k
40 18 38 0 0 4| 0 0 |3493k 203k| 0 0 | 15k 18k
56 5 1 36 0 2| 0 96M|1607k 44k| 0 0 |5375 7012
57 23 16 0 0 4| 0 11M|6747k 149k| 0 0 | 18k 20k
31 31 34 0 0 4| 0 0 |4691k 314k| 0 0 | 27k 39k
48 24 22 0 0 5| 0 45k|4471k 286k| 0 0 | 19k 22k
64 16 12 0 0 8| 0 0 |4607k 319k| 0 0 | 17k 16k
47 22 27 0 0 4| 0 5120B|4295k 293k| 0 0 | 21k 27k
47 32 12 0 0 8| 0 0 |4645k 194k| 0 0 | 17k 17k
从上面信息可以看出：产生了706M的二进制日志，在复制期间，Master网卡出去（send）流量4M~5M，Slave网卡接收（recv）流量4M~5M，Master的CPU空闲20~30，Slave的CPU空闲20左右，磁盘读写也不算大。
对比Row和Statement：R比S产生的日志量大5.5倍，网卡流量高4~5倍，cpu稍微忙了10个百分点。在复制过程中，从均没有延迟。因为SQL过滤条件WHERE 后面的字段利用好索引，ROW和STATEMENT模式下效果一样。要是没有利用好索引，则：
STATEMENT下：在主上执行（3~5s）一条，从上也是需要这个时间，并且出现延迟。（Seconds_Behind_Master）。本来就单线程的，导致从的可用性更差。
ROW下：在主上执行（3~5s）一条，正常情况下每张表都有主键，所以按照ROW的记录的SQL格式，不会出现对这类sql的延迟。除非极端情况下更新一张没有主键甚至没有任何索引的表。
范围内的批量更新结果怎么样?【update user set password = 'serqrnncavfyozeu' where id > 0 and id < 1000000】
STATEMENT下主从的情况：
ROW下主从的情况：
对比发现：在执行此类sql的时候，在STATEMENT下面，（利用好索引）主和从的各个开销都很小，网络流量都不大。而在ROW下面：因为日志产生量就很大，导致在复制期间网卡流量就很大：12M。网卡流量：【1：10000】，日志大小：【1：2000000】，CPU空闲：【80：20】。这个只限于这个例子，看范围大小和表字段的大小。总之在网络和磁盘开销上面比较，他们差距了好几个数量级。
小结2：
对于更新单条的sql语句，在STATEMENT和ROW下
1，CPU消耗差距不大，都需要执行这么sql。消耗 R=S
2，磁盘写和网络传输上，因为ROW记录的格式的原因。消耗 R>S
3，SQL效率来看，合理利用索引的更新，效率差距不大，不合理利用索引的更新，效率 R>S
4，日志文件大小上，因为都需要记录这么多SQL，但是由于R和S的记录格式不一样，大小 R>S
对于执行一个大范围的sql语句，在STATEMENT和ROW下
1，CPU上，主上只要执行一条SQL，而从上需要执行N条，消耗 R>S
2，磁盘写和网络传输上，因为ROW记录的格式的原因。消耗R>S，看范围条件，大的话，差距巨大。
3，日志文件大小上，主记录一条，从记录N条，并且还由于R和S的记录格式不一样，R>S，差距巨大。
从上面的分析得出，STATEMENT要比ROW划算。要是使用STATEMENT没有任何问题的话，就推荐使用STATEMENT/MIXED格式记录二进制日志。
2，数据的一致性:
其实ROW有很多一些好处。特别对数据的一致性有了很严的要求。
情况1：
更新主上有的数据，但从上没有：在STATEMENT/MIXED下，复制正常，没有报错。而在ROW下，复制终止。
情况2：和ROW记录的格式有关
主从上的字段属性不一样，在STATEMENT/MIXED下，不受影响，复制正常，而在ROW下，复制报错。varcar <=> char
主从上的字段长度不一样，在STATEMENT/MIXED下，不受影响，复制正常，而在ROW下，复制报错。varchar(10) <=> varchar(20)
对于情况2，在5.1里面没有办法自动处理复制的错误，但是在5.5版本中增加了一个参数控制：slave_type_conversions
ALL_LOSSY：仅支持有损转换，比如一个值本来是bigint存储为9999999999999，现在转换为int类型势必会要截断从而导致数据不一致。
ALL_NON_LOSSY：仅支持无损转换，只能在无损的情况下才能进行转换
ALL_LOSSY,ALL_NON_LOSSY：有损/无算转换都支持
空，即不设置这个参数：必须主从的字段类型一模一样。
表示允许相同类型字段、长度不同，否则默认为空，会导致主从停止
zjy@localhost : test 01:52:45>show variables like 'slave_type%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| slave_type_conversions | |
+------------------------+-------+ zjy@localhost : test 01:53:00>set global slave_type_conversions ='ALL_LOSSY,ALL_NON_LOSSY';
Query OK, 0 rows affected (0.00 sec) zjy@localhost : test 01:53:30>show variables like 'slave_type%';
+------------------------+-------------------------+
| Variable_name | Value |
+------------------------+-------------------------+
| slave_type_conversions | ALL_LOSSY,ALL_NON_LOSSY |
+------------------------+-------------------------+
在从上修改了之后，情况2的复制报错不会再出现。
目前只发现这2个，后期发现再补充进来。
小结3：
对于ROW和STATEMENT的复制，ROW在数据的一致性上面要求更好，从库要是提供服务，最好把复制模式改成ROW。
3，复制下的各种情况:可以参考这篇文章
对于ROW和STATEMENT下的存储过程，函数，触发器，事件的记录方式有什么区别呢？结果：
触发器（TRIGGER）：
ROW
主上有，从上没有，复制正常，数据正常。
主上有，从上也有，复制正常，数据正常。 STATEMENT/MIXED
主上有，从上没有，复制正常，数据不正常，触发器里面的sql语句没有执行。
主上有，从上也有，复制正常，数据正常。 函数（FUNCTION）：
ROW
主上有，从上没有，复制正常，数据正常。日志里记录的是UDF转换过的结果。
主上有，从上也有，复制正常，数据正常。 STATEMENT/MIXED
主上有，从上没有，复制报错。从不识别UDF函数。
主上有，从上也有，复制正常，数据正常。 存储过程（STORED PROCEDURES）
ROW
主上有，从上没有，复制正常，数据正常。记录的不是call sp，而是SP里面的sql。
主上有，从上也有，复制正常，数据正常。 STATEMENT/MIXED
主上有，从上没有，复制正常，数据正常。记录的不是call sp，而是SP里面的sql。
主上有，从上也有，复制正常，数据正常。 事件（event）：
ROW
主上有，从上没有，复制正常，数据正常。记录的不是计划，而是EVENT里面的sql。
主上有，从上也有，复制正常，数据正常。（默认，DISABLE ON SLAVE），ALTER EVENT event_name ENABLE/DISABLE STATEMENT/MIXED
主上有，从上没有，复制正常，数据正常。记录的不是计划，而是EVENT里面的sql。
主上有，从上也有，复制正常，数据正常。（默认，DISABLE ON SLAVE）, ALTER EVENT event_name ENABLE/DISABLE
小结4：
Event最好在主上，其他的都可以在主从上同时存在，要是人为的操作数据库而修改模式（R-S）也不会出现问题，更能确保数据的一致性。
对于【小结2】和【小结3】，说明了ROW和STATEMENT的各自优势，下面这个功能更能体现出ROW的优势。
总结：
经过上面的分析，到底是使用ROW好还是STATEMENT好？这个需要权衡， 在【小结2】中：
更新一个大范围的SQL，针对STATEMENT没有什么疑问。对比ROW，其磁盘写和网卡流量以及CPU消耗都比较大，特别是一大个范围的sql语句，差距很大，这时候用STATMENT相对来说更好，因为在利用好索引的前提下，STATEMENT更划算。如上面的例子。
更新小数据，比如每次sql更新一条或则几条，ROW和STATMENT差距不是很大。虽然有几倍的差距，但是这些影响对目前的设备来讲也没任何压力。而且利用ROW之后，可以使没有利用好索引的sql，在从上能更好的执行，并且更能保证主从数据的一致性，更诱人的是ROW下可以实现误操作回退的功能。
所以权衡下，有大范围的更新（一般线上很少），人为的去执行，在执行前，把当前session设置成STATEMENT，其余的都用ROW。这样就避免了上面所说的情况。要是线上有这类操作的话，可以让程序先执行 ：
set session binlog_format=mixed;
MySQL Binlog 【ROW】和【STATEMENT】选择(转)的更多相关文章
- mysql binlog_format row and Statement 比较
两种模式的对比: Statement 优点 历史悠久,技术成熟: 产生的 binlog 文件较小: binlog 中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况: binlog 可以用于 ...
- MySQL Binlog Mixed模式记录成Row格式
背景: 一个简单的主从结构,主的binlog format是Mixed模式,在执行一条简单的导入语句时,通过mysqlbinlog导出发现记录的Binlog全部变成了Row的格式(明明设置的是Mixe ...
- Mysql Binlog 三种格式介绍及分析
一．Mysql Binlog格式介绍 Mysql binlog日志有三种格式,分别为Statement,MiXED,以及ROW! 1.Statement:每一条会修改数据的sql都会记录在 ...
- Mysql Binlog日志详解
一．Mysql Binlog格式介绍 Mysql binlog日志有三种格式,分别为Statement,MiXED,以及ROW! 1.Statement:每一条会修改数据的sql都会记录在 ...
- MySQL binlog相关分析
1.redolog.binlog的简单分析 图解:redolog和binlog机制 2.开启binlog及关注点 3.关注binlog的相关参数 4.binlog模式分析 5.关于binlog的使用 ...
- Mysql Binlog三种格式详细介绍
一．MySQL Binlog格式介绍 mysql binlog日志有三种格式,分别为Statement,MiXED,以及ROW! 查看binlog的格式的脚本: 二.binlog 的不同模式有什么区别 ...
- MySQL Binlog详解
MySQL Binlog详解 Mysql的binlog日志作用是用来记录mysql内部增删改查等对mysql数据库有更新的内容的记录(对数据库的改动),对数据库的查询select或show等不会被bi ...
- Mysql Binlog三种格式介绍及分析【转】
一．Mysql Binlog格式介绍 Mysql binlog日志有三种格式,分别为Statement,MiXED,以及ROW! 1.Statement:每一条会修改数据的sql都会记录在 ...
- MySQL Binlog 介绍
Binlog 简介 MySQL中一般有以下几种日志: 日志类型 写入日志的信息 错误日志 记录在启动,运行或停止mysqld时遇到的问题 通用查询日志 记录建立的客户端连接和执行的语句 二进制日志 记 ...
随机推荐
- 把input类型剔出来
<!doctype html public "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...
- 怎么在手机浏览器上访问电脑本地的文件，局域网内，自建WiFi也可以
首先,电脑要有Mysql+Apache+PHP环境,我直接用Wampsever,开启环境后手机和电脑要再同一个局域网内,然后电脑上打开win+R,输入cmd,再输入ipconfig,就可以看着这台的电 ...
- Magento架构师的笔记-----Magento显示当前目录的父分类和子分类的分类名
在Magento目录的分类页面里,希望在左侧导航获取到父分类和子分类,可以用以下方法:打开app/your_package/your_themes/template/catalog/navigatio ...
- 高级iOS开发工程师的面试题
1:CALayer与UIView的区别是什么? 两者最大的区别就是:涂层不会直接渲染到屏幕上: UIView是iOS界面元素的基础,所有界面元素都是继承于它,他的本身全是由CoreAnimation来 ...
- MINIX3 进程通信分析
MINIX3 进程通信分析 6.1MINIX3 进程通信概要 MINIX3 的进程通信是 MINIX3 内核部分最重要的一个部件,我个人认为其实这 是内核中的“内核”,怎么来理解这个概念呢?其实 MI ...
- 《JS高程》对象&原型学习笔记
ECMA-262 把对象定义为:”无序属性的集合,其属性可以包含基本值.对象或者函数.”可以把 ECMAScript 的对象想象成散列表:无非就是一组名值对,其中值可以是数据或函数. 6.1.理解 ...
- sphinx搜索引擎架构图
- 使用Jsoup函数包抓取网页内容
之前写过一篇用Java抓取网页内容的文章,当时是用url.openStream()函数创建一个流,然后用BufferedReader把这个inputstream读取进来.抓取的结果是一整个字符串.如果 ...
- ZOJ 1016 Parencodings
原题链接 题目大意:有两串数字P和W.数组P中,数字P[i]表示第i个右括号之前的左括号个数.数组W中,数字W[i]表示在第i个右括号和与它匹配的左括号之间的右括号的个数(包括本身).给出一个数组P, ...
- urlscan使用详解
0x01 简介与下载 URLScan是集成在IIS上的,可以制约的HTTP请求的安全工具.通过阻止特定的HTTP请求,URLScan安全工具有助于防止潜在的有害的请求到达服务器上的应用. 最新版UR ...