为企业做网站企业网站推广的方法
首先我们来看看, 存储自增主键和uuid的数据类型
我们知道, mysql中作为主键的通常是int类型的数据, 这个 数据从第一条记录开始, 从1开始主键往后递增, 例如我有100条数据, 那么根据主键排序后, 里面的记录从上往下一次就是1, 2, 3 ... 100, 但是UUID就不一样了, UUID是根据特殊的算法, 来生成唯一的一个字符串, 他的长度高达128个比特位, 而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12), 每一个x都是 0-9 或 a-f 范围内的一个十六进制的数字, 因此他需要使用字符串格式来进行存储, 标准的uuid的长度是32个字符, 外加两个短线, 也就是34个字符
在mysql中对int类型值的处理速度是比字符串的速度要快的, 因此在速度上, 是肯定比不过自增主键的, 我们在比较UUID, 然后对这些UUID进行一个排序的, 是一个字符一个字符的进行比较的, 例如有两个UUID, 那么就是从第一个字符比较, 如果第一个字符相等, 就比较下一个字符的大小, 以此类推, 直到比较完了, 那么两个字符串就想等, 如果存在字符的大小区别, 那么就根据不同的这个字符进行排序, 以此类推.
所以你是用UUID进行存储, 那么相比于自增的主键, 那么你就要花费额外的空间来存储这些UUID, 在插入主键或者是uuid的时候, 会有一个插入顺序的问题, 对于主键, 如果你不指定主键的值, 然后给这个主键设置自增值, 那么在插入的时候, 就会按照最大主键值的下一位插入, 这个时候就会性能很高, 为什么这么说呢?
因为mysql底层是一个数据页为一个基本的读写单元, 一个数据页可以存放16kb的数据, 你可以理解为数据页里面的记录是一个链表, 假如此时你不是按主键自增的顺序插入, 并且你插入的主键对应的数据页刚好满了装不下了, 此时的话, 你就需要将一个页拆分为两页, 这个就造成了不必要的性能消耗. 如果你按照自增的形式插入, 那么他们就会以此在最后一个数据页里面插入, 如果不够了, 就创建新的数据页, 而不是将一个页差分为两个, 然后拷贝数据.
但是如果你是使用的UUID作为主键, 那么就没有这个功能, 你的字符串id是有序的, 但是你不能保证, 你下一个生成的uuid, 就一定是最大的, 因此被分页的可能性就会很高. 同时每一个主键的占用的空间大了, 那么一个数据页装的数据记录也会变少, 页面增多, 所以在对这些记录进行操作, 将数据页读取到内存中的时候, 读取的页数页随之增多. io成本随之增多.
在存储和性能方面, 还是自增主键更胜一筹.
说了这么多仿佛都是UUID的缺点, 那UUID做主键就么没有有点吗?
有点肯定是有的 , 例如UUID的长度很长, 并且是随机生成的, 他的主键的复杂性很高, 并且没有规律, 你不能够通过数据分析来预测下一个主键id是多少,这种不可预测性对于需要保密性的应用场景较为适用。
还有另外一种场景, 假如现在有这样一个需求, 我需要将一个自增主键的表, 导入另外一个和当前表结构相同的表, 但是这个表已经存了很多数据, 这个时候我将其插入, 就会导入失败, 因为两个表前面几部分的id是重合的, 因此会插入失败. 同样的当你去拆分数据库的时候, 也可以很好的拆分, 并且避免id的重复导致数据的错乱.
此时如果你使用的是UUID, 那么就可以避免这个问题.
总结:
在MySQL中，使用自增主键（AUTO_INCREMENT）和UUID作为主键的主要区别体现在以下几个方面：
- 唯一性：
- 自增主键：确保主键的唯一性，每次插入新行时，数据库会自动为主键生成一个唯一的、比之前插入的最大主键值大1的整数值。
- UUID：具有极高的唯一性，基于一定算法（如随机数生成器或时间戳）生成，几乎不可能重复。UUID由32位16进制数表示，共128位（标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）。
- 数据类型和存储：
- 自增主键：只适用于整数类型的主键列（如INT、BIGINT等），存储空间相对较小。
- UUID：虽然也是字符串类型，但由于其长度较长（32个字符），存储空间相对较大。
- 插入性能：
- 自增主键：在插入新行时，数据库可以很容易地将新行插入到索引的末尾，减少了页分裂或移动数据的频率，从而提高了插入性能。
- UUID：由于UUID是随机生成的，插入时位置具有不确定性，可能导致无序插入和内存碎片，插入性能相对较差。
- 索引和查询性能：
- 自增主键：由于其递增的特性，非常适合用作聚集索引（Clustered Index），能够优化查询性能。同时，较小的索引大小也可以减少内存消耗，更好地适应于内存缓存。
- UUID：由于UUID的无序性，可能导致索引碎片化，影响查询性能。同时，较大的索引大小也可能增加内存消耗。
- 可预测性：
- 自增主键：主键值是可预测的，因为它们是按顺序生成的。
- UUID：主键值是不可预测的，因为它们是随机生成的。这种不可预测性对于需要保密性的应用场景较为适用。
- 删除和重新插入：
- 自增主键：在删除并重新插入数据后，可能会出现主键值“跳跃”的现象，即新插入的主键值可能会比之前删除的主键值大很多。
- UUID：UUID在删除和重新插入数据时，主键值不会受到影响，因为它们是随机生成的。
自增主键和UUID在MySQL中各有优缺点，选择哪种方式作为主键取决于具体的应用场景和需求。例如，在需要高性能插入和查询的场景下，自增主键可能更合适；而在需要保证主键全局唯一性和不可预测性的场景下，UUID可能更合适。