8种专坑运维的 SQL 写法,性能降低100倍,您不来看看?

1、LIMIT 语句

分页查询是最常用的场景之一,但也通常也是最容易出问题的地方。比如对于下面简单的语句,一般 DBA 想到的办法是在 type,name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引,性能迅速提升。

SELECT *FROM   operationWHERE  type = 'SQLStats'       AND name = 'SlowLog'ORDER  BY create_timeLIMIT  1000, 10;

好吧,可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时,程序员仍然会抱怨:我只取10条记录为什么还是慢?

要知道数据库也并不知道第1000000条记录从什么地方开始,即使有索引也需要从头计算一次。出现这种性能问题,多数情形下是程序员偷懒了。

在前端数据浏览翻页,或者大数据分批导出等场景下,是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下:

​​​​​​​

SELECT   *FROM     operationWHERE    type = 'SQLStats'AND      name = 'SlowLog'AND      create_time > '2017-03-16 14:00:00'ORDER BY create_time limit 10;

在新设计下查询时间基本固定,不会随着数据量的增长而发生变化。

2、隐式转换

SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句:​​​​​​​

mysql> explain extended SELECT *     > FROM   my_balance b     > WHERE  b.bpn = 14000000123     >       AND b.isverified IS NULL ;mysql> show warnings;| Warning | 1739 | Cannot use ref access on index 'bpn' due to type or collation conversion on field 'bpn'

其中字段 bpn 的定义为 varchar(20),MySQL 的策略是将字符串转换为数字之后再比较。函数作用于表字段,索引失效。

上述情况可能是应用程序框架自动填入的参数,而不是程序员的原意。现在应用框架很多很繁杂,使用方便的同时也小心它可能给自己挖坑。

3、关联更新、删除

虽然 MySQL5.6 引入了物化特性,但需要特别注意它目前仅仅针对查询语句的优化。对于更新或删除需要手工重写成 JOIN。

比如下面 UPDATE 语句,MySQL 实际执行的是循环/嵌套子查询(DEPENDENT SUBQUERY),其执行时间可想而知。​​​​​​​

UPDATE operation oSET    status = 'applying'WHERE  o.id IN (SELECT id                FROM   (SELECT o.id,                               o.status                        FROM   operation o                        WHERE  o.group = 123                               AND o.status NOT IN ( 'done' )                        ORDER  BY o.parent,                                  o.id                        LIMIT  1) t);

执行计划:​​​​​​​

+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+| id | select_type        | table | type  | possible_keys | key     | key_len | ref   | rows | Extra                                               |+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+| 1  | PRIMARY            | o     | index |               | PRIMARY | 8       |       | 24   | Using where; Using temporary                        || 2  | DEPENDENT SUBQUERY |       |       |               |         |         |       |      | Impossible WHERE noticed after reading const tables || 3  | DERIVED            | o     | ref   | idx_2,idx_5   | idx_5   | 8       | const | 1    | Using where; Using filesort                         |+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+

重写为 JOIN 之后,子查询的选择模式从 DEPENDENT SUBQUERY 变成 DERIVED,执行速度大大加快,从7秒降低到2毫秒。​​​​​​​

UPDATE operation o       JOIN  (SELECT o.id,                            o.status                     FROM   operation o                     WHERE  o.group = 123                            AND o.status NOT IN ( 'done' )                     ORDER  BY o.parent,                               o.id                     LIMIT  1) t         ON o.id = t.idSET    status = 'applying'

执行计划简化为:​​​​​​​

+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+| id | select_type | table | type | possible_keys | key   | key_len | ref   | rows | Extra                                               |+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+| 1  | PRIMARY     |       |      |               |       |         |       |      | Impossible WHERE noticed after reading const tables || 2  | DERIVED     | o     | ref  | idx_2,idx_5   | idx_5 | 8       | const | 1    | Using where; Using filesort                         |+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+

4、混合排序

MySQL 不能利用索引进行混合排序。但在某些场景,还是有机会使用特殊方法提升性能的。​​​​​​​

SELECT *FROM   my_order o       INNER JOIN my_appraise a ON a.orderid = o.idORDER  BY a.is_reply ASC,          a.appraise_time DESCLIMIT  0, 20

执行计划显示为全表扫描:​​​​​​​

+----+-------------+-------+--------+-------------+---------+---------+---------------+---------+-+| id | select_type | table | type   | possible_keys     | key     | key_len | ref      | rows    | Extra+----+-------------+-------+--------+-------------+---------+---------+---------------+---------+-+|  1 | SIMPLE      | a     | ALL    | idx_orderid | NULL    | NULL    | NULL    | 1967647 | Using filesort ||  1 | SIMPLE      | o     | eq_ref | PRIMARY     | PRIMARY | 122     | a.orderid |       1 | NULL           |+----+-------------+-------+--------+---------+---------+---------+-----------------+---------+-+

由于 is_reply 只有0和1两种状态,我们按照下面的方法重写后,执行时间从1.58秒降低到2毫秒。​​​​​​​

SELECT *FROM   ((SELECT *         FROM   my_order o                INNER JOIN my_appraise a                        ON a.orderid = o.id                           AND is_reply = 0         ORDER  BY appraise_time DESC         LIMIT  0, 20)        UNION ALL        (SELECT *         FROM   my_order o                INNER JOIN my_appraise a                        ON a.orderid = o.id                           AND is_reply = 1         ORDER  BY appraise_time DESC         LIMIT  0, 20)) tORDER  BY  is_reply ASC,          appraisetime DESCLIMIT  20;

5、EXISTS语句

MySQL 对待 EXISTS 子句时,仍然采用嵌套子查询的执行方式。如下面的 SQL 语句:​​​​​​​

SELECT *FROM   my_neighbor n       LEFT JOIN my_neighbor_apply sra              ON n.id = sra.neighbor_id                 AND sra.user_id = 'xxx'WHERE  n.topic_status < 4       AND EXISTS(SELECT 1                  FROM   message_info m                  WHERE  n.id = m.neighbor_id                         AND m.inuser = 'xxx')       AND n.topic_type <> 5

执行计划为:​​​​​​​

+----+--------------------+-------+------+-----+------------------------------------------+---------+-------+---------+ -----+| id | select_type        | table | type | possible_keys     | key   | key_len | ref   | rows    | Extra   |+----+--------------------+-------+------+ -----+------------------------------------------+---------+-------+---------+ -----+|  1 | PRIMARY            | n     | ALL  |  | NULL     | NULL    | NULL  | 1086041 | Using where                   ||  1 | PRIMARY            | sra   | ref  |  | idx_user_id | 123     | const |       1 | Using where          ||  2 | DEPENDENT SUBQUERY | m     | ref  |  | idx_message_info   | 122     | const |       1 | Using index condition; Using where |+----+--------------------+-------+------+ -----+------------------------------------------+---------+-------+---------+ -----+

去掉 exists 更改为 join,能够避免嵌套子查询,将执行时间从1.93秒降低为1毫秒。​​​​​​​

SELECT *FROM   my_neighbor n       INNER JOIN message_info m               ON n.id = m.neighbor_id                  AND m.inuser = 'xxx'       LEFT JOIN my_neighbor_apply sra              ON n.id = sra.neighbor_id                 AND sra.user_id = 'xxx'WHERE  n.topic_status < 4       AND n.topic_type <> 5

新的执行计划:​​​​​​​

+----+-------------+-------+--------+ -----+------------------------------------------+---------+ -----+------+ -----+| id | select_type | table | type   | possible_keys     | key       | key_len | ref   | rows | Extra                 |+----+-------------+-------+--------+ -----+------------------------------------------+---------+ -----+------+ -----+|  1 | SIMPLE      | m     | ref    | | idx_message_info   | 122     | const    |    1 | Using index condition ||  1 | SIMPLE      | n     | eq_ref | | PRIMARY   | 122     | ighbor_id |    1 | Using where      ||  1 | SIMPLE      | sra   | ref    | | idx_user_id | 123     | const     |    1 | Using where           |+----+-------------+-------+--------+ -----+------------------------------------------+---------+ -----+------+ -----+

6、条件下推

外部查询条件不能够下推到复杂的视图或子查询的情况有:

1、聚合子查询;2、含有 LIMIT 的子查询;3、UNION 或 UNION ALL 子查询;4、输出字段中的子查询;

如下面的语句,从执行计划可以看出其条件作用于聚合子查询之后:​​​​​​​

SELECT *FROM   (SELECT target,               Count(*)        FROM   operation        GROUP  BY target) tWHERE  target = 'rm-xxxx'
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+| id | select_type | table      | type  | possible_keys | key         | key_len | ref   | rows | Extra       |+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+|  1 | PRIMARY     | <derived2> | ref   | <auto_key0>   | <auto_key0> | 514     | const |    2 | Using where ||  2 | DERIVED     | operation  | index | idx_4         | idx_4       | 519     | NULL  |   20 | Using index |+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+

确定从语义上查询条件可以直接下推后,重写如下:

​​​​​​​

SELECT target,       Count(*)FROM   operationWHERE  target = 'rm-xxxx'GROUP  BY target

执行计划变为:​​​​​​​

+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+| 1 | SIMPLE | operation | ref | idx_4 | idx_4 | 514 | const | 1 | Using where; Using index |+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+

关于 MySQL 外部条件不能下推的详细解释说明请参考以前文章:MySQL · 性能优化 · 条件下推到物化表

7、提前缩小范围

先上初始 SQL 语句:​​​​​​​

SELECT *FROM   my_order o       LEFT JOIN my_userinfo u              ON o.uid = u.uid       LEFT JOIN my_productinfo p              ON o.pid = p.pidWHERE  ( o.display = 0 )       AND ( o.ostaus = 1 )ORDER  BY o.selltime DESCLIMIT  0, 15

该SQL语句原意是:先做一系列的左连接,然后排序取前15条记录。从执行计划也可以看出,最后一步估算排序记录数为90万,时间消耗为12秒。​​​​​​​

+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+| id | select_type | table | type   | possible_keys | key     | key_len | ref             | rows   | Extra                                              |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+|  1 | SIMPLE      | o     | ALL    | NULL          | NULL    | NULL    | NULL            | 909119 | Using where; Using temporary; Using filesort       ||  1 | SIMPLE      | u     | eq_ref | PRIMARY       | PRIMARY | 4       | o.uid |      1 | NULL                                               ||  1 | SIMPLE      | p     | ALL    | PRIMARY       | NULL    | NULL    | NULL            |      6 | Using where; Using join buffer (Block Nested Loop) |+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+

由于最后 WHERE 条件以及排序均针对最左主表,因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下,执行时间缩小为1毫秒左右。​​​​​​​​​​​​

SELECT *FROM (SELECT *FROM   my_order oWHERE  ( o.display = 0 )       AND ( o.ostaus = 1 )ORDER  BY o.selltime DESCLIMIT  0, 15) o     LEFT JOIN my_userinfo u              ON o.uid = u.uid     LEFT JOIN my_productinfo p              ON o.pid = p.pidORDER BY  o.selltime DESClimit 0, 15

再检查执行计划:子查询物化后(select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万,但是利用了索引以及 LIMIT 子句后,实际执行时间变得很小。​​​​​​​

+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+| id | select_type | table      | type   | possible_keys | key     | key_len | ref   | rows   | Extra                                              |+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+|  1 | PRIMARY     | <derived2> | ALL    | NULL          | NULL    | NULL    | NULL  |     15 | Using temporary; Using filesort                    ||  1 | PRIMARY     | u          | eq_ref | PRIMARY       | PRIMARY | 4       | o.uid |      1 | NULL                                               ||  1 | PRIMARY     | p          | ALL    | PRIMARY       | NULL    | NULL    | NULL  |      6 | Using where; Using join buffer (Block Nested Loop) ||  2 | DERIVED     | o          | index  | NULL          | idx_1   | 5       | NULL  | 909112 | Using where                                        |+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+

8、中间结果集下推

再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件):​​​​​​​

SELECT    a.*,          c.allocatedFROM      (              SELECT   resourceid              FROM     my_distribute d                   WHERE    isdelete = 0                   AND      cusmanagercode = '1234567'                   ORDER BY salecode limit 20) aLEFT JOIN          (              SELECT   resourcesid, sum(ifnull(allocation, 0) * 12345) allocated              FROM     my_resources                   GROUP BY resourcesid) cON        a.resourceid = c.resourcesid

那么该语句还存在其它问题吗?不难看出子查询 c 是全表聚合查询,在表数量特别大的情况下会导致整个语句的性能下降。

其实对于子查询 c,左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下,执行时间从原来的2秒下降到2毫秒。​​​​​​​

SELECT    a.*,          c.allocatedFROM      (                   SELECT   resourceid                   FROM     my_distribute d                   WHERE    isdelete = 0                   AND      cusmanagercode = '1234567'                   ORDER BY salecode limit 20) aLEFT JOIN          (                   SELECT   resourcesid, sum(ifnull(allocation, 0) * 12345) allocated                   FROM     my_resources r,                            (                                     SELECT   resourceid                                     FROM     my_distribute d                                     WHERE    isdelete = 0                                     AND      cusmanagercode = '1234567'                                     ORDER BY salecode limit 20) a                   WHERE    r.resourcesid = a.resourcesid                   GROUP BY resourcesid) cON        a.resourceid = c.resourcesid

但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销,还使得整个语句显的繁杂。使用 WITH 语句再次重写:

​​​​​​​

WITH a AS(         SELECT   resourceid         FROM     my_distribute d         WHERE    isdelete = 0         AND      cusmanagercode = '1234567'         ORDER BY salecode limit 20)SELECT    a.*,          c.allocatedFROM      aLEFT JOIN          (                   SELECT   resourcesid, sum(ifnull(allocation, 0) * 12345) allocated                   FROM     my_resources r,                            a                   WHERE    r.resourcesid = a.resourcesid                   GROUP BY resourcesid) cON        a.resourceid = c.resourcesid

总结

数据库编译器产生执行计划,决定着SQL的实际执行方式。但是编译器只是尽力服务,所有数据库的编译器都不是尽善尽美的。

上述提到的多数场景,在其它数据库中也存在性能问题。了解数据库编译器的特性,才能避规其短处,写出高性能的SQL语句。

程序员在设计数据模型以及编写SQL语句时,要把算法的思想或意识带进来。

编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担 。

最后,附 SQL 语句执行顺序:​​​​​​​

FROM<left_table>
ON<join_condition>
<join_type> JOIN<right_table>
WHERE<where_condition>
GROUP BY<group_by_list>
HAVING<having_condition>
SELECT
DISTINCT<select_list>
ORDER BY<order_by_condition>
LIMIT<limit_number>

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/796839.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

AIGC实战——ProGAN(Progressive Growing Generative Adversarial Network)

AIGC实战——ProGAN 0. 前言1. ProGAN2. 渐进式训练3. 其他技术3.1 小批标准差3.2 均等学习率3.3 逐像素归一化 4. 图像生成小结系列链接 0. 前言 我们已经学习了使用生成对抗网络 (Generative Adversarial Network, GAN) 解决各种图像生成任务。GAN 的模型架构和训练过程具有…

真实的招生办对话邮件及美国高校官网更新的反 AI 政策

这两年 ChatGPT 的热度水涨船高&#xff0c;其编写功能强大&#xff0c;且具备强大的信息整合效果&#xff0c;所以呈现的内容在一定程度上具备可读性。 那么&#xff0c;美国留学文书可以用 ChatGPT 写吗&#xff1f;使用是否有风险&#xff1f;外网博主 Kushi Uppu 在这个申…

C++20 semaphore(信号量) 详解

头文件在C20中是并发库技术规范&#xff08;Technical Specification, TS&#xff09;的一部分。信号量是同步原语&#xff0c;帮助控制多线程程序中对共享资源的访问。头文件提供了标准C方式来使用信号量。 使用环境 Windows&#xff1a;VS中打开项目属性&#xff0c;修改C语…

基于卷积神经网络的天气识别系统(pytorch框架)【python源码+UI界面+前端界面+功能源码详解】

功能演示&#xff1a; 天气识别系统&#xff0c;vgg16&#xff0c;mobilenet卷积神经网络&#xff08;pytorch框架&#xff09;_哔哩哔哩_bilibili &#xff08;一&#xff09;简介 基于卷积神经网络的天气识别系统是在pytorch框架下实现的&#xff0c;系统中有两个模型可选…

vue+elementUI实现表格组件的封装

效果图&#xff1a; 在父组件使用表格组件 <table-listref"table":stripe"true":loading"loading":set-table-h"slotProps.setMainCardBodyH":table-data"tableData":columns"columns.tableList || []":ra…

快速创建Python库文档:pdoc的简便之道

快速创建Python库文档:pdoc的简便之道 什么是pdoc&#xff1f; pdoc 是一个用于自动生成 Python 模块文档的库,它可以根据代码中的 docstrings 自动生成漂亮的文档网页. 为什么选择使用pdoc库&#xff1f; 简单易用: pdoc不需要复杂的配置,只需运行一个命令即可生成文档。 …

项目管理工具对比:甘特图与看板

许多项目管理工具都能帮助你规划、管理和跟踪项目&#xff0c;比如甘特图和看板。如果比较一下甘特图和看板&#xff0c;会发现两者在不同方面都对项目有价值。 让我们来看看看板与甘特图的区别&#xff0c;了解它们是如何工作的&#xff0c;以及各自的优缺点&#xff0c;看看…

基于Springboot的Java学习平台

采用技术 基于Springbootjava学习平台的设计与实现~ 开发语言&#xff1a;Java 数据库&#xff1a;MySQL 技术&#xff1a;SpringBootMyBatis 工具&#xff1a;IDEA/Ecilpse、Navicat、Maven 页面展示效果 系统功能模块 后台管理 用户注册 课程信息 作业信息 资料信息…

电工技术学习笔记——正弦交流电路

一、正弦交流电路 1. 正弦量的向量表示法 向量表示方法&#xff1a;正弦交流电路中&#xff0c;相量表示法是一种常用的方法&#xff0c;用于描述电压、电流及其相位关系。相量表示法将正弦交流信号表示为复数&#xff0c;通过复数的运算来描述电路中各种参数的相互关系 …

java中的正则表达式和异常

正则表达式&#xff1a; 作用一&#xff1a;用来校验数据格式是否合法 作用二&#xff1a;在文本中查找满足要求的内容 不用正则表达式&#xff1a;检验QQ号是否合法&#xff0c;要求全部是数字&#xff0c;长度在6-20&#xff0c;不能以0开头 public class test {public stat…

使用阿里云试用Elasticsearch学习:2.3 深入搜索——多字段搜索

查询很少是简单一句话的 match 匹配查询。通常我们需要用相同或不同的字符串查询一个或多个字段&#xff0c;也就是说&#xff0c;需要对多个查询语句以及它们相关度评分进行合理的合并。 有时候或许我们正查找作者 Leo Tolstoy 写的一本名为 War and Peace&#xff08;战争与…

【Linux实践室】Linux高级用户管理实战指南:创建与删除用户组操作详解

&#x1f308;个人主页&#xff1a;聆风吟_ &#x1f525;系列专栏&#xff1a;Linux实践室、网络奇遇记 &#x1f516;少年有梦不应止于心动&#xff0c;更要付诸行动。 文章目录 一. ⛳️任务描述二. ⛳️相关知识2.1 &#x1f514;Linux创建用户组命令2.1.1 知识点讲解2.1.2…

设计模式的区别

很多设计模式看起来或者感觉上差不多&#xff0c;其实不仅仅要从具体的实现方式来辨别&#xff0c;更要主要该种设计模式的意图。 那些容易混淆的设计模式&#xff0c;了解一下~_看了几种设计模式发现有点混乱,都差不多啊-CSDN博客

亲手开发全国海域潮汐表查询微信小程序详情教程及代码

最近在做一个全国海域潮汐表查询&#xff0c;可以为赶海钓鱼爱好者提供涨潮退潮时间表及潮高信息。 下面教大家怎么做一个这样的小程序。 主要功能&#xff0c;根据IP定位地理位置&#xff0c;自动查询出省份或城市的港口&#xff0c;进入后预测7天内港口潮汐表查询。 步骤&…

全坚固笔记本丨工业笔记本丨三防笔记本相较于普通笔记本有哪些优势?

三防笔记本和普通笔记本在设计和性能方面存在显著差异&#xff0c;三防笔记本相较于普通笔记本具备以下优势&#xff1a; 三防笔记本通常采用耐磨、耐摔的材料&#xff0c;并具有坚固的外壳设计&#xff0c;能够承受恶劣环境和意外碰撞&#xff0c;有效保护内部组件不受损坏。相…

【Linux】进程初步理解

个人主页 &#xff1a; zxctscl 如有转载请先通知 文章目录 1. 冯诺依曼体系结构1.1 认识冯诺依曼体系结构1.2 存储金字塔 2. 操作系统2.1 概念2.2 结构2.3 操作系统的管理 3. 进程3.1 进程描述3.2 Linux下的PCB 4. task_struct本身内部属性4.1 启动4.2 进程的创建方式4.2.1 父…

C/C++预处理过程

目录 前言&#xff1a; 1. 预定义符号 2. #define定义常量 3. #define定义宏 4. 带有副作用的宏参数 5. 宏替换的规则 6. 宏和函数的对比 7. #和## 8. 命名约定 9. #undef 10. 命令行定义 11. 条件编译 12. 头文件的包含 13. 其他预处理指令 总结&#x…

谷歌在生成式人工智能领域的挑战与机遇:内部纷争与市场压力下的战略调整

每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗&#xff1f;订阅我们的简报&#xff0c;深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同&#xff0c;从行业内部的深度分析和实用指南中受益。不要错过这个机会&#xff0c;成为AI领…

nest获取传入接口的参数

代码 Query 可接收接口路径中传入的参数 Body 可接收body中传入的参数 Headers 可接收Headers中传入的参数 import { Controller, Post, Get, Body, Query, Headers } from nestjs/common;// 定义getList参数类型 export class ListDto {readonly page: number;readonly page…

keycloak - 鉴权VUE

目录 一、前言 1、背景 2、实验版本 二、开始干活 1、keycloak配置 a、创建领域(realms) b、创建客户端 c、创建用户、角色 2、vue代码 a、依赖 b、main.js 三、未解决的问题 目录 一、前言 1、背景 2、实验版本 二、开始干活 1、keycloak配置 a、创建领域(r…