以默认的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 相互交流