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（索引包含整个字符串），执行顺序是这样的：
- 从index1索引树找到满足索引值是’ [email protected]’的这条记录，取得ID2的值；
- 回表到主键上查到主键值是ID2的行，判断email的值是正确的，将这行记录加入结果集；
- 取index1索引树上刚刚查到的位置的下一条记录，发现已经不满足email=' [email protected] ’的 条件了，循环结束。
这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。
如果使用的是index2（索引包含字符串前缀email(6)），执行顺序是这样的：
- 从index2索引树找到满足索引值是’zhangs’的记录，找到的第一个是ID1；
- 回表到主键上查到主键值是ID1的行，判断出email的值不是’ [email protected] ’，这行记录丢弃；
- 取index2上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出ID2，再到回表到ID索引上取整行然后判断，这次值对了，将这行记录加入结果集；
- 重复上一步，直到在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使用案例
- 主键索引 (简图)
二级索引zip_last_first (简图，这里省略了数据页等信息)
10.5 开启和关闭ICP性能对比
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。选择的标准是看能否使用表的索引吗？
回答：
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 业务字段尽量不要做主键
为了能够唯一地标识一个会员的信息，需要为 会员信息表设置一个主键。那么，怎么为这个表设置主 键，才能达到我们理想的目标呢？ 这里我们考虑业务字段做主键。
表数据如下：
在这个表里，哪个字段比较合适呢？
- 选择卡号（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元。那么，系统中就有了张三买书的流水记录，如下所示：
接着，我们查询一下 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 吗？
打开淘宝，看一下订单信息：
从上图可以发现，订单号不是自增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举例：
为什么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个二级索引，最终的结果如下所示：
从上图可以看到插入1亿条数据有序UUID是最快的，而且在实际业务使用中有序UUID在 业务端就可以生成 。还可以进一步减少SQL的交互次数。
另外，虽然有序UUID相比自增ID多了8个字节，但实际只增大了3G的存储空间，还可以接受。
在当今的互联网环境中，非常不推荐自增ID作为主键的数据库设计。更推荐类似有序UUID的全局 唯一的实现。
另外在真实的业务系统中，主键还可以加入业务和系统属性，如用户的尾号，机房的信息等。这样 的主键设计就更为考验架构师的水平了。
13.4.4 MySQL8.0之前主键方案：手动赋值
手动赋值字段做主键！
比如，设计各个分店的会员表的主键，因为如果每台机器各自产生的数据需要合并，就可能会出现主键重复的问题。
可以在总部 MySQL 数据库中，有一个管理信息表，在这个表中添加一个字段，专门用来记录当前会员编号的最大值。
门店在添加会员的时候，先到总部 MySQL 数据库中获取这个最大值，在这个基础上加 1，然后用这个值作为新会员的“id”，同时，更新总部 MySQL 数据库管理信息表中的当前会员编号的最大值。
这样一来，各个门店添加会员的时候，都对同一个总部 MySQL 数据库中的数据表字段进行操作，就解决了各门店添加会员时会员编号冲突的问题。