InnoDB行格式（compact，redundant）对照
InnoDB行格式分两种格式（COMPACT，redundant）默觉得COMPACT compact的存储格式为 首部为一个非NULL的变长字段长度列表，并且是依照列的顺序逆序放置的，当列的长度小于255字节，用1字节表示，若大于255个字节。用2个字节表 示，varchar的最大长度为65535>，由于两个字节为16位，即65535，第二部分是NULL标志位，该位指示了该行是否有NULL值， 实用01表示，无则用00表示。接下去的部分是为记录头信息（record header）固定占用5个字节，最后的部分就是实际存储的每一个列的数据，NULL不占该部分不论什么数据，除了占有NULL标志位，实际存储不占不论什么空间，
另外注意,每行数据除了用户定义的列外，还有两个隐 藏列，事务ID（6字节），会滚指针列（7字节），若INNODB表未定义,Primay key,那么每行会添加�一个6字节的rowid，假设有，怎有4个字节的索引字段。
redundant的存储格式为 首部是一个字段长度偏移列表（每一个字段占用的字节长度及其对应的位移），相同是依照列的顺序逆序放置，当列的长度小于255字节，用1字节表示，若大于 255个字节，用2字节表>示。第二个部分为记录头信息（record header），不同与compact行格式，它的行格式固定占用6个字节，最后的部分就是实际存储的每一个列的数据，NULL不占该部分不论什么数据，可是 char中假设有NULL值则须要占用对应的字节，另外注意,每行数据除了用户定义的列外，还有两个隐藏列，事务ID（6字节），会滚指针列（7字节），
若INNODB表未定义,Primay key,那么每行会添加�一个6字节的rowid，假设有，怎有4个字节的索引字段
问：怎样理解长度偏移列表? 答：长度偏移列表表示每一个文件夹的长度，及其相对的位置。
如今我们来做个实验来详细看下他们的差别
CREATE TABLE test1 (
t1 varchar(10) DEFAULT NULL,
t2 varchar(10) DEFAULT NULL,
t3 char(10) DEFAULT NULL,
t4 varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT
insert into test1 values('a','bb','bb','ccc');
insert into test1 values('d','ee','ee','fff');
insert into test1 values('d',NULL,NULL,'fff');
通过python py_innodb_page_info.py -v /vobiledata/mysqldata/test/test1.ibd分析可知数据页存在00000003页上，一个页有16K，第三页通过十六进制转化为0000C000開始。
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000000, page type <Freshly Allocated Page>
page offset 00000000, page type <Freshly Allocated Page>
Total number of page: 6:
Freshly Allocated Page: 2
Insert Buffer Bitmap: 1
File Space Header: 1
B-tree Node: 1
File Segment inode: 1
通过hexdump -C -v /vobiledata/mysqldata/test/test1.ibd>tes1.txt分析可知
0000bff0 00 00 00 00 00 00 00 00 52 4b 47 ff 63 5e 66 c7 |........RKG.cf.|
0000c000 30 4e 95 ae 00 00 00 03 ff ff ff ff ff ff ff ff |0N..............| 0000c010 00 00 00 50 63 5f 15 76 45 bf 00 00 00 00 00 00 |...Pc_.vE.......|
0000c020 00 00 00 00 15 9c 00 02 00 ef 80 05 00 00 00 00 |................|
0000c030 00 d8 00 02 00 02 00 03 00 00 00 00 00 00 00 00 |................|
0000c040 00 00 00 00 00 00 00 00 36 01 00 00 15 9c 00 00 |........6.......|
0000c050 00 02 00 f2 00 00 15 9c 00 00 00 02 00 32 01 00 |.............2..|
0000c060 02 00 1e 69 6e 66 69 6d 75 6d 00 04 00 0b 00 00 |...infimum......|
0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 00 00 10 00 |supremum........|
0000c080 2c 00 00 0c 84 58 03 00 00 00 62 81 97 80 00 00 |,....X....b.....|
0000c090 00 2d 01 10 61 62 62 62 62 20 20 20 20 20 20 20 |.-..abbbb |
0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b 00 00 0c | ccc........+...|
0000c0b0 84 58 04 00 00 00 62 81 f8 80 00 00 00 2d 01 10 |.X....b......-..|
0000c0c0 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66 |deeee fff|
0000c0d0 03 01 06 00 00 20 ff 98 00 00 0c 84 58 05 00 00 |..... ......X...|
0000c0e0 00 62 82 43 80 00 00 00 2d 01 10 64 66 66 66 00 |.b.C....-..dfff.|
0000c0f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0000c100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0000c110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
我们能够分析上面的数据来看INNODB是怎么存数据的。
存储数据页，在0000c078開始存数据，
03,02,01表示可变字段存储列表(记录可变字段的最长字节)，
00表示记录中没有NUll（如有怎依照null的位置用二进制计算），
00 00 10 00 2c表示记录头信息（规定为5个字节长度），这个头是用来连接联系的记录，也用InnoDB默认使用紧凑（COMPACT）格式
存储数据页，在0000c078開始存数据， 03,02,01表示可变字段存储列表(记录可变字段的最长字节)，
00表示记录中没有NUll（如有怎依照null的位置用二进制计算），
00 00 10 00 2c表示记录头信息（规定为5个字节长度），这个头是用来连接联系的记录，也用于行级锁。
00 00 0c 84 58 03表示rowid，我们没有设置主键，所以（隐藏的六个字节），由此可见，为了降低表空间，我们在设计表是尽量要设置主键。
00 00 00 62 81 97 六个transation ID
80 00 00 00 2d 01 10 七个字节的回滚指针
PS：null不占用空间
我们观察下第三列存的数据：03，01表示第四列和第一列不为空，06表示存在null值，为止在于第二位和第三位，00000110 = 06
接下来我们看下数据被删除后空间的变化情况：
lin_ren@test 12:19:09>select * from test1;
t1 t2 t3
t4
a bb bb
ccc
d ee ee
fff
d NULL
NULL fff
3 rows in set (0.00 sec)
xue_binbin@test 12:27:40>delete from test1 where t1 = 'a';
Query OK, 1 row affected (0.00 sec)
0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 20 00 10 00 |supremum.... ...|
0000c080 00 00 00 0c 84 58 00 00 00 00 63 60 0c 00 00 00 |.....X....c`....|
0000c090 00 33 26 06 61 62 62 62 62 20 20 20 20 20 20 20 |.3&.abbbb |
0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b 00 00 0c | ccc........+...|
0000c0b0 84 58 01 00 00 00 62 7c 94 80 00 00 00 2d 01 1f |.X....b|.....-..|
0000c0c0 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66 |deeee fff|
0000c0d0 03 01 06 00 00 20 ff 98 00 00 0c 84 58 02 00 00 |..... ......X...|
0000c0e0 00 62 7c 94 80 00 00 00 2d 01 2e 64 66 66 66 00 |.b|.....-..dfff.|
0000c0f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
我们发现数据存储没有变化
xue_binbin@test 12:35:01>insert into test1 values('a','bb','bb','ccc');
Query OK, 1 row affected (0.00 sec)
xue_binbin@test 12:35:08>select * from test1;
t1 t2 t3
t4
d ee ee
fff
d NULL
NULL fff
a bb bb
ccc
0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 00 00 10 ff |supremum........|
0000c080 ef 00 00 0c 84 58 0c 00 00 00 63 63 8f 80 00 00 |.....X....cc....|
0000c090 00 2d 01 10 61 62 62 62 62 20 20 20 20 20 20 20 |.-..abbbb |
0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b 00 00 0c | ccc........+...|
0000c0b0 84 58 01 00 00 00 62 7c 94 80 00 00 00 2d 01 1f |.X....b|.....-..|
0000c0c0 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66 |deeee fff|
0000c0d0 03 01 06 00 00 20 ff a9 00 00 0c 84 58 02 00 00 |..... ......X...|
0000c0e0 00 62 7c 94 80 00 00 00 2d 01 2e 64 66 66 66 00 |.b|.....-..dfff.|
由此表明数据空间删除的时候不释放，在等着下一个插入数据时刻，假设插入同样的数据就能够反复利用，假设没有，就有碎片
xue_binbin@test 12:35:13>insert into test1 values('c','aaa','aaa','cc');
Query OK, 1 row affected (0.00 sec)
xue_binbin@test 12:37:24>select * from test1;
0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 00 00 10 00 |supremum........|
0000c080 77 00 00 0c 84 58 0c 00 00 00 63 63 8f 80 00 00 |w....X....cc....|
0000c090 00 2d 01 10 61 62 62 62 62 20 20 20 20 20 20 20 |.-..abbbb |
0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b 00 00 0c | ccc........+...|
0000c0b0 84 58 01 00 00 00 62 7c 94 80 00 00 00 2d 01 1f |.X....b|.....-..|
0000c0c0 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66 |deeee fff|
0000c0d0 03 01 06 00 00 20 ff a9 00 00 0c 84 58 02 00 00 |..... ......X...|
0000c0e0 00 62 7c 94 80 00 00 00 2d 01 2e 64 66 66 66 02 |.b|.....-..dfff.|
0000c0f0 03 01 00 00 00 28 ff 78 00 00 0c 84 58 0d 00 00 |.....(.x....X...|
0000c100 00 63 64 b5 80 00 00 00 2d 01 10 63 61 61 61 61 |.cd.....-..caaaa|
0000c110 61 61 20 20 20 20 20 20 20 63 63 00 00 00 00 00 |aa cc.....|
由此可见，假设插入一条新的数据，则会接着往下空间存
接着我们来看下有主键的情况的INNODB存储情况：
CREATE TABLE te1 (
id int(11) NOT NULL DEFAULT '0',
t1 varchar(10) DEFAULT NULL,
t2 varchar(10) DEFAULT NULL,
t3 char(6) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT
insert into te1 values(1,'aa','bb','bb');
insert into te1 values(2,'cc',NULL，NULL)；
相同的分析数据： 0000c070 73 75 70 72 65 6d 75 6d 02 02 00 00 00 10 00 26 |supremum.......&|
0000c080 80 00 00 01 00 00 00 62 98 e7 80 00 00 00 2d 01 |.......b......-.|
0000c090 10 61 61 62 62 62 62 20 20 20 20 20 20 20 20 02 |.aabbbb .|
0000c0a0 06 00 00 18 ff ca 80 00 00 02 00 00 00 62 99 2e |.............b..|
0000c0b0 80 00 00 00 2d 01 10 63 63 00 00 00 00 00 00 00 |....-..cc.......|
0000c0c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
我们发现假设有主键的话，在头文件（00 00 10 00 26）会有记录索引的信息（全部的记录行80 00 00 01）01表示主键1，将比没有索引的少存一个字节
xue_binbin@test 12:44:05>update te1 set t1 ='cc' where id = 1;
Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
0000c070 73 75 70 72 65 6d 75 6d 02 02 00 00 00 10 00 22 |supremum......."|
0000c080 80 00 00 01 00 00 00 63 68 c3 00 00 00 00 33 0f |.......ch.....3.|
0000c090 a7 63 63 62 62 62 62 20 20 20 20 02 06 00 00 18 |.ccbbbb .....|
0000c0a0 ff ce 80 00 00 02 00 00 00 63 31 07 80 00 00 00 |.........c1.....|
0000c0b0 2d 01 1d 63 63 00 00 00 00 00 00 00 00 00 00 00 |-..cc...........|
由此可见，update操作是在原有的数据位置上做更改操作，不会产生碎片
冗余（redundant）
xue_binbin@test 11:00:55>create table test3 engine = innodb row_format = redundant as select * from test1;
xue_binbin@test 07:40:21>select * from test3;
t1 t2 t3
t4
a bb bb
ccc
d ee ee
fff
d NULL
NULL fff
相同分析数据：
0000c070 08 03 00 00 73 75 70 72 65 6d 75 6d 00 23 20 16 |....supremum.# .|
0000c080 14 13 0c 06 00 00 10 0f 00 ba 00 00 0c 84 58 06 |..............X.|
0000c090 00 00 00 63 40 0a 80 00 00 00 2d 01 10 61 62 62 |...c@.....-..abb|
0000c0a0 62 62 20 20 20 20 20 20 20 20 63 63 63 23 20 16 |bb ccc# .|
0000c0b0 14 13 0c 06 00 00 18 0f 00 ea 00 00 0c 84 58 07 |..............X.|
0000c0c0 00 00 00 63 40 0a 80 00 00 00 2d 01 1f 64 65 65 |...c@.....-..dee|
0000c0d0 65 65 20 20 20 20 20 20 20 20 66 66 66 21 9e 94 |ee fff!..|
0000c0e0 14 13 0c 06 00 00 20 0f 00 74 00 00 0c 84 58 08 |...... ..t....X.|
0000c0f0 00 00 00 63 40 0a 80 00 00 00 2d 01 2e 64 00 00 |...c@.....-..d..|
0000c100 00 00 00 00 00 00 00 00 66 66 66 00 00 00 00 00 |........fff.....|
0000c110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
test3表中第一行记录为（a，bb，bb，ccc）他们的长度分别为1，2，10，3
外加上还有隐藏的三个字段（rowid（长度为6）,事务ID（6），回滚ID（7））
所以长度偏移列表有7个，分别为（06）6，（0c）12，（13）19，（14）20，（16）22，（20）32，（23）35
表空间数据记录为反序，则为23，20，16，14，13，0c，06
23 20 16 14 13 0c 06 长度偏移列表
00 00 10 0f 00 ba 头文件ID
00 00 0c 84 58 06 rowid
00 00 00 63 40 0a transactionID
80 00 00 00 2d 01 10 回滚ID
至于主键的话，相同的把rowid换成了4个字节的主键信息
对于插入的数据的顺序，底层是怎么插入的？
实验： create table t3(id int not null,t1 varchar(10) CHARACTER SET latin1 DEFAULT NULL,t2 varchar(10) CHARACTER SET latin1 DEFAULT NULL,t3 char(6) CHARACTER SET latin1 DEFAULT NULL,PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=compact;
lin_ren@test 05:52:24>insert into t3 values(1,'aa','bb','cc');
Query OK, 1 row affected (0.00 sec)
lin_ren@test 05:53:39>insert into t3 values(3,'aaa','bbb','ccc');
Query OK, 1 row affected (0.00 sec)
lin_ren@test 05:54:50>insert into t3 values(2,'aa','bbbb','ccc');
Query OK, 1 row affected (0.00 sec)
0000c070 73 75 70 72 65 6d 75 6d 02 02 00 00 00 10 00 48 |supremum.......H|
0000c080 80 00 00 01 00 00 00 82 46 58 80 00 00 00 32 01 |........FX....2.|
0000c090 10 61 61 62 62 63 63 20 20 20 20 03 03 00 00 00 |.aabbcc .....|
0000c0a0 18 ff cd 80 00 00 03 00 00 00 82 46 65 80 00 00 |...........Fe...|
0000c0b0 00 32 01 10 61 61 61 62 62 62 63 63 63 20 20 20 |.2..aaabbbccc |
0000c0c0 04 02 00 00 00 20 ff db 80 00 00 02 00 00 00 82 |..... ..........|
0000c0d0 46 8a 80 00 00 00
32 01 10 61 61 62 62 62 62 63 |F.....2..aabbbbc|
0000c0e0 63 63 20 20 20 00 00 00 00 00 00 00 00 00 00 00 |cc ...........|
0000c0f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
CREATE TABLE t1 (
id int(11) NOT NULL DEFAULT '0',
t1 varchar(10) CHARACTER SET latin1 DEFAULT NULL,
t2 varchar(10) CHARACTER SET latin1 DEFAULT NULL,
t3 char(6) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT |
lin_ren@test 05:57:17>insert into t1 values(1,'aa','bb','cc');
Query OK, 1 row affected (0.00 sec)
lin_ren@test 06:03:43>insert into t1 values(3,'a','b','c');
Query OK, 1 row affected (0.00 sec)
lin_ren@test 06:04:01>insert into t1 values(2,'aa','ab','cc');
Query OK, 1 row affected (0.00 sec)
0000c070 08 03 00 00 73 75 70 72 65 6d 75 6d 00 1b 15 13 |....supremum....|
0000c080 11 0a 04 00 00 10 0d 00 d5 80 00 00 01 00 00 00 |................|
0000c090 82 46 d3 80 00 00 00 32 01 10 61 61 62 62 63 63 |.F.....2..aabbcc|
0000c0a0 20 20 20 20 19 13 12 11 0a 04 00 00 18 0d 00 74 | ...........t|
0000c0b0 80 00 00 03 00 00 00 82 46 d5 80 00 00 00 32 01 |........F.....2.|
0000c0c0 10 61 62 63 20 20 20 20 20 1b 15 13 11 0a 04 00 |.abc .......|
0000c0d0 00 20 0d 00 b0 80 00 00 02 00 00 00 82 46 d6 80 |. ...........F..|
0000c0e0 00 00 00 32 01 10 61 61 61 62 63 63 20 20 20 20 |...2..aaabcc [BR]]
由此可见，无论是compact，还是redundant ,用ID做主键，插入的顺序依照你的排列顺序，而不是依照id的顺序排列
optimize table t3;
lin_ren@test 10:16:09>optimize table t3;
Table Op
Msg_type Msg_text
test.t3 optimize
note Table does not support optimize, doing recreate + analyze instead
test.t3 optimize
status OK
整理后数据排序
0000c070 73 75 70 72 65 6d 75 6d 02 02 00 00 00 10 00 23 |supremum.......#|
0000c080 80 00 00 01 00 00 00 82 5f ff 80 00 00 00 32 01 |........_.....2.|
0000c090 10 61 61 62 62 63 63 20 20 20 20 04 02 00 00 00 |.aabbcc .....|
0000c0a0 18 00 25 80 00 00 02 00 00 00 82 5f ff 80 00 00 |..%........_....|
0000c0b0 00 32 01 1d 61 61 62 62 62 62 63 63 63 20 20 20 |.2..aabbbbccc |
0000c0c0 03 03 00 00 00 20 ff a8 80 00 00 03 00 00 00 82 |..... ..........|
0000c0d0 5f ff 80 00 00 00 32 01 2a 61 61 61 62 62 62 63 |_.....2.*aaabbbc|
0000c0e0 63 63 20 20 20 00 00 00 00 00 00 00 00 00 00 00 |cc ...........|
删除数据：
optimize table t3;
0000c000 6e 94 df 09 00 00 00 03 ff ff ff ff ff ff ff ff |n...............|
0000c010 00 00 00 5a 29 eb 95 68 45 bf 00 00 00 00 00 00 |...Z)..hE.......|
0000c020 00 00 00 00 16 c9 00 02 00 c0 80 04 00 00 00 00 |................|
0000c030 00 a3 00 02 00 01 00 02 00 00 00 00 00 00 00 00 |................|
0000c040 00 00 00 00 00 00 00 00 38 2f 00 00 16 c9 00 00 |........8/......|
0000c050 00 02 00 f2 00 00 16 c9 00 00 00 02 00 32 01 00 |.............2..|
0000c060 02 00 1d 69 6e 66 69 6d 75 6d 00 03 00 0b 00 00 |...infimum......|
0000c070 73 75 70 72 65 6d 75 6d 02 02 00 00 00 10 00 23 |supremum.......#|
0000c080 80 00 00 01 00 00 00 82 60 50 80 00 00 00 32 01 |........`P....2.|
0000c090 10 61 61 62 62 63 63 20 20 20 20 04 02 00 00 00 |.aabbcc .....|
0000c0a0 18 ff cd 80 00 00 02 00 00 00 82 60 50 80 00 00 |...........`P...|
0000c0b0 00 32 01 1d 61 61 62 62 62 62 63 63 63 20 20 20 |.2..aabbbbccc |
0000c0c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
由此可见，假设删除大量的数据，我们要运行optimize table t3操作来释放空间。
以上就是InnoDB行格式分两种格式（COMPACT，redundant）的差别，外加Insert，delete，update的本质差别。
InnoDB行格式（compact，redundant）对照的更多相关文章
- InnoDB的行记录格式, Compact, Redundant, Compressed, Dynamic
InnoDB存储引擎和大多数数据库一样(如Oracle和Microsoft SQL Server数据库),记录是以行的形式存储的.这意味着页中保存着表中一行行的数据.到MySQL 5.1时,InnoD ...
- 数据页结构 .InnoDb行格式、以及索引底层原理分析
局部性原理 局部性原理是指CPU访问存储器时,无论是存取指令还是存取数据,所访问的存储单元都趋于聚集在一个较小的连续区域中. 首先要明白局部性原理能解决的是什么问题,也就是主存容量远远比缓存大, CP ...
- Mysql之InnoDB行格式、数据页结构
Mysql架构图 存储引擎负责对表中的数据的进行读取和写入,常用的存储引擎有InnoDB.MyISAM.Memory等,不同的存储引擎有自己的特性,数据在不同存储引擎中存放的格式也是不同的,比如Mem ...
- InnoDB行记录格式(compact)、InnoDB数据页结构
1. compact 行记录格式: 变长字段长度列表,null标志位,记录头信息,列1数据,列2数据 …… 记录头信息中包含许多信息,只列举一部分: 名称 大小 描述 deleted_flag 1bi ...
- MySQL 行格式
以 MySQL 默认的存储引擎 InnoDB 为例 InnoDB 包含以下四种行格式 Compact Redundant Dynamic Compressed 指定行格式 CREATE TABLE 表 ...
- 14.9 InnoDB Row Storage and Row Formats InnoDB 行存储和行格式:
14.9 InnoDB Row Storage and Row Formats InnoDB 行存储和行格式: 14.9.1 Overview of InnoDB Row Storage 14.9.2 ...
- MyISAM和InnoDB的行格式ROW_FORMAT
MyISAM行存储 MyISAM有3种行存储格式:fixed / dynamic / compressed: 格式 说明 备注 fixed 只有当表不包含变长字段(varchar/varbina ...
- 【大白话系列】MySQL 学习总结 之 COMPACT 行格式的设计原理
如果大家对我的 [大白话系列]MySQL 学习总结系列 感兴趣的话,可以点击关注一波. 一.回顾 MySQL 学习总结系列至此已经第七节了. 从大方向:我们已经学习了 MySQL 的架构设计.Inno ...
- 14.9.2 Specifying the Row Format for a Table 指定 表的行格式
14.9.2 Specifying the Row Format for a Table 指定 表的行格式 mysql> SHOW TABLE STATUS\G; *************** ...
随机推荐
- linux运维常用命令集
1.删除0字节文件 find -type f -size 0 -exec rm -rf {} \; 2.查看进程 按内存从大到小排列 PS -e -o "%C : %p : %z ...
- #pragma详解
在#Pragma是预处理指令它的作用是设定编译器的状态或者是指示编译器完成一些特定的动作.#pragma指令对每个编译器给出了一个方法,在保持与C和C ++语言完全兼容的情况下,给出主机或操作系统专有 ...
- [docker]coreOS与atomic对照
声明: 本博客欢迎转发,但请保留原作者信息! 博客地址:http://blog.csdn.net/halcyonbaby 内容系本人学习.研究和总结,如有雷同,实属荣幸! 摘自https://majo ...
- 第m个全排列
#include<stdio.h> #include<string.h> int flag,n,m; ],sum,vis[]; void dfs(int k) { ) retu ...
- Advanced Data Structures
Advanced Data Structures Advanced Data Structures
- C++ 指针—02 指针与引用的对照
★同样点: ●都是地址的概念: 指针指向一块内存,它的内容是所指内存的地址:而引用则是某块内存的别名. ★不同点: ●指针是一个实体,而引用仅是个别名: ●引用仅仅能在定义时被初始化一次,之后不可变: ...
- 图解：如何U盘装Win7系统(傻瓜式装机) + 分区步骤图解(用WIN7自带管理工具)
原地址:http://wenku.baidu.com/link?url=wV2Pfw2IM21u2KmtAcNweSZRwpXRuKAVAS29dS4aWGEpMtFdDlzZvixCgsvBxIm- ...
- set与map容器
首先来看看set集合容器: set集合容器实现了红黑树的平衡二叉树数据结构,在插入元素时它会自动调整二叉树的排列,把该元素放到适当的位置,并且 保证左右子树平衡.平衡二叉检索树采用中序遍历算法. 对于 ...
- SPOJ 7001(莫比乌斯反演)
传送门:Visible Lattice Points 题意:0<=x,y,z<=n,求有多少对xyz满足gcd(x,y,z)=1. 设f(d) = GCD(a,b,c) = d的种类数 : ...
- poj3140（树的dfs）
题目链接:http://poj.org/problem?id=3140 题意:给定一棵n棵节点的树,求删去某条边后两个分支的最小差异值. 分析:num[u]表示以u点为根节点的子树的总人数,那么不在该 ...