MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计

导航: 

【Java笔记+踩坑汇总】Java基础+进阶+JavaWeb+SSM+SpringBoot+瑞吉外卖+SpringCloud+黑马旅游+谷粒商城+学成在线+MySQL高级篇+设计模式+牛客面试题

目录

8. 优先考虑覆盖索引

8.1 什么是覆盖索引?

8.1.0 概念 

8.0.1 覆盖索引情况下,“不等于”索引生效

8.0.2 覆盖索引情况下,左模糊查询索引生效

8.2 覆盖索引的利弊

9. 给字符串添加索引

9.1 前缀索引

9.2 前缀索引不能用覆盖索引

10. 索引下推

10.1 介绍

10.2 ICP的使用条件

10.3 ICP的开启/关闭

10.4 ICP使用案例

10.5 开启和关闭ICP性能对比

11. 普通索引 vs 唯一索引

11.1 查询性能近似

11.2 普通索引更新性能更高,change buffer

11.3 change buffer的使用场景

12. SQL优化

12.1 EXISTS 和 IN 的区分

12.2 建议COUNT(*)或COUNT(1)

12.3 建议SELECT(字段)而不是SELECT(*)

12.4 LIMIT 1 对优化的影响

12.5 多使用COMMIT

13. 主键设计思路

13.1 自增主键的缺点

13.2 业务字段尽量不要做主键

13.3 淘宝订单号的主键设计

13.4 推荐的主键设计

13.4.1 核心与非核心业务主键策略选择

13.4.2 UUID的特点

13.4.3 MySQL 8.0主键方案:有序UUID

13.4.4 MySQL8.0之前主键方案:手动赋值


8. 优先考虑覆盖索引

8.1 什么是覆盖索引?

8.1.0 概念 

覆盖索引:一个索引包含了满足查询结果的数据就叫做覆盖索引,不需要回表等操作。

索引是高效找到行的一个方法,但是一般数据库也能使用索引找到一个列的数据,因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能通过读取索引就可以得到想要的数据,那就不需要读取行了。

覆盖索引是非聚簇索引的一种形式,它包括在查询里的SELECT、JOIN和WHERE子句用到的所有列 (即建索引的字段正好是覆盖查询条件中所涉及的字段)。简单说就是, 索引列+主键 包含 SELECT 到 FROM之间查询的列

8.0.1 覆盖索引情况下,“不等于”索引生效

没覆盖索引情况下,“不等于”索引失效:

没覆盖索引的情况下,使用“不等于”导致索引失效。因为如果使用索引,则需要依次遍历非聚簇索引B+树里所有叶节点,时间复杂度O(n),找到记录后还要回表,加在一起效率不如全表扫描,所以查询优化器就选择全表扫描了。

CREATE INDEX idx_age_name ON student(age, NAME);
#查所有字段,并且使用“不等于”,索引失效
EXPLAIN SELECT * FROM student WHERE age <> 20;

覆盖索引情况下,“不等于”索引生效:

覆盖索引,查的两个字段被联合索引给覆盖了,性能更高。虽然还是需要依次遍历非聚簇索引B+树里所有叶节点,时间复杂度O(n),但是不需要回表了,整体效率比不用索引更高,查询优化器就又使用索引了。

CREATE INDEX idx_age_name ON student(age, NAME);
#查的两个字段正好被联合索引“idx_age_name ”覆盖了,索引成功
EXPLAIN SELECT age,name FROM student WHERE age <> 20;

8.0.2 覆盖索引情况下,左模糊查询索引生效

没覆盖索引的情况下,左模糊查询导致索引失效

#没覆盖索引的情况下,左模糊查询导致索引失效
CREATE INDEX idx_age_name ON student(age, NAME);
EXPLAIN SELECT * FROM student WHERE NAME LIKE '%abc';

覆盖索引情况下,左模糊查询索引生效

主要原因也是因为走非聚簇索引B+树遍历叶节点,不回表,效率会比全表扫描时高,查询优化器选择效率高的方案。

#有覆盖索引的情况下,左模糊查询索引生效
CREATE INDEX idx_age_name ON student(age, NAME);
EXPLAIN SELECT id,age,NAME FROM student WHERE NAME LIKE '%abc';

上述都使用到了声明的索引,下面的情况则不然,查询列依然多了classId,结果是未使用到索引:

CREATE INDEX idx_age_name ON student(age, NAME);
EXPLAIN SELECT id,age,NAME,classId FROM student WHERE NAME LIKE '%abc';

8.2 覆盖索引的利弊

好处:

1.避免回表(Innodb表进行索引的二次查询)

Innodb是以聚集索引的顺序来存储的,对于lnnodb来说,二级索引在叶子节点中所保存的是行的主键信息,如果是用二级索引查询数据,在查找到相应的键值后,还需通过主键进行二次查询才能获取我们真实所需要的数据。

在覆盖索引中,二级索引的键值中可以获取所要的数据,避免了对主键的二次查询 ,减少了IO操作,提升了查询效率。

2.可以把随机IO变成顺序IO加快查询效率

由于覆盖索引是按键值的顺序存储的,对于IO密集型的范围查找来说,对比随机从磁盘读取每一行的数据I0要少的多,因此利用覆盖索引在访问时也可以把磁盘的随机读取的IO 转变成索引查找的 顺序IO。

由于覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段。

弊端:

具体问题要具体分析:

索引字段的维护总是有代价的。因此,在建立几余索引来支持覆盖索引时就需要权衡考虑了。这是业务DBA,或者称为业务数据架构师的工作。

9. 给字符串添加索引

9.1 前缀索引

有一张教师表,表定义如下:

create table teacher(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;

讲师要使用邮箱登录,所以业务代码中一定会出现类似于这样的语句:

mysql> select col1, col2 from teacher where email='xxx';

如果email这个字段上没有索引,那么这个语句就只能做 全表扫描

MySQL是支持前缀索引的。默认地,如果你创建索引的语句不指定前缀长度,那么索引就会包含整个字符串。

mysql> alter table teacher add index index1(email);
#或
mysql> alter table teacher add index index2(email(6));

这两种不同的定义在数据结构和存储上有什么区别呢?下图就是这两个索引的示意图。

以及

如果使用的是index1(索引包含整个字符串),执行顺序是这样的:

  1. 从index1索引树找到满足索引值是’ [email protected]’的这条记录,取得ID2的值;
  2. 回表到主键上查到主键值是ID2的行,判断email的值是正确的,将这行记录加入结果集;
  3. 取index1索引树上刚刚查到的位置的下一条记录,发现已经不满足email=' [email protected] ’的 条件了,循环结束。

这个过程中,只需要回主键索引取一次数据,所以系统认为只扫描了一行。

如果使用的是index2(索引包含字符串前缀email(6)),执行顺序是这样的:

  1. 从index2索引树找到满足索引值是’zhangs’的记录,找到的第一个是ID1;
  2. 回表到主键上查到主键值是ID1的行,判断出email的值不是’ [email protected] ’,这行记录丢弃;
  3. 取index2上刚刚查到的位置的下一条记录,发现仍然是’zhangs’,取出ID2,再到回表到ID索引上取整行然后判断,这次值对了,将这行记录加入结果集;
  4. 重复上一步,直到在index2上取到的值不是’zhangs’时,循环结束。

也就是说使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本。前面 已经讲过区分度,区分度越高越好。因为区分度越高,意味着重复的键值越少。

9.2 前缀索引不能用覆盖索引

因为非聚簇索引树查到的数据是前缀和id,前缀不是完整数据,必须要回表到聚簇索引树。

所以使用前缀索引就用不上覆盖索引对查询性能的优化了,这也是你在选择是否使用前缀索引时需要考虑的一个因素。

10. 索引下推

10.1 介绍

索引下推(ICP,Index Condition Pushdown)是MySQL 5.6中新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式。

  • 如果没有ICP:联合索引某字段是模糊查询(非左模糊)时,该字段进行条件判断后,后面几个字段不能用来直接条件判断,必须回表后再判断。
  • 启用ICP 后:联合索引某字段是模糊查询(非左模糊)时,该字段进行条件判断后,后面几个字段可以直接条件判断,判断过滤后再回表对不包含在联合索引内的字段条件进行判断。主要优化点是在回表之前过滤,减少回表次数。主要应用:模糊查询(非左模糊)导致索引里该字段后面的字段无序,必须要回表判断,而使用了索引下推,就不需要回表,直接在联合索引树里判断。

如果没有ICP ,存储引擎会遍历索引以定位基表中的行,并将它们返回给 MySQL 服务器,由 MySQL 服务器评古WHERE 后面的条件是否保留行。
启用ICP 后,如果部分 WHERE 条件可以仅使用索引中的列进行筛选,则MySQL 服务器会把这部分WHERE 条件放到存储引擎筛选。然后,存储引擎通过使用索引条目来筛选数据,并且只有在满足这一条件时才从表中读取行。

好处: ICP可以减少存储引擎必须访问基表的次数和MySQL服务器必须访问存储引擎的次数。但是,ICP的 加速效果 取决于在存储引擎内通过 ICP筛选 的数据的比例。 

举例:

不支持索引下推的联合索引:例如索引(name,age),查询name like 'z%' and age=?,模糊查询导致age无序。在联合索引树查询时只会查name,后面的age乱序不能直接进行条件判断,必须回表后再判断age。

而支持索引下推的联合索引:例如索引(name,age),查询name like 'z%' and age and address,在联合索引树查询时不止查name,还会判断后面的age,过滤后再回表判断address。

CREATE INDEX idx_name_age ON student(name,age);
#索引失败;非覆盖索引时,左模糊导致索引失效
EXPLAIN SELECT * FROM student WHERE name like '%bc%' AND age=30;
#索引成功;MySQL5.6引入索引下推,where后面的name和age都在联合索引里,可以又过滤又索引,不用回表,索引生效
EXPLAIN SELECT * FROM student WHERE `name` like 'bc%' AND age=30;
#索引成功;name走索引,age用到索引下推过滤,classid不在联合索引里,需要回表。
EXPLAIN SELECT * FROM student WHERE `name` like 'bc%' AND age=30 AND classid=2;

好处: 某些场景下ICP可以大大减少回表次数,提高性能。ICP可以减少存储引擎必须访问基表的次数和MySQL服务器必须访问存储引擎的次数。但是,ICP的 加速效果 取决于在存储引擎内通过 ICP筛选 的数据的比例。

10.2 ICP的使用条件

  • 表的访问类型为 range 、 ref 、 eq_ref 或者 ref_or_null 。
  • 存储引擎:ICP可以用于InnDB和MyISAM存储引擎
  • 必须二级索引:对于InnoDB表,ICP仅用于二级索引。ICP的目标是减少全行读取次数,从而减少I/O操作。
  • 必须不是覆盖索引:当SQL使用覆盖索引时,不支持ICP优化方法。因为这种情况下使用ICP不会减少I/O。
  • 相关子查询的条件不能使用ICP
  • 必须5.6版本及以上:MySQL 5.6版本引入并默认开启,之前版本不支持索引下推。
  • 必须where字段在索引列中:并非全部where条件都可以用ICP筛选,如果where条件的字段不在索引列中,还是要读取整表的记录到server端做where过滤。

10.3 ICP的开启/关闭

  • 默认情况下启动索引条件下推。可以通过设置系统变量optimizer_switch控制:index_condition_pushdown
# 打开索引下推
SET optimizer_switch = 'index_condition_pushdown=on';

# 关闭索引下推
SET optimizer_switch = 'index_condition_pushdown=off';
  • 当使用索引条件下推是,EXPLAIN语句输出结果中Extra列内容显示为Using index condition

10.4 ICP使用案例

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第1张图片

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第2张图片

  • 主键索引 (简图)

二级索引zip_last_first (简图,这里省略了数据页等信息)

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第3张图片

10.5 开启和关闭ICP性能对比

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第4张图片

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第5张图片

11. 普通索引 vs 唯一索引

从性能的角度考虑,你选择唯一索引还是普通索引呢?选择的依据是什么呢?

假设,我们有一个主键列为ID的表,表中有字段k,并且在k上有索引,假设字段 k 上的值都不重复。

这个表的建表语句是:

mysql> create table test(
id int primary key,
k int not null,
name varchar(16),
index (k)
)engine=InnoDB;

表中R1~R5的(ID,k)值分别为(100,1)、(200,2)、(300,3)、(500,5)和(600,6)。

11.1 查询性能近似

假设,执行查询的语句是 select id from test where k=5。

  • 对于普通索引来说,查找到满足条件的第一个记录(5,500)后,需要查找下一个记录,直到碰到第一个不满足k=5条件的记录。
  • 对于唯一索引来说,由于索引定义了唯一性,查找到第一个满足条件的记录后,就会停止继续检索。

那么,这个不同带来的性能差距会有多少呢?答案是, 微乎其微

11.2 普通索引更新性能更高,change buffer

写缓存(change buffer):

当需要更新一个数据页时,如果数据页在内存中就直接更新,而如果这个数据页还没有在内存中的话, 在不影响数据一致性的前提下, InooDB会将这些更新操作缓存在change buffer中 ,这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候,将数据页读入内存,然后执行change buffer中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

merge :将change buffer中的操作应用到原数据页,得到最新结果的过程称为 merge 。除了访问这个数据页会触发merge外,系统有后台线程会定期merge。在数据库正常关闭(shutdown)的过程中,也会执行merge 操作。

如果能够将更新操作先记录在change buffer, 减少读磁盘 ,语句的执行速度会得到明显的提升。而且, 数据读入内存是需要占用 buffer pool 的,所以这种方式还能够 避免占用内存,提高内存利用率。

唯一索引的更新就不能使用change buffer ,实际上也只有普通索引可以使用。

做好区分:

  • 读数据用的是缓冲池buffer pool
  • 重做日志有个redo log buffer,是将缓冲池里更新的数据写入redo log buffer,事务提交时根据刷盘策略,将redo log buffer刷盘到redo log file或page cache。

11.3 change buffer的使用场景

  • 普通索引和唯一索引应该怎么选择?其实,这两类索引在查询能力上是没差别的,主要考虑的是对更新性能的影响。所以,建议你尽量选择普通索引

  • 在实际使用中会发现, 普通索引 和 change buffer 的配合使用,对于 数据量大 的表的更新优化 还是很明显的。

  • 不适合change buffer情况:如果所有的更新后面,都马上伴随着对这个记录的查询 ,那么你应该关闭change buffer 。而在其他情况下,change buffer都能提升更新性能。

  • 事务提交的时候,change buffer 的操作也会记录到redo log中,所以崩溃恢复时,change buffer 也可以找回来。

  • 由于唯一索引用不上change buffer的优化机制,因此如果业务可以接受 ,从性能角度出发建议优先考虑非唯一索引。但是如果"业务可能无法确保"的情况下,怎么处理呢?

    • 首先, 业务正确性优先 。我们的前提是“业务代码已经保证不会写入重复数据”的情况下,讨论性能 问题。如果业务不能保证,或者业务就是要求数据库来做约束,那么没得选,必须创建唯一索引。 这种情况下,本节的意义在于,如果碰上了大量插入数据慢、内存命中率低的时候,给你多提供一 个排查思路。
    • 然后,在一些“ 归档库 ”的场景,你是可以考虑使用唯一索引的。比如,线上数据只需要保留半年, 然后历史数据保存在归档库。这时候,归档数据已经是确保没有唯一键冲突了。要提高归档效率, 可以考虑把表里面的唯一索引改成普通索引。

12. SQL优化

12.1 EXISTS 和 IN 的区分

问题:

不太理解哪种情况下应该使用 EXISTS,哪种情况应该用 IN。选择的标准是看能否使用表的索引吗?

回答:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第6张图片

12.2 建议COUNT(*)或COUNT(1)

统计行数尽量用COUNT(1),COUNT(*):COUNT(1),COUNT(*)时,查询优化器会优先选用有索引的、占用空间最小的二级索引树进行统计,只有找不到非聚簇索引树时采用使用聚簇索引树统计,空间占用大。当然也能COUNT(最小空间二级索引字段),但麻烦不如交给优化器自动选择。

SELECT COUNT(*) FROM student;
SELECT COUNT(1) FROM student;

 问:在 MySQL 中统计数据表的行数,可以使用三种方式: SELECT COUNT(*) 、 SELECT COUNT(1) 和 SELECT COUNT(具体字段) ,使用这三者之间的查询效率是怎样的?

答:如果你要统计的是某个字段的非空数据行数,则另当别论,毕竟比较执行效率的前提是结果一样才可以。

COUNT(*)和COUNT(1): COUNT(*) 和COUNT(1)都是对所有结果进行COUNT(*)COUNT(*)和COUNT(1)本质上并没有区别(二者执行时间可能略有差别,不过你还是可以把它俩的执行效率看成是相等的)。如果有 WHERE 子句,则是对所有符合筛选条件的数据行进行统计,如果没有 WHERE子句,则是对数据表的数据行数进行统计。

MylSAM 统计只需O(1):如果是 MylSAM 存储引擎,统计数据表的行数只需要 O(1)的复杂度,这是因为每张 MyISAM 的数据表都有一个 meta 信息存储了 row_count 值,而一致性则由表级锁来保证。 如果是InnoDB 存储引擎,因为innoDB 支持事务,采用行级锁和 MVCC机制,所以无法像 MyISAM一样,维护1个row_count变量,因此需要采用扫描全表,是O(n)的复杂度,进行循环+计数的方式来完成统计。

选择建议:在ImnoDB中,如果采用COUNT(具体字段)来统计数据行数,要尽量采用二级索引。因为主键是聚簇索引,聚簇索引叶节点包含整个记录,统计时要加载到内存的数据量更大,性能就差一点。对于COUNT(*)和 COUNT(1)来说,它们不需要查找具体的行,只是统计行数,系统会自动采用占用空间更小的二级索引来进行统计。 如果有多个二级索引,会使用 key_len 小的二级索引进行扫描。当没有二级索引的时候,才会采用主键索引来进行统计。

12.3 建议SELECT(字段)而不是SELECT(*)

在表查询中,建议明确字段,不要使用 * 作为查询的字段列表,推荐使用SELECT <字段列表> 查询。原因:

① MySQL 在解析的过程中,会通过查询数据字典将“*”按序转换成所有列名,这会大大的耗费资源和时间。

② 无法使用覆盖索引

12.4 LIMIT 1 对优化的影响

针对的是会扫描全表的 SQL 语句,如果你可以确定结果集只有一条,那么加上 LIMIT 1 的时候,当找到一条结果的时候就不会继续扫描了,这样会加快查询速度。

如果数据表已经对字段建立了唯一索引,那么可以通过索引进行查询,不会全表扫描的话,就不需要加上 LIMIT 1 了。

12.5 多使用COMMIT

只要有可能,在程序中尽量多使用 COMMIT,这样程序的性能得到提高,需求也会因为 COMMIT 所释放的资源而减少。

COMMIT 所释放的资源:

  • 回滚段上用于恢复数据的信息
  • 被程序语句获得的锁
  • redo / undo log buffer 中的空间
  • 管理上述 3 种资源中的内部花费

13. 主键设计思路

聊一个实际问题:淘宝的数据库,主键是如何设计的?

某些错的离谱的答案还在网上年复一年的流传着,甚至还成为了所谓的MySQL军规。其中,一个最明显的错误就是关于MySQL的主键设计。

大部分人的回答如此自信:用8字节的 BIGINT 做主键,而不要用INT。

这样的回答,只站在了数据库这一层,而没有 从业务的角度 思考主键。主键就是一个自增ID吗?目前用自增做主键,架构设计上可能连及格都拿不到

13.1 自增主键的缺点

自增ID做主键,简单易懂,几乎所有数据库都支持自增类型,只是实现上各自有所不同而已。自增ID除了简单,其他都是缺点,总体来看存在以下几方面的问题:

  • 可靠性不高

    存在自增ID回溯的问题,这个问题直到最新版本的MySQL 8.0才修复。

  • 安全性不高

    对外暴露的接口可以非常容易猜测对应的信息。比如:/User/1/这样的接口,可以非常容易猜测用户ID的 值为多少,总用户数量有多少,也可以非常容易地通过接口进行数据的爬取。

  • 性能差

    自增ID的性能较差,需要在数据库服务器端生成。

  • 需要额外执行函数得知自增值,影响性能

    业务还需要额外执行一次类似 last_insert_id() 的函数才能知道刚才插入的自增值,这需要多一次的 网络交互。在海量并发的系统中,多1条SQL,就多一次性能上的开销

  • 全局不唯一,高并发时自增锁竞争影响性能

    最重要的一点,自增ID是局部唯一,只在当前数据库实例中唯一,而不是全局唯一,在任意服务器间都是唯一的。对于目前分布式系统来说,这简直就是噩梦。

  • 分库分表、数据迁移时,自增不再适用。

13.2 业务字段尽量不要做主键

为了能够唯一地标识一个会员的信息,需要为 会员信息表设置一个主键。那么,怎么为这个表设置主 键,才能达到我们理想的目标呢? 这里我们考虑业务字段做主键。

表数据如下:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第7张图片

在这个表里,哪个字段比较合适呢?

  • 选择卡号(cardno)

会员卡号(cardno)看起来比较合适,因为会员卡号不能为空,而且有唯一性,可以用来 标识一条会员 记录。

mysql> CREATE TABLE demo.membermaster
-> (
-> cardno CHAR(8) PRIMARY KEY, -- 会员卡号为主键
-> membername TEXT,
-> memberphone TEXT,
-> memberpid TEXT,
-> memberaddress TEXT,
-> sex TEXT,
-> birthday DATETIME
-> );
Query OK, 0 rows affected (0.06 sec)

不同的会员卡号对应不同的会员,字段“cardno”唯一地标识某一个会员。如果都是这样,会员卡号与会员一一对应,系统是可以正常运行的。

但实际情况是,会员卡号可能存在重复使用的情况。比如,张三因为工作变动搬离了原来的地址,不再到商家的门店消费了(退还了会员卡),于是张三就不再是这个商家门店的会员了。但是,商家不想让这个会员卡空着,就把卡号是“10000001”的会员卡发给了王五。

从系统设计的角度看,这个变化只是修改了会员信息表中的卡号是“10000001”这个会员信息,并不会影响到数据一致性。也就是说,修改会员卡号是“10000001”的会员信息,系统的各个模块,都会获取到修改后的会员信息,不会出现“有的模块获取到修改之前的会员信息,有的模块获取到修改后的会员信息,而导致系统内部数据不一致”的情况。因此,从信息系统层面上看是没问题的。
但是从使用系统的业务层面来看,就有很大的问题了,会对商家造成影响。

比如,我们有一个销售流水表(trans),记录了所有的销售流水明细。2020年12月01日,张三在门店购买了一本书,消费了89元。那么,系统中就有了张三买书的流水记录,如下所示:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第8张图片

接着,我们查询一下 2020 年 12 月 01 日的会员销售记录:

mysql> SELECT b.membername,c.goodsname,a.quantity,a.salesvalue,a.transdate
-> FROM demo.trans AS a
-> JOIN demo.membermaster AS b
-> JOIN demo.goodsmaster AS c
-> ON (a.cardno = b.cardno AND a.itemnumber=c.itemnumber);
+------------+-----------+----------+------------+---------------------+
| membername | goodsname | quantity | salesvalue | transdate |
+------------+-----------+----------+------------+---------------------+
|     张三   | 书         | 1.000    | 89.00      | 2020-12-01 00:00:00 |
+------------+-----------+----------+------------+---------------------+
1 row in set (0.00 sec)

如果会员卡“10000001”又发给了王五,我们会更改会员信息表。导致查询时:

mysql> SELECT b.membername,c.goodsname,a.quantity,a.salesvalue,a.transdate
-> FROM demo.trans AS a
-> JOIN demo.membermaster AS b
-> JOIN demo.goodsmaster AS c
-> ON (a.cardno = b.cardno AND a.itemnumber=c.itemnumber);
+------------+-----------+----------+------------+---------------------+
| membername | goodsname | quantity | salesvalue | transdate |
+------------+-----------+----------+------------+---------------------+
| 王五        | 书        | 1.000    | 89.00      | 2020-12-01 00:00:00 |
+------------+-----------+----------+------------+---------------------+
1 row in set (0.01 sec)

这次得到的结果是:王五在 2020 年 12 月 01 日,买了一本书,消费 89 元。显然是错误的!结论:千万不能把会员卡号当做主键。

  • 选择会员电话或身份证号

会员电话可以做主键吗?不行的。在实际操作中,手机号也存在被运营商收回,重新发给别人用的情况。

那身份证号行不行呢?好像可以。因为身份证决不会重复,身份证号与一个人存在一一对应的关系。可问题是,身份证号属于个人隐私,顾客不一定愿意给你。要是强制要求会员必须登记身份证号,会把很多客人赶跑的。其实,客户电话也有这个问题,这也是我们在设计会员信息表的时候,允许身份证号和电话都为空的原因。

所以,建议尽量不要用跟业务有关的字段做主键。毕竟,作为项目设计的技术人员,我们谁也无法预测 在项目的整个生命周期中,哪个业务字段会因为项目的业务需求而有重复,或者重用之类的情况出现。

经验: 刚开始使用 MySQL 时,很多人都很容易犯的错误是喜欢用业务字段做主键,想当然地认为了解业务需求,但实际情况往往出乎意料,而更改主键设置的成本非常高。

13.3 淘宝订单号的主键设计

在淘宝的电商业务中,订单服务是一个核心业务。请问, 订单表的主键淘宝是如何设计的呢?是自增ID 吗?

打开淘宝,看一下订单信息:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第9张图片

从上图可以发现,订单号不是自增ID!我们详细看下上述4个订单号:

1550672064762308113
1481195847180308113
1431156171142308113
1431146631521308113

订单号是19位的长度,且订单的最后5位都是一样的,都是08113。且订单号的前面14位部分是单调递增的。

大胆猜测,淘宝的订单ID设计应该是:

订单ID = 时间 + 去重字段 + 用户ID后6位尾号

这样的设计能做到全局唯一,且对分布式系统查询及其友好。

13.4 推荐的主键设计

13.4.1 核心与非核心业务主键策略选择

非核心业务 :对应表的主键自增ID,如告警、日志、监控等信息。

核心业务 :主键设计至少应该是全局唯一且是单调递增。全局唯一保证在各系统之间都是唯一的,单调 递增是希望插入时不影响数据库性能。推荐使用MySQL8.0 改造为有序UUID,具体通过函数uuid_to_bin(@uuid,true)将UUID转化为有序UUID

13.4.2 UUID的特点

这里推荐最简单的一种主键设计:UUID。

全局唯一,占用36字节,数据无序,插入性能差。

认识UUID:

  • 为什么UUID是全局唯一的?
  • 为什么UUID占用36个字节?
  • 为什么UUID是无序的?

MySQL数据库的UUID组成如下所示:

UUID = 时间+UUID版本(16字节)- 时钟序列(4字节) - MAC地址(12字节)

我们以UUID值e0ea12d4-6473-11eb-943c-00155dbaa39d举例:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第10张图片

为什么UUID是全局唯一的? 

在UUID中时间部分占用60位,存储的类似TIMESTAMP的时间戳,但表示的是从1582-10-15 00:00:00.00 到现在的100ns的计数。可以看到UUID存储的时间精度比TIMESTAMPE更高,时间维度发生重复的概率降低到1/100ns

时钟序列是为了避免时钟被回拨导致产生时间重复的可能性。MAC地址用于全局唯一

为什么UUID占用36个字节?

UUID根据字符串进行存储,设计时还带有无用"-"字符串,因此总共需要36个字节。

为什么UUID是随机无序的呢?

因为UUID的设计中,将时间低位放在最前面,而这部分的数据是一直在变化的,并且是无序。

13.4.3 MySQL 8.0主键方案:有序UUID

改造为有序:若将时间高低位互换,则时间就是单调递增的了,也就变得单调递增了。MySQL 8.0可以更换时间低位和时间高位的存储方式,这样UUID就是有序的UUID了。

优化空间占用:MySQL 8.0还解决了UUID存在的空间占用的问题,除去了UUID字符串中无意义的"-"字符串,并且将字符串用二进制类型保存,这样存储空间降低为了16字节。

可以通过MySQL8.0提供的uuid_to_bin函数实现上述功能,同样的,MySQL也提供了bin_to_uuid函数进行转化:

SET @uuid = UUID();
SELECT @uuid,uuid_to_bin(@uuid),uuid_to_bin(@uuid,TRUE);

通过函数uuid_to_bin(@uuid,true)将UUID转化为有序UUID了。全局唯一 + 单调递增,这不就是我们想要的主键!

有序UUID性能测试:

16字节的有序UUID,相比之前8字节的自增ID,性能和存储空间对比究竟如何呢?

我们来做一个测试,插入1亿条数据,每条数据占用500字节,含有3个二级索引,最终的结果如下所示:

MySQL高级篇——覆盖索引、前缀索引、索引下推、SQL优化、主键设计_第11张图片

从上图可以看到插入1亿条数据有序UUID是最快的,而且在实际业务使用中有序UUID在 业务端就可以生成 。还可以进一步减少SQL的交互次数。

另外,虽然有序UUID相比自增ID多了8个字节,但实际只增大了3G的存储空间,还可以接受。

在当今的互联网环境中,非常不推荐自增ID作为主键的数据库设计。更推荐类似有序UUID的全局 唯一的实现。

另外在真实的业务系统中,主键还可以加入业务和系统属性,如用户的尾号,机房的信息等。这样 的主键设计就更为考验架构师的水平了。

13.4.4 MySQL8.0之前主键方案:手动赋值

手动赋值字段做主键!

比如,设计各个分店的会员表的主键,因为如果每台机器各自产生的数据需要合并,就可能会出现主键重复的问题。

可以在总部 MySQL 数据库中,有一个管理信息表,在这个表中添加一个字段,专门用来记录当前会员编号的最大值。

门店在添加会员的时候,先到总部 MySQL 数据库中获取这个最大值,在这个基础上加 1,然后用这个值作为新会员的“id”,同时,更新总部 MySQL 数据库管理信息表中的当前会员编号的最大值。

这样一来,各个门店添加会员的时候,都对同一个总部 MySQL 数据库中的数据表字段进行操作,就解决了各门店添加会员时会员编号冲突的问题。

你可能感兴趣的:(Java学习路线,数据库,java,sql)