uuid和自增_uuid作为主键，还是用自增呢？

以默认的innodb存储引擎为例：

做为主键时，uuid和自增相比较，自增更适合。

原因：

1 uuid是无序的， 插入数据时，页的位置会发生变化，页分裂，速度慢。

2 uuid占的空间大，并且innodb中，别的索引还都要包含主键的值，那么每个索引的空间也都会增大，占的空间大，需要读数据时一般会认为需要的io次数多。

自增也是有缺点的

可见my blog

http://blog.itpub.net/25099483/viewspace-1869361/

http://blog.itpub.net/25099483/viewspace-1869360/

http://blog.itpub.net/25099483/viewspace-1869362/

下面来一个模拟一个场景证明第二个观点：

思路：

1 建表有三列(主键，姓名，性别)， 一个表是uuid为主键，一个表是自增为主键

插入同样的记录数

2 对“性别”列加索引，对比索引大小。索引大的占的空间多

mysql> create table song_auto_inc(id int primary key auto_increment,name varchar(10),sex char(1));

Query OK, 0 rows affected (0.01 sec)

mysql> create table song_uuid(id varchar(36) primary key ,name varchar(10),sex char(1));

Query OK, 0 rows affected (0.00 sec)

cat insert_auto_inc.sh --插入自增表

#!/bin/bash

while true; do

mysql -h10.13.12.197 -P3306 -uroot -ptest -e "insert into test.song_auto_inc (name,sex) select 'name1','1' ;"

done

cat insert_uuid.sh --插入uuid

#!/bin/bash

while true; do

mysql -h10.13.12.197 -P3306 -uroot -ptest -e "insert into test.song_uuid select uuid(),'name1','1' ;"

done

插入数据：

sh insert_auto_inc.sh

sh insert_uuid.sh

mysql> select count(*) from song_auto_inc;

+----------+

| count(*) |

+----------+

| 197806 | --记录数一样

+----------+

1 row in set (0.03 sec)

mysql> select count(*) from song_uuid;

+----------+

| count(*) |

+----------+

| 197806 | --记录数一样

+----------+

1 row in set (0.03 sec)

--去掉两个表中的碎片

mysql> optimize table song_auto_inc;

+--------------------+----------+----------+-------------------------------------------------------------------+

| Table | Op | Msg_type | Msg_text |

+--------------------+----------+----------+-------------------------------------------------------------------+

| test.song_auto_inc | optimize | note | Table does not support optimize, doing recreate + analyze instead |

| test.song_auto_inc | optimize | status | OK |

+--------------------+----------+----------+-------------------------------------------------------------------+

2 rows in set (4.32 sec)

mysql> optimize table song_uuid;

+----------------+----------+----------+-------------------------------------------------------------------+

| Table | Op | Msg_type | Msg_text |

+----------------+----------+----------+-------------------------------------------------------------------+

| test.song_uuid | optimize | note | Table does not support optimize, doing recreate + analyze instead |

| test.song_uuid | optimize | status | OK |

+----------------+----------+----------+-------------------------------------------------------------------+

2 rows in set (10.71 sec)

--查看数据文件大小：

-rw-rw---- 1 mysql mysql 8.5K Jul 23 23:10 song_auto_inc.frm

-rw-rw---- 1 mysql mysql 7.0M Jul 23 23:10 song_auto_inc.ibd

-rw-rw---- 1 mysql mysql 8.5K Jul 23 23:13 song_uuid.frm

-rw-rw---- 1 mysql mysql 14M Jul 23 23:13 song_uuid.ibd

加索引

mysql> create index idx_song_uuid_sex on song_uuid(sex);

Query OK, 0 rows affected (5.51 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> create index idx_song_auto_inc_sex on song_auto_inc(sex);

Query OK, 0 rows affected (0.91 sec)

Records: 0 Duplicates: 0 Warnings: 0

再次查看数据文件大小：

-rw-rw---- 1 mysql mysql 8.5K Jul 23 23:19 song_auto_inc.frm

-rw-rw---- 1 mysql mysql 13M Jul 23 23:19 song_auto_inc.ibd

-rw-rw---- 1 mysql mysql 8.5K Jul 23 23:19 song_uuid.frm

-rw-rw---- 1 mysql mysql 24M Jul 23 23:19 song_uuid.ibd

自增主键的表大小是 7M

uuid主键的表大小是14M

自增主键二级索引大小是 13-7=6M

uuid主键二级索引大小是 24-14=10M

可以证明第二个观点。

第一个观点留给读者自己验证

上面的测试是在ucloud(UCloud – 专业云计算服务商)的mysql5.6的普通udb上完成的，如果对比插入时的性能不满意，可以使用ssd的udb，ssd的性能非常高。在网上看到https://linux.cn/article-7596-1.html这个文章，里面用ucloud ssd mysql和别的云服务商进行对比，可以参考下。

QQ 273002188 欢迎一起学习

QQ 群 236941212

oracle,mysql,PG 相互交流