mysql主键是bree还是hash

Posted 2023-05-15

参考技术A 1. hash索引查找数据基本上能一次定位数据，当然有大量碰撞的话性能也会下降。而btree索引就得在节点上挨着查找了，很明显在数据精确查找方面hash索引的效率是要高于btree的；2. 那么不精确查找呢，也很明显，因为hash算法是基于等值计算的，所以对于“like”等范围查找hash索引无效，不支持；3. 对于btree支持的联合索引的最优前缀，hash也是无法支持的，联合索引中的字段要么全用要么全不用。提起最优前缀居然都泛起迷糊了，看来有时候放空得太厉害；4. hash不支持索引排序，索引值和计算出来的hash值大小并不一定一致。本回答被提问者采纳 参考技术B

当分片索引不是纯整型的字符串时，只接受整型的内置 hash 算法是无法使用的。为此，stringhash 按照用户定义的起点和终点去截取分片索引字段中的部分字符，根据当中每个字符的二进制 unicode 值换算出一个长整型数值，然后就直接调用内置 hash 算法求解分片路由：先求模得到逻辑分片号，再根据逻辑分片号直接映射到物理分片。

用户需要在 rule.xml 中定义 partitionLength[] 和 partitionCount[] 两个数组和 hashSlice 二元组。

在 DBLE 的启动阶段，点乘两个数组得到模数，也是逻辑分片的数量

并且根据两个数组的叉乘，得到各个逻辑分片到物理分片的映射表（物理分片数量由 partitionCount[] 数组的元素值之和）

此外根据 hashSlice 二元组，约定把分片索引值中的第 4 字符到第 5 字符（字符串以 0 开始编号，编号 3 到编号 4 等于第 4 字符到第 5 字符）字符串用于 “字符串->整型”的转换

在 DBLE 的运行过程中，用户访问使用这个算法的表时，WHERE 子句中的分片索引值会被提取出来，取当中的第 4 个字符到第 5 字符，送入下一步

设置一个初始值为 0 的累计值，逐个取字符，把累计值乘以 31，再把这个字符的 unicode 值当成长整型加入到累计值中，如此类推直至处理完截取出来的所有字符，此时的累计值就能够代表用户的分片索引值，完成了 “字符串->整型” 的转换

对上一步的累计值进行求模，得到逻辑分片号

再根据逻辑分片号，查映射表，直接得到物理分片号

与MyCat的类似分片算法对比

请点击输入图片描述

两种算法在string转化为int之后，和 hash 分区算法相同，区别也继承了 hash 算法的区别。

开发注意点

【分片索引】1. 必须是字符串

【分片索引】2. 最大物理分片配置方法是，让 partitionCount[] 数组和等于 2880

例如：

<property name="partitionLength">1</property><property name="partitionCount">2880</property>


或

<property name="partitionLength">1,1</property><property name="partitionCount">1440,1440</property>


【分片索引】3. 最小物理分片配置方法是，让 partitionCount[] 数组和等于 1

例如

<property name="partitionLength">2880</property><property name="partitionCount">1</property>


【分片索引】4. partitionLength 和 partitionCount 被当做两个逗号分隔的一维数组，它们之间的点乘必须在 [1, 2880] 范围内

【分片索引】5. partitionLength 和 partitionCount 的配置对顺序敏感

<property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>


和

<property name="partitionLength">256,512</property><property name="partitionCount">2,1</property>


是不同的分片结果

【分片索引】6. 分片索引字段长度小于用户指定的截取长度时，截取长度会安全减少到符合分片索引字段长度

【数据分布】1. 分片索引字段截取越长则越有利于数据均匀分布

【数据分布】2. 分片索引字段的内容重复率越低则越有利于数据均匀分布

运维注意点

【扩容】1. 预先过量分片，并且不改变 partitionCount 和 partitionLength 点乘结果，也不改变截取设置 hashSlice 时，可以避免数据再平衡，只需进行涉及数据的迁移

【扩容】2. 若需要改变 partitionCount 和 partitionLength 点乘结果或改变截取设置 hashSlice 时，需要数据再平衡

【缩容】1. 预先过量分片，并且不改变 partitionCount 和 partitionLength 点乘结果，也不改变截取设置 hashSlice 时，可以避免数据再平衡，只需进行涉及数据的迁移

【缩容】2. 若需要改变 partitionCount 和 partitionLength 点乘结果或改变截取设置 hashSlice 时，需要数据再平衡

配置注意点

【配置项】1. 在 rule.xml 中，可配置项为 <property name="partitionLength">  、<property name="partitionCount"> 和 <property name="hashSlice"> 

【配置项】2.在 rule.xml 中配置 <property name="partitionLength"> 标签

内容形式为：<物理分片持有的虚拟分片数>[,<物理分片持有的虚拟分片数>,...<物理分片持有的虚拟分片数>]

物理分片持有的虚拟分片数必须是整型，物理分片持有的虚拟分片数从左到右与同顺序的物理分片数对应，partitionLength 和partitionCount 的点乘结果必须在 [1, 2880] 范围内

【配置项】3. 在 rule.xml 中配置 <property name="partitionCount"> 标签
内容形式为：<物理分片数>[,<物理分片数>,...<物理分片数>]

其中物理分片数必须是整型，物理分片数按从左到右的顺序与同顺序的物理分片持有的虚拟分片数对应，物理分片的编号从左到右连续递进，partitionLength 和 partitionCount 的点乘结果必须在 [1, 2880] 范围内

【配置项】4. partitionLength 和 partitionCount 的语义是：持有partitionLength[i] 个虚拟分片的物理分片有 partitionCount[i] 个

例如

<property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>


语义是持有 512 个逻辑分片的物理分片有 1 个，紧随其后，持有 256 个逻辑分片的物理分片有 2 个

【配置项】5.partitionLength 和 partitionCount 都对书写顺序敏感，

例如

<property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>


分片结果是第一个物理分片持有头512个逻辑分片，第二个物理分片持有紧接着的256个逻辑分片，第三个物理分片持有最后256个逻辑分片，相对的

<property name="partitionLength">256,512</property><property name="partitionCount">2,1</property>


分片结果则是第一个物理分片持有头 256 个逻辑分片，第二个物理分片持有紧接着的 256 个逻辑分片，第三个物理分片持有最后 512 个逻辑分片

【配置项】6.partitionLength[] 的元素全部为 1 时，这时候partitionCount 数组和等于 partitionLength 和 partitionCount 的点乘，物理分片和逻辑分片就会一一对应，该分片算法等效于直接取余

【配置项】7.在 rule.xml 中配置标签，从分片索引字段的第几个字符开始截取到第几个字符：

若希望从首字符开始截取 k 个字符（ k 为正整数），配置的内容形式可以为“ 0 : k ”、“ k ”或“ : k ”；

若希望从末字符开始截取 k 个字符（ k 为正整数），则配置的内容形式可以为“ -k : 0 ”、“ -k ”或“ -k : ”；

若希望从头第 m 个字符起算截取 n 个字符（ m 和 n 都是正整数），则先计算出 i = m - 1 和 j = i + n - 1，配置的内容形式为“ i : j ”；

若希望从尾第 m 个字符起算截取从尾算起的 n 个字符（ m 和 n 都是正整数），则先计算出 i = -m + n - 1，配置的内容形式可以为“ -m : i ”；

若希望不截取，则配置的内容形式可以为“ 0 : 0 ”、“ 0 : ”、“ : 0 ”或 “ : ”

参考技术C 是btree，btree，btree，btree

mysql表设计的一些面试题

MySQL表设计有一些比较重要的点，面试的时候常常会被问到。

为什么一定要设置一个主键？

在不设置主键的情况下，InnoDB存储引擎会帮你生成一个隐藏列作为自增主键。因此，手动指定主键可以为以后的维护带来便利，比如说在自定义主键上建立主键索引来提高查询效率。

主键是用自增还是随机（UUID）？

主键建议是自增的好。因为InnoDB中的主键是聚簇索引，如果主键是自增的话，每次插入新的记录就会顺序添加到当前索引节点的后续位置，当一页写满就会自动开辟新的页。如果不是自增主键，可能就会在中间插入，引发页的分裂导致产生很多表空间的碎片。

可以理解为当主键是UUID的时候，插入表记录的时间会更长，占用空间也会更大。

主键为什么不推荐有业务含义？

主要有两点。

1.任何有业务含义的列都有改变的可能性，主键一旦带上了业务含义，那么主键就有可能发生变更。而主键一旦发生变更，该记录数据在磁盘上的存储位置就会发生改变，甚至有可能会引发页分裂导致产生空间碎片。

2.带有业务含义的主键就不一定是顺序自增的了，这样就会导致数据的插入顺序不到有序的，也不能保证后面插入数据的主键一定比前面的数据大。如果出现了后面插入数据的主键比前面的小的情况，就有可能引发页分裂导致产生空间碎片。

表示枚举的字段为什么不用enum类型？

表示枚举的字段一般选用tinyint类型。不选用enum类型主要有两个原因：

1.enum类型的order by的操作效率低，需要额外的操作。

2.如果枚举值是数值类型的，会很容易出现语法陷阱，枚举的下标和数值很容易会被弄混淆。

货币字段用什么类型？

如果货币单位是分，可以是int类型；如果坚持用元，则要用decimal类型。

但是是不能用float和double类型的，因为这两个类型是以二进制存储的，会有一定的误差。比如float类型如果你insert一个1234567.23，查询出来的结果可能是1234567.25。

时间字段用什么类型？

时间字段的话需要结合项目背景，varchar、timestamp、datetime或bigint类型都可以。

1.varchar类型。如果用varchar类型来存时间，优点在于显示直观，存取都方便。但是缺点也是挺多的，比如插入的数据没有校验，某一天你可能会发现数据库中存了一个2019-06-31的数据。其次，做时间比较运算时需要用str_to_date()等函数将其转化为时间类型，除非建立基于函数的索引，否则这么写是无法命中索引的，数据量一大，查询效率就会很低。

2.timestamp类型。这个类型是四个字节的整数，它能表示的时间范围为1970-01-01 08:00:01到2038-01-19 11:14:07，而2038年以后的时间，是无法用timestamp类型存储的。但是它有一个优势是它带有时区信息的，一旦系统中的时区发生改变，项目中的该字段的值也会自己发生改变。

3.datetime类型。datetime类型的储存占用8个字节，存储的时间范围为1000-01-01 00:00:00 ~ 9999-12-31 23:59:59。显然，存储时间范围更大，但是它存储的是时间绝对值，不带有时区信息。如果改变了数据库的时区，该项的值不会自己发生变更。

4.bigint类型。这个类型也是8个字节，自己维护一个时间戳，表示范围比timestamp类型大多了。缺点就是要自己维护，不大方便。

为什么不直接存储图片、音频和视频等大容量内容？

在实际应用中，一般都是用HDFS来存储文件的，在MySQL中只会存文件的存放路径。但是实际上MySQL是有提供两个字段类型被涉及用来存放大容量文件的，一个是text类型，一个是blob类型。然而在生产中基本不会使用这两个类型，主要原因如下：

1.MySQL内存临时表不支持text和blob这样的大数据类型。如果查询中包含这样的数据，那么在排序等操作的时候就不能够使用内存临时表，只能使用磁盘临时表，会导致查询效率低下。

2.这两种类型会造成binlog的内容太多。因为数据的内容比较大，也就会造成binlog的内容比较多。我们知道，主从同步是通过binlog来进行的，如果binlog过大，就会导致主从同步的效率问题。

为什么字段要被定义为NOT NULL？

1.索引的性能不好。MySQL难以优化引用可空列查询，它会使得索引、索引统计和值更加复杂。可空列需要更多的存储空间，还需要MySQL内部进行特殊处理。可空列被索引后，每条记录都需要一个额外的字节。

2.查询可能会出现一些不可预料的结果。比如说使用count()聚合函数去统计一个可为空的字段，那么最后统计出来的记录数可能会和实际的记录数不同。

MySQL表设计面试题的总结

MySQL如果要深入提问的话，可以把你问到叫爸爸，因此平时要注意多积累。

另外要注意的是，上面的回答都是基于InnoDB存储引擎的。

 

"心结如果真的打不开，你就给它系成个花样儿，其实生活就需要这样。"