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; *************** ...
随机推荐
- 汇编与高级语言（插图结合Delphi代码，来自linzhengqun）
汇编与高级语言 1. 汇编基础知识 1.1. 寄存器 寄存器 用途 EAX,EBX,EDX,ECX 通用寄存器,由程序员自己指定用途,也有一些不成文的用法: EAX:常用于运算. ...
- 与众不同 windows phone (20) - Device（设备）之位置服务（GPS 定位）, FM 收音机, 麦克风, 震动器
原文:与众不同 windows phone (20) - Device(设备)之位置服务(GPS 定位), FM 收音机, 麦克风, 震动器 [索引页][源码下载] 与众不同 windows phon ...
- Android自己定义控件——3D画廊和图像矩阵
转载请注明出处:http://blog.csdn.net/allen315410/article/details/39932689 1.3D画廊的实现 我们知道android系统已经为我们提供好了一个 ...
- moodle中文API之表单API
Form API 表单API 文件夹 1.概述 2.亮点 3.使用方法 4.表单元素 4.1 基本表单元素 4.2 定制表单元素 5.经常使用函数 5.1 add_action_buttons($c ...
- POJ 1159 - Palindrome 优化空间LCS
将原串和其逆序串的最长公共子序列求出来为M..那么2*n-M就是所需要加的最少字符..因为求出的M就是指的原串中"潜伏"的最长回文.. 问题转化为求LCS..但是n最大到5000. ...
- Android 编译时出现r cannot be resolved to a variable
问题:编译出现r cannot be resolved to a variable 原因:SDK的Tools没有安装 解决:在Android SDK Manager中安装Tools部分,包括如下4项, ...
- Linux创建修改删除用户和组
Linux 创建修改删除用户和组 介绍 在日常的维护过程中创建用户操作用的相对会多一些,但是在这个过程中涉及到的知识点就不单单就是useradd了,接下来就来详细了解账号管理的相关信息. 用户信息 先 ...
- 图解：如何U盘装Win7系统(傻瓜式装机) + 分区步骤图解(用WIN7自带管理工具)
原地址:http://wenku.baidu.com/link?url=wV2Pfw2IM21u2KmtAcNweSZRwpXRuKAVAS29dS4aWGEpMtFdDlzZvixCgsvBxIm- ...
- 北京联通100M光纤宽带需邀请函 实际速率12MB/S - OFweek光通讯网
[新提醒]随身wifi无法使用FAQ(不断更新中~~~~~~) - 使用问题 - 360官方论坛 undefined 北京联通100M光纤宽带需邀请函 实际速率12MB/S - OFweek光通讯网 ...
- cocos2D（四）---- CCSprite
在介绍CCSprite之前,先要理解游戏开发中的一个核心概念:精灵.精灵也称为游戏对象,它能够用来表示游戏中的不论什么物体,比方敌人.子弹.甚至是一个背景图片.一段文字.CCSprite能够说是在co ...