# Mysql 技能树 - 用 MySQL 解决实际问题 ## 0. 目录设计 - 实践 - 创建数据库、数据表、对表中的数据进行增删改查操作、使用函数、表与表之间的关联操作 - 进阶 - 程序存储在服务器上、利用突发事件来调用程序、在不改变存储结构的前提下创建虚拟表以方便查询等 - 优化 - 数据库的设计规范，还会带你创建数据模型，帮助你来理清设计思路 - 案例 - 你从 0 到 1 设计一个连锁超市的信息系统数据库 ## 1. 前言 - 鸡汤理论 - 在工作中，最重要的绝对不是你的知识储备量，而是你**解决实际问题的能力** - **正确的学习方法，远比你投入的时间更重要** - 快速应用在实战项目： 项目的实际需求 --> 解决问题所需的知识点 --> 用好这些知识的实战经验 - 配置一个自己顺手的数据库操作环境 - ## 2. ## 3. 优化 ### 3.1 范式：如何消除冗余和高效存取？ - 现象，什么样的表需要重新使用范式进行设计 - ![冗余供货表](pic/冗余供货表.png) - 表里重复的数据非常多：比如第一行和第二行的数据，同样是 3478 号单据，供货商编号、供货商名称和仓库，这 **3 个字段的信息完全相同**。可是这 2 条数据的**后 半部分又不相同**，因此，并不能认为它们是冗余数据而删除。 - 坏味道: - 在我们的工作场景中，这种由于数据表结构设计不合理，而导致的数据重复的现象并不少见，往往是系统虽然能够运行，承载能力却很差，稍微有点流量，就会出现**内存不足、 CUP 使用率飙升的情况，甚至会导致整个项目失败**。 - **第一范式** - 这张进货单表重新设计的第一步，就是要把所有的列，也就是字段，都确认一遍，确保**每个字段只包含一种数据**。如果各种数据都混合在一起，就无法通过后面的拆解，把重复的数据去掉。 - 其实，这就是第一范式所要求的：**所有的字段都是基本数据字段，不可进一步拆分**。 - 在我们的这张表里，“property”这一字段可以继续拆分。其他字段已经都是基本数据字段，不能再拆了。 - 经过优化，我们**把“property”这一字段，拆分成“specification（规格）”和“unit（单位）”**，这 2 个字段如下： - ![第一范式拆分供货表](pic/第一范式拆分供货表.png) - 这样处理之后，字段多了一个，但是每一个字段都成了**不可拆分的最小信息单元**，我们就可以在这个表的基础之上，着手进行进一步的优化了。这就要用到数据表设计的第二范式. - **第二范式** - 通过观察，我们可以发现，这个表的前 2 条记录的前 4 个字段完全一样。那可不可以通过拆分，把它们变成一条记录呢？当然是可以的，而且为了优化，必须要进行拆分。 - 第二范式就告诉了我们拆分的原则：**在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有字段，都必须完全依赖主键，不能只依赖主键的一部分。** - 根据这个要求，我们可以对表进行重新设计。 - 重新设计的第一步，就是要确定这个表的主键。通过观察发现，字段“listnumber”+“barcode”可以唯一标识每一条记录，可以作为主键。确定好了主键 以后，我们判断一下，哪些字段完全依赖主键，哪些字段只依赖于主键的一部分。同时，把只依赖于主键一部分的字段拆分出去，形成新的数据表。 - 首先，进货单明细表里面的“goodsname” “specification” “unit” 这些信息是商品的属性，只依赖于“barcode”，不完全依赖主键，可以拆分出去。我们把这 3 个字段加上 它们所依赖的字段“barcode”，拆分形成一个新的数据表“商品信息表”。 - 这样一来，原来的数据表就被拆分成了两个表。 - 商品信息表： - ![第二范式拆分后的商品信息表](pic/第二范式拆分后的商品信息表.png) - 进货单表： - ![第二范式拆分后的进货单表](pic/第二范式拆分后的进货单表.png) - 同样道理，字段“supplierid”“suppliername”“stock”只依赖于“listnumber”，不完全依赖于主键，所以，我们可以把“supplierid”“suppliername”“stock”这 3 个字段拆出去，再加上它们依赖的字段“listnumber”，就形成了一个新的表“进货单头表”。剩下的字段，会组成新的表，我们叫它“进货单明细表”。 - 这样一来，原来的数据表就拆分成了 3 个表。 - 进货单头表： - ![第二范式拆分下的进货单头表](pic/第二范式拆分下的进货单头表.png) - 进货单明细表： - ![第二范式拆分下的进货单明细表](pic/第二范式拆分下的进货单明细表.png) - 商品信息表： - ![第二范式拆分下的商品信息表](pic/第二范式拆分下的商品信息表.png) - 我们再来分析一下拆分后的 3 个表，保证这 3 个表都满足第二范式的要求。 - 在“商品信息表”中，字段“barcode”是有可能存在重复的，比如，用户门店可能有散装称重商品和自产商品，会存在条码共用的情况。所以，所有的字段都不能唯一标识表里 的记录。这个时候，我们必须给这个表加上一个主键，比如说是自增字段“itemnumber”。 - 现在，我们就可以把进货单明细表里面的字段“barcode”都替换成字段“itemnumber”，这就得到了新的进货单明细表和商品信息表。 - 进货单明细表(新)： - ![进货单明细表(新)](pic/进货单明细表(新).png) - 商品信息表(新)： - ![商品信息表(新)](pic/商品信息表(新).png) - 这样一来，我们拆分后的 3 个数据表中的数据都不存在重复，可以唯一标识。而且，表中的其他字段，都完全依赖于表的主键，不存在部分依赖的情况。所以，拆分后的 3 个数据 表就全部满足了第二范式的要求。 - **第三范式** - 我们的进货单头表，还有数据冗余的可能。因为“suppliername”依赖“supplierid”。那么，这个时候，就可以按照第三范式的原则进行拆分了。 - 第三范式要求数据表**在满足第二范式的基础上，不能包含那些可以由非主键字段派生出来的字段，或者说，不能存在依赖于非主键字段的字段**。 - 在刚刚的进货单头表中，字段“suppliername”依赖于非主键字段“supplierid”。因此，这个表不满足第三范式的要求。 - 那接下来，我们就进一步拆分下进货单头表，把它拆解成供货商表和进货单头表。 - 供货商表： - ![供货商表](pic/供货商表.png) - 进货单头表： - ![进货单头表](pic/进货单头表.png) - 这样一来，供货商表和进货单头表中的所有字段，都完全依赖于主键，不存在任何一个字段依赖于非主键字段的情况了。所以，这 2 个表就都满足第三范式的要求了。 - 但是，在进货单明细表中，quantity * importprice = importvalue，“importprice”“quantity”和“importvalue”这 3 个字段，可以通过 任意两个计算出第三个来，这就存在冗余字段。如果严格按照第三范式的要求，现在我们应该进行进一步优化。优化的办法是删除其中一个字段，只保留另外 2 个，这样就没有冗 余数据了。 - 真的可以这样做吗？要回答这个问题，我们就要先了解下实际工作中的业务优先原则。 - 业务优先的原则 - 所谓的业务优先原则，就是指一切以业务需求为主，技术服务于业务。**完全按照理论的设计不一定就是最优，还要根据实际情况来决定**。这里我们就来分析一下不同选择的利与弊。 - 对于 quantity * importprice = importvalue，看起来“importvalue”似乎是冗余字段，但并不会导致数据不一致。可是，如果我们把这个字段取消，是会影响业务的。 - 因为有的时候，供货商会经常进行一些促销活动，按金额促销，那他们拿来的进货单只有金额，没有价格。而“importprice”反而是通过“importvalue”÷“quantity”计算出 来的。因此，如果不保留“importvalue”字段，只有“importprice”和“quantity”的话，经过四舍五入，会产生较大的误差。这样日积月累，最终会导致查询结果出现较大偏 差，影响系统的可靠性。 - 我借助一个例子来说明下为什么会有偏差。 - 假设进货金额是 25.5 元，数量是 34，那么进货价格就等于 25.5÷34=0.74 元，但是如果用这个计算出来的进货价格来计算进货金额，那么，进货金额就等于 0.74×34=25.16 元，其中相差了 25.5-25.16=0.34 元。代码如下所示： - “importvalue”=25.5元，“quantity”=34，“importprice”=25.5÷34=0.74 - “importprice”=0.74元，“quantity”=34，“importvalue”=0.74*34=25.16 - 误差 = 25.5 - 25.16 = 0.34 - 现在你知道了，在我们这个场景下，“importvalue”是必须要保留的。 - 那么，换一种思路，如果我们保留“quantity”和“importvalue”，取消“importprice”，这样不是既能节省存储空间，又不会影响精确度吗？ - 其实不是的。“importprice”是系统的核心指标，涉及成本核算。几乎所有的财务、营运和决策支持模块，都要涉及到成本问题，如果取消“importprice”这个字段，那么系统的 运算成本、开发和运维成本，都会大大提高，得不偿失。 - 所以，本着业务优先的原则，在不影响系统可靠性的前提下，可以容忍一定程度的数据冗余，保留“importvalue”“importprice”和“quantity"。 - 因此，最后的结果是，我们可以把进货单表拆分成下面的 4 个表： - 供货商表： - ![供货商表](pic/供货商表.png) - 进货单头表： - ![进货单头表](pic/进货单头表.png) - 进货单明细表： - ![进货单明细表(新)](pic/进货单明细表(新).png) - 商品信息表： - ![商品信息表(新)](pic/商品信息表(新).png) - 这样一来，我们就避免了冗余数据，而且还能够满足业务的需求，这样的数据表设计，才是合格的设计。 - 一般来说，MySQL 的数据库设计满足第三范式，就足够了。不过，第三范式，并不是终极范式，还有 **BCNF 范式（也叫 BC 范式）、第四范式和第五范式**。 ### 3.2 ER模型：如何理清数据库设计思路？ - 接上面对表按范式进行拆解 - 但是，当我们按照这样的方式拆分一连串数据表时，却发现越拆越多，而且支离破碎。事实上，**局部最优的表，不仅有可能存在进一步拆分的情况，还有可能会出现数据缺失**。 - 毕竟，数据库设计是牵一发而动全身的。那有没有什么办法提前看到数据库的全貌呢？ - ER 模型就是一个这样的工具。ER 模型也叫作实体关系模型，是用来描述现实生活中客观存在的事物、事物的属性，以及事物之间关系的一种数据模型。 - 在开发基于数据库的信息系统的**设计阶段**，通常使用 ER 模型**来描述信息需求和信息特性**，帮助我们理清业务逻辑，从而设计出优秀的数据库。 - ER 模型包括哪些要素？ - 在 ER 模型里面，有三个要素，分别是**实体、属性和关系**。 - 实体。在 ER 模型中，用**矩形来表示**。实体分为两类，分别是**强实体和弱实体**。强实体是指不依赖于其他实体的实体；弱实体是指对另一个实体有很强 的依赖关系的实体。 - 属性，则是指**实体的特性**。比如超市的地址、联系电话、员工数等。在 ER 模型中用**椭圆形来表示**。 - 关系，则是指**实体之间的联系**。比如超市把商品卖给顾客，就是一种超市与顾客之间的联系。在 ER 模型中用**菱形来表示**。 - 需要注意的是，有的时候，**实体和属性不容易区分** - 该如何区分实体和属性呢？ - 一个原则：我们要从系统整体的角度出发去看，**可以独立存在的是实体，不可再分的是属性**。也就是说，属性不需要进一步描述，不能包含其他属性。 - 在 ER 模型的 3 个要素中，关系又可以分为 3 种类型，分别是 **1 对 1、1 对多和多对多** - 1 对 1：**指实体之间的关系是一一对应的**，比如个人与身份证信息之间的关系就是 1 对1 的关系。一个人只能有一个身份证信息，一个身份证信息也只属于一个人。 - 1 对多：**指一边的实体通过关系，可以对应多个另外一边的实体**。相反，另外一边的实体通过这个关系，则只能对应唯一的一边的实体。比如超市与超市里的收款机之间的从 属关系，超市可以拥有多台收款机，但是每一条收款机只能从属于一个超市。 - 多对多：**指关系两边的实体都可以通过关系对应多个对方的实体**。比如在进货模块中，供货商与超市之间的关系就是多对多的关系，一个供货商可以给多个超市供货，一个超 市也可以从多个供货商那里采购商品。 - 超市业务创建 ER 模型 - ![超市业务创建ER模型](pic/超市业务创建ER模型.png) - 在这个图中，供货商和超市之间的供货关系，两边的数字都不是 1，表示多对多的关系。 - 同样，超市和顾客之间的零售关系，也是多对多的关系。 - 这个 ER 模型，包括了 3 个实体之间的 2 种关系： - 超市从供货商那里采购商品； - 超市把商品卖给顾客。 - 有了这个 ER 模型，我们就可以从整体上理解超市的业务了。但是，这里没有包含属性，这样就无法体现实体和关系的具体特征。现在，我们需要把属性加上，用椭圆来表示，这样 我们得到的 ER 模型就更加完整了。 - ER 模型的细化 - 进货模块 - 实体及属性 - 供货商：名称、地址、电话、联系人。 - 商品：条码、名称、规格、单位、价格。 - 门店：编号、地址、电话、联系人。 - 仓库：编号、名称。 - 员工：工号、姓名、住址、电话、身份证号、职位。 - 实体关系 - 其中，供货商、商品和门店是强实体，因为它们不需要依赖其他任何实体。 - 而仓库和员工是弱实体，因为它们虽然都可以独立存在，但是它们都依赖门店这个实体，因此都是弱实体。 - ER 模型如下： - ![ER模型](pic/ER模型.png) - 这里我是用粗框矩形表示弱实体，用粗框菱形，表示弱实体与它依赖的强实体之间的关系。 - 零售模块 - 零售业务包括普通零售和会员零售两种模式。普通零售包含的实体，包括门店、商品和收银款台；会员零售包含的实体，包括门店、商品、会员和收银款台。 - 实体及属性 - 商品：条码、名称、规格、单位、价格。 - 会员：卡号、发卡门店、名称、电话、身份证、地址、积分、储值。 - 门店：编号、地址、电话、联系人。 - 收银款台：编号、名称。 - 实体关系 - 其中，商品和门店不依赖于任何其他实体，所以是强实体； - 会员和收银款台都依赖于门店，所以是弱实体。 - 零售模块的 ER 模型了： - ![零售ER模型](pic/零售ER模型.png) - 完整的 ER 模型： - ![完整ER模型](pic/完整ER模型.png) - 如何把 ER 模型图转换成数据表？ - 通过绘制 ER 模型，我们已经理清了业务逻辑，现在，我们就要进行非常重要的一步了：把绘制好的 ER 模型，转换成具体的数据表。 - 我来介绍下转换的原则。 - 一个实体通常转换成一个数据表； - 一个多对多的关系，通常也转换成一个数据表； - 一个 1 对 1，或者 1 对多的关系，往往通过表的外键来表达，而不是设计一个新的数据表； - 属性转换成表的字段。 ### 3.3 查询有点慢，语句该如何写？ - 查询分析语句 - 虽然 MySQL 的查询分析语句并不能直接优化查询，但是却可以帮助你了解 SQL 语句的执行计划，有助于你分析查询效率低下的原因，进而有针对性地进行优化。查询分析语句的 语法结构是： - { EXPLAIN | DESCRIBE | DESC }查询语句; ```shell mysql> SELECT itemnumber,quantity,price,transdate -> FROM demo.trans -> WHERE itemnumber=1 -> AND transdate>'2020-06-18 09:00:00' -> AND transdate<'2020-06-18 12:00:00'; +------------+----------+-------+---------------------+ | itemnumber | quantity | price | transdate | +------------+----------+-------+---------------------+ | 1 | 0.276 | 70.00 | 2020-06-18 11:04:00 | | 1 | 1.404 | 70.00 | 2020-06-18 11:10:57 | | 1 | 0.554 | 70.00 | 2020-06-18 11:18:12 | | 1 | 0.431 | 70.00 | 2020-06-18 11:27:39 | | 1 | 0.446 | 70.00 | 2020-06-18 11:42:08 | | 1 | 0.510 | 70.00 | 2020-06-18 11:56:43 | +------------+----------+-------+---------------------+ 6 rows in set (6.54 sec) ``` - 结果显示，有 6 条记录符合条件。这个简单的查询一共花去了 6.54 秒，这个速度显然太慢了。 - 现在，我们用下面的语句分析一下这个查询的具体细节： ```shell mysql> EXPLAIN SELECT itemnumber,quantity,price,transdate -- 分析查询执行情况 -> FROM demo.trans -> WHERE itemnumber=1 -- 通过商品编号筛选 -> AND transdate>'2020-06-18 09:00:00' -- 通过交易时间筛选 -> AND transdate<'2020-06-18 12:00:00'; +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key |key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | 1 | SIMPLE | trans | NULL | ALL | NULL | NULL | NULL | NULL | 4157166 | 1.11 | Using where | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ 1 row in set, 1 warning (0.00 sec) ``` - id：是一个查询序列号。 - table：表示与查询结果相关的表的名称。 - partition：表示查询访问的分区。 - key：表示优化器最终决定使用的索引是什么。 - key_len：表示优化器选择的索引字段按字节计算的长度。如果没有使用索引，这个值就是空。 - ref：表示哪个字段或者常量被用来与索引字段比对，以读取表中的记录。如果这个值是“func”，就表示用函数的值与索引字段进行比对。 - rows：表示为了得到查询结果，必须扫描多少行记录。 - filtered：表示查询筛选出的记录占全部表记录数的百分比。 - possible_key：表示 MySQL 可以通过哪些索引找到查询的结果记录。如果这里的值是空，就说明没有合适的索引可用。你可以通过查看 WHERE 条件语句中使用的字段，来 决定是否可以通过创建索引提高查询的效率 - Extra：表示 MySQL 执行查询中的附加信息。你可以点击这个链接查询详细信息。 - type：表示表是如何连接的。至于具体的内容，你可以参考下查询分析语句输出内容说明。 - 除了刚刚这些字段，还有 1 个比较重要，那就是 select_type。 - SIMPLE：表示简单查询，不包含子查询和联合查询。 - PRIMARY：表示是最外层的查询。 - UNION：表示联合查询中的第二个或者之后的查询。 - DEPENDENTUNION：表示联合查询中的第二个或者之后的查询，而且这个查询受外查询的影响。 - 关于这个 DEPENDENTUNION 取值， ```shell mysql> SELECT * -> FROM demo.goodsmaster a -> WHERE itemnumber in -> ( -> SELECTb.itemnumber -> FROM demo.goodsmaster b -> WHERE b.goodsname = '书' -> UNION -> SELECTc.itemnumber -> FROM demo.goodsmaster c -> WHERE c.goodsname = '笔' -> ); ... 2 rows in set (0.00 sec) ``` - MySQL 在执行的时候，会把这个语句进行优化，重新写成下面的语句： ```sql SELECT * FROM demo.goodsmaster a WHERE EXISTS ( SELECT b.id FROM demo.goodsmaster b WHERE b.goodsname = '书' ANDa.itemnumber=b.itemnumber UNION SELECT c.id FROM demo.goodsmaster c WHERE c.goodsname = '笔' AND a.itemnumber=c.itemnumber ); ``` - 在这里，子查询中的联合查询是： ```sql SELECT c.id FROM demo.goodsmaster c WHERE c.goodsname = '笔' AND a.itemnumber=c.itemnumber ``` - 这个查询就用到了与外部查询相关的条件 a.itemnumber=c.itemnumber，因此，查询类别就变成了“UNION DEPENDENT”。 - 分析一下刚刚的查询语句。 - 这个查询是一个简单查询，涉及的表是 demo.trans，没有分区，连接类型是扫描全表，没有索引，一共要扫描的记录数是 4157166。因此，查询速度慢的主要原因是没 有索引，导致必须要对全表进行扫描才能完成查询。所以，针对这个问题，可以通过创建索引的办法，来提高查询的速度。 - 下面，我们用条件语句中的筛选字段 itemnumber 和 transdate 分别创建索引： ```shell mysql> CREATE INDEX itemnumber_trans ON demo.trans(itemnumber); Query OK, 0 rows affected (59.86 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> CREATE INDEX transdate_trans ON demo.trans(transdate); Query OK, 0 rows affected (56.75 sec) Records: 0 Duplicates: 0 Warnings: 0 ``` - 2 种查询优化的方法 - 怎么在包含关键字“LIKE”和“OR”的条件语句中，利用索引提高查询效率。 - 使用关键字“LIKE” - “LIKE”经常被用在查询的限定条件中，通过通配符“%”来筛选符合条件的记录。比如 - WHERE字段 LIKE ‘aa%’，表示筛选出所有以“aa”开始的记录； - WHERE字段 LIKE ‘%aa%’，表示所有字段中包含“aa”的记录。 - 这里你要注意的是，**通配符在前面的筛选条件是不能用索引的**。也就是说，WHERE字段LIKE‘%aa’和WHERE字段 LIKE ‘%aa%’都不能使用索引，但是通配符在后面的筛选条 件，就可以使用索引。 - 使用关键字“OR” - 关键字“OR”表示“或”的关系，“WHERE 表达式 1 OR 表达式 2”，就表示表达式 1 或者表达式 2 中只要有一个成立，整个 WHERE 条件就是成立的。 - 需要注意的是，**只有当条件语句中只有关键字“OR”，并且“OR”前后的表达式中的字段都建有索引的时候，查询才能用到索引**。 - 我刚才已经用字段条码给商品流水表创建了一个索引，现在我再用商品编号“itemnumber”创建一个索引： ```shell mysql> CREATE INDEX trans_itemnumber ON demo.trans(itemnumber); Query OK, 0 rows affected (20.24 sec) Records: 0 Duplicates: 0 Warnings: 0 ``` - 我们先看一下关键字“OR”前后的表达式中的字段都创建了索引的情况： ```shell mysql> EXPLAIN SELECT * FROM demo.trans -> WHERE barcode LIKE '6953150%' -> OR itemnumber = 1; +----+-------------+-------+------------+-------------+----------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len +----+-------------+-------+------------+-------------+----------------------- | 1 | SIMPLE | trans | NULL | index_merge | trans_barcode,trans_itemnumber | t +----+-------------+-------+------------+-------------+----------------------- 1 row in set, 1 warning (0.01 sec) ``` - 我们先看一下关键字“OR”前后的表达式中的字段都创建了索引的情况： ```shell mysql> EXPLAIN SELECT * FROM demo.trans -> WHERE barcode LIKE '6953150%' -> OR itemnumber = 1; +----+-------------+-------+------------+-------------+----------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len +----+-------------+-------+------------+-------------+----------------------- | 1 | SIMPLE | trans | NULL | index_merge | trans_barcode,trans_itemnumber | t +----+-------------+-------+------------+-------------+----------------------- 1 row in set, 1 warning (0.01 sec) ``` - 说明优化器选择了合并索引的方式。因此，这个关键字“OR”前后的表达式中的字段都创建了索引的查询，是可以用到索引的。 ### 3.4 表太大了，如何设计才能提高性能？