uuid和索引建立规则

上图：

索引建立规则：

1、表的主键、外键必须有索引；
2、数据量超过300的表应该有索引；
3、经常与其他表进行连接的表，在连接字段上应该建立索引；
4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
5、索引应该建在选择性高的字段上；
6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：
8、频繁进行数据操作的表，不要建立太多的索引；
9、删除无用的索引，避免对执行计划造成负面影响；

---

索引是不是越多越好呢？

不是

1.数据量小的表不需要建立索引，建立会增加额外的索引开销
2.不经常引用的列不要建立索引，因为不常用，即使建立了索引也没有多大意义。对经常用于查询的字段应该创建索引。
3.经常频繁更新的列不要建立索引，因为肯定会影响插入或更新的效率
4.数据重复且分布平均的字段，因此他建立索引就没有太大的效果（例如性别字段，是否上架等等，不适合建立索引）
5.数据变更需要维护索引，意味着索引越多维护成本越高。当对表中的数据进行增加、删除、修改时，索引也需要动态的维护，降低了数据的维护速度。
6.更多的索引也需要更多的存储空间，一个表中很够创建多个索引，这些索引度会被存放到一个索引文件中(专门存放索引的地方)。

---

mysql不推荐使用uuid或者雪花id作为主键?

首先看第一种情况：

聚集索引：特点是倒着的b+树，主键和数据都是存储在叶子节点，叶子节点之间有指针相连，叶子节点按照顺序排列

使用自增

假如我们需要增加一个项，那么我们直接在最后追加一个就行了

使用uuid

如果随机出来的是一个小的，假如说插入4。我们知道我们的聚集索引都是按照顺序排列的

那么就会进行页分裂

这个操作会非常的浪费性能，所以uuid会导致页分裂

第二种情况：

非聚集索引：按照索引的值进行排列，索引的下面挂的不是表的数据而是主键的值

uuid是比较长的字符串，会相对浪费空间一些

---

小总结：

自增的优点：

①下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序的记录填满，提升了页面的最大填充率，不会有页的浪费

②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的位置而做出额外的消耗

③减少了页分裂和碎片的产生

自增缺点

①：别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息，很容易分析出你的经营情况

②：对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争

③：Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

④：不利于扩展：迁移数据库的时候我们假如两个数据库都是自增，那么两个数据库就可能发生冲突

⑤：不利于迁移：如果要拆数据库，那么每个库都可能有相同的值。就会造成全局不唯一！！！

uuid缺点：
①：写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机IO

②：因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据，一次插入最少需要修改三个页以上

③：由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片

在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又需要一定的时间消耗。

---

如何解决

推荐方案
1.对于单库应用，聚集索引(MySQL)强烈推荐自增ID，堆表(Oracle)推荐使用自增ID，也可以考虑UUID

2.对于分库分表，推荐使用全局唯一、趋势递增的分布式ID

分布式id讲解

1.UUID;

2.单机数据库自增ID;
假如说有多个数据库，单独弄一个数据库，所有需要id的时候都用我这个数据库的id，保证了全局唯一和递增，，但是会过度依赖于单机数据库。

3.Redis自增ID;
优化单机数据库，会引入新的服务，但是节点可能丢失，造成问题

4.跳跃式自增ID

需要判断最大容量从而预留空位（几个一跳）

5. Snowflake及其改进算法（雪花算法）

64位

一毫秒最多可以生成1024*4096=4194304个id

问题：服务器时间不对，往前调时间就可能导致重复！！！！

思考题：身份证和手机号能作为主键吗？

可以答uuid的缺点，因为几乎是随机的！！！！