MySQL支持的数据类型很多,那么选择合适的数据类型对于获得高性能就至关重要。那么就先了解各种类型的优缺点!

用微软自带的sqlcmd工具,可以导入执行。以SQL Server 2008R版本为例:

 

澳门微尼斯人手机版,一、类型介绍

第一步:Win+R 键入:cmd 命令,开启命令行工具;

Preface

1、整型类型

第二步:键入:cd C:\Program Files\Microsoft SQL
Server\100\Tools\Binn
 (具体目录路径跟你安装的SQL位置有关)

 

  整型类型有: TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT 。他们分别占8,16,24,32,64位储存空间。可存储的整数范围为-2^(N-1)到2^(N-1)-1,其中N是存储空间的位数。

第三步:键入:sqlcmd -S . -U sa -P 123 -d test -i data.sql

    Today I’m gonna test how to rescue a
dropped table from binlog server based on a full Xtrabackup backup
set.

还可以将整数类型设为 UNSIGNED ,这样几乎可以是其范围增大一倍。例如TINYINT范围是-128

参数说明:*-S 服务器地址 -U 用户名 -P 密码
 -d 数据库名称 -i 脚本文件路径 *

 

  • 127,而TINYINT
    UNSIGNED的范围是0-255。不过这两种只是在范围上有缺别,在存储空间和性能上都是一样的。

 

Framework

 

更多参考:

 

2、实数类型

转自:

Hostname IP/Port Identity OS Version MySQL Version GTID Mode Binlog Format
zlm1 192.168.56.100/3306 master CentOS 7.0 5.7.21 on row
zlm2 192.168.56.101/3306 slave CentOS 7.0 5.7.21 on row
zlm3 192.168.56.102/3306 binlog server CentOS 7.0 5.7.21 on row

  对于实数类型,MySQL即支持精确类型(DECIMAL),也支持不精确类型(FLOAT,DOUBLE)。

 

  DECIMAL类型允许最多存储65位数字,因此它可以存储比BIGINT还大的数字。而且在MySQL5.0或更高版本中,MySQL服务器自身实现的DECIMAL的高精度计算。但相比较浮点类型,因为CPU直接支持原声浮点计算,所以浮点类型计算会更快。

Precedure

  通常来说,浮点类型在存储相同的范围时,比DECIMAL使用更少的空间。FLOAT占用4个字节存储,DOUBLE占用8个字节存储,但相比FLOAT有更高的精度和更大的范围。浮点类型存储时在精度上会有各种各样的问题,例如当你只把一列设为FLOAT,而没有指定精度时,在存储1234567.33会变成1234570。

 

  DECIMAL所占的字节比较特殊。它是在小数点前后分别使用每4个字节存储9位数字。具体看mysql手册说法:

Step
1: Create binlog server.

澳门微尼斯人手机版 1

 

所以我们使用最多的DECIMAL(10,2)所占的字节数为1+4+1+1=7个字节(小数点占一个字节)。

Check
the position on master 

因为需要额外的计算开销和存储空间,所以应该尽量只在对小数进行精确计算时才使用DECIMAL–例如存储财务数据。当你的数据量比较大的时候,为了避免浮点存储计算不精确和DECIMAL精确计算代价高的问题,可以使用BIGINT代替DECIMAL,只需将原来需要存储的小数乘以相应的倍数即可(BIGINT的范围满足你的需求)。

1 zlm@192.168.56.100:3306 [sysbench]>show master status;
2 +------------------+----------+--------------+------------------+-------------------------------------------------+
3 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                               |
4 +------------------+----------+--------------+------------------+-------------------------------------------------+
5 | mysql-bin.000098 |      363 |              |                  | 2a4b3562-2ab6-11e8-be7a-080027de0e0e:1-12715693 |
6 +------------------+----------+--------------+------------------+-------------------------------------------------+
7 1 row in set (0.00 sec)

 

 

3、字符串类型

**Make
binlog server begin to receive binlog.**

  VARCHAR类型用于存储可变长的字符串,所以它需要1或2个额外的字节记录字符串的长度:如果列的长度小于或等于255个字节,则只使用1个字节表示,否则使用2个字节表示。例如varchar(10)就需要11个字节,varchar(1000)则需要1002个字节。

 1 [root@zlm3 16:25:01 /data]
 2 #mysqlbinlog -R --raw -h192.168.56.100 -urepl -prepl4slave -P3306 --stop-never mysql-bin.000098 &
 3 [1] 4375
 4 mysqlbinlog: [Warning] Using a password on the command line interface can be insecure.
 5 
 6 [root@zlm3 16:26:24 /data]
 7 #ls -l
 8 total 4
 9 drwxr-xr-x 2 mysql mysql  32 Jun 10 03:41 backup
10 drwxr-xr-x 3 mysql mysql  22 Mar 18 16:05 mysql
11 -rw-r----- 1 root  root  363 Jul 29 16:26 mysql-bin.000098

  VARCHAR节省了存储空间,所以对性能有所帮助。但由于行是变长的,在UPDATE时可能是原来的行更长,这就会导致需要做一些额外的工作。如果一个行占用的空间曾长,并且在页内没有更多的空间可以存储,这是INNODB就会分裂当前页来使行可以放进页内。

 

  下面这些情况使用VARCHAR是合适的:

**Flush
two logs on master.**

  • 字符串列的最大长度比平均长度大很多
  • 列的更新很少
  • 使用了UTF-8这样的字符集,每个字符都是用不同的字节存储
 1 zlm@192.168.56.100:3306 [sysbench]>flush logs;
 2 Query OK, 0 rows affected (0.06 sec)
 3 
 4 zlm@192.168.56.100:3306 [sysbench]>flush logs;
 5 Query OK, 0 rows affected (0.01 sec)
 6 
 7 zlm@192.168.56.100:3306 [sysbench]>show master status;
 8 +------------------+----------+--------------+------------------+-------------------------------------------------+
 9 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                               |
10 +------------------+----------+--------------+------------------+-------------------------------------------------+
11 | mysql-bin.000100 |      194 |              |                  | 2a4b3562-2ab6-11e8-be7a-080027de0e0e:1-12715693 |
12 +------------------+----------+--------------+------------------+-------------------------------------------------+
13 1 row in set (0.00 sec)

 

 

  CHAR类型是定长的:MySQL总是根据定义字符串的长度分配足够空间。因为CHAR会根据需要采用空格填充到字符串末尾,而且当你检索时,CHAR会删除末尾的空格。所以会有一个很有趣的事情发生,当你存储一个”Johnson 
“到char(10)时,检索出来的结果却是”Johnson”,因为MySQL并不知道这空格是你存的还是系统自动填充的。

**Check
whether the newly generated binlogs are successfully transmited to
binlog server.**

  CHAR很适合存储很短的字符串或所有值都接近同一个长度。例如密码的MD5值。

1 [root@zlm3 16:26:27 /data]
2 #ls -l
3 total 12
4 drwxr-xr-x 2 mysql mysql  32 Jun 10 03:41 backup
5 drwxr-xr-x 3 mysql mysql  22 Mar 18 16:05 mysql
6 -rw-r----- 1 root  root  410 Jul 29 16:27 mysql-bin.000098
7 -rw-r----- 1 root  root  241 Jul 29 16:27 mysql-bin.000099
8 -rw-r----- 1 root  root  194 Jul 29 16:27 mysql-bin.000100

 

 

  BLOB和TEXT都是为了存储很大的数据类型而设计的字符串数据类型,分别采用二进制和字符方式存储。而且当它们存储的数据过大时,INNOSB会使用专门的‘外部’空间来存储数据,此时每个值的行内仅存储一个1

4个字节的指针,然后在外部区域存储真实的指。当需要对BLOB和TEXT排序时,它只对每个列的最前 max_sort_length 进行排序。这个值是可以配置的。

Step
2: Destroy the table.

 

 

4、 枚举类型

Check
target table on master.

  有时候可以使用枚举类型代替常用的字符串类型。MySQL在内部会将每个值在列表中的位置保存为整数,并且在表的.frm文件中保存“数字-字符串”的映射关系。比如性别列,就可以用enum(男,女,未知),这里有些人可能用TINYINT代替枚举,实际我感觉这并不能带来性能的优化,只不过你把“数字-字符串”的映射关系搬到你的业务逻辑中处理,如果你的注释写的不清晰,反而会给新人带来困惑。

 1 zlm@192.168.56.100:3306 [sysbench]>show tables;
 2 +--------------------+
 3 | Tables_in_sysbench |
 4 +--------------------+
 5 | sbtest1            |
 6 | sbtest2            |
 7 | sbtest3            |
 8 | sbtest4            |
 9 | sbtest5            |
10 | sbtest6            |
11 +--------------------+
12 6 rows in set (0.00 sec)
13 
14 zlm@192.168.56.100:3306 [sysbench]>select count(*) from sbtest6;
15 +----------+
16 | count(*) |
17 +----------+
18 |        0 |
19 +----------+
20 1 row in set (0.00 sec)
21 
22 zlm@192.168.56.100:3306 [sysbench]>insert into sbtest6 values(1,1,'a','b');
23 Query OK, 1 row affected (0.00 sec)
24 
25 zlm@192.168.56.100:3306 [sysbench]>select * from sbtest6;
26 +----+---+---+-----+
27 | id | k | c | pad |
28 +----+---+---+-----+
29 |  1 | 1 | a | b   |
30 +----+---+---+-----+
31 1 row in set (0.00 sec)

  对于弱类型语言来说,枚举并不是狠友好。举个栗子:select id,name from users where id = 1; 和 select id,name from users where id = ‘1’; 得到的结果是一样的。因为ENUM内部存储是用的整型,所以在检索ENUM类型时也可以用整数,例如 select id,name from users where sex = 1; 和 select id,name from users where sex = ‘男’; 可以得到相同的结果。但

 

select id,name from users where sex = ‘1’;

Generate
Xtrabackup backup set.

就检索不到任何值。但如果你设计和使用的好,依然可以用。

 1 [root@zlm1 16:32:14 ~]
 2 #innobackupex --defaults-file=/data/mysql/mysql3306/my3306.cnf -uroot -pPassw0rd /data/backup
 3 180729 16:32:20 innobackupex: Error: extra argument found -pPassw0rd
 4 180729 16:32:20 innobackupex: Error: extra argument found /data/backup
 5 
 6 [root@zlm1 16:32:20 ~]
 7 #innobackupex -v
 8 innobackupex version 2.4.4 Linux (x86_64) (revision id: df58cf2)
 9 
10 [root@zlm1 16:32:26 ~]
11 #innobackupex --defaults-file=/data/mysql/mysql3306/my3306.cnf --user=root --password=Passw0rd /data/backup
12 180729 16:32:33 innobackupex: Starting the backup operation
13 ...
14 
15 180729 16:32:53 Backup created in directory '/data/backup/2018-07-29_16-32-33'
16 MySQL binlog position: filename 'mysql-bin.000100', position '476', GTID of the last change '2a4b3562-2ab6-11e8-be7a-080027de0e0e:1-12715694'
17 180729 16:32:53 [00] Writing backup-my.cnf
18 180729 16:32:53 [00]        ...done
19 180729 16:32:53 [00] Writing xtrabackup_info
20 180729 16:32:53 [00]        ...done
21 xtrabackup: Transaction log of lsn (1719676169) to (1719676178) was copied.
22 180729 16:32:53 completed OK!

发表评论

电子邮件地址不会被公开。 必填项已用*标注