在线QQ客服：1922638
专业的SQL Server、MySQL数据库同步软件
？在我的代码中，登录时需要放置所有与用户相关的用户，角色，部门，职位和权限(在菜单中放置了权限，每2个表都有一个相关表)。
耗时:
由于用户名在程序中受到唯一控制，因此该用户名将创建唯一索引。 (提示:由于我的程序使用的框架，请先登录成为用户
查找用户信息，然后比较密码。如果同时查询用户名和密码，则可以在”密码”字段中添加普通索引。 )
出于这种原因，本文从头开始介绍了SQL数据库SQL优化(除外)的原因:SQL执行性能分析
=” =”
？用户表类型级别已达到最高效率。
签出计划:
？
？从上图可以看到，fkur(即用户角色表)的类型仍然是ALL。在这里，我们对该表进行优化。
？
，数据少效果不明显，但请参阅按查询计划键入
？ ？效果不明显，但要看查询计划的类型
？
？
看一下查询计划，它的类型仍然是ALL(这里是一个坑，如果数据太少，查询将自动确定是去索引还是到完整表，因此表中的数据必须大于2) *查询的数据索引只能是有效的)
？至此，索引的添加完成，主要是添加唯一索引和普通索引。
？当前，在由Ali Java开发的规范手册中，明确提到Left连接表最多不应超过3个。令人尴尬的是，在我们的案例中，安全性的安全许可框架在后台被采用。至少应查询和缓存用户，角色和权限以进行权限验证。其次，由于数据权限的原因，也有必要查询用户的部门和职位。基本上不存在表短缺的情况。因此，上述优先添加索引的方法应运而生。但是这里我们提供了一些优化多个索引的方法左加入。
？顾名思义，Left join当然是基于左表作为查询条件，并且具有以下特征:
？
？ 第一点: 左表用作基准，右表用作关联。如果找不到，则返回NULL。例如，左用户？加入？？部门用户有10个数据，部门只有5个数据
然后必须查询10个数据。那么这里的查询费用是多少？最接近用户*部门查询(当然，此前提未编制索引)
笛卡尔成本接近2表。左连接越多，笛卡尔开销越大。
？
？ 第二点: ？ Mysql中Join的查询原理是一种称为嵌套循环联接的算法。该算法基于驱动表作为循环基础，一个接一个地
一个表作为查询。
？
第三点: ALL查询，我们还使用此SQL作为优化示例。在最初的查询计划中，所有关联均采用ALL的形式，即不添加任何内容
在索引的情况下。当然，索引查询计划在添加后会得到优化。
？
我们针对以上三点提出一些优化建议:
？第一点: 无法做到这一点，只能说减少了尽可能多的Left Joins。
？ 第二点: 在业务场景允许的情况下，将小数据表与左表相关联。
？ 第三点: 首先，添加必要的索引。其次，如果出现联接表的查询条件，请将查询条件放入联接中。这一点的原理实际上是基于第二点
查询算法，但我将其放在此处，因为它可以降低查询级别。举个简单的例子吗？…左加入LEFT JOIN fk_menu m
ON m.menu_id = rm.menu_id，如果这里有一个，只需将菜单类型查询为按钮即可。不要在此SQL的末尾添加
m.menu_type =” BUTTON”，但在”左连接”中(从fk_menu中选择？*？从哪里来？mene_type =” BUTTON”？)上？…..
？
？好的，最好发布预先编译的最有效的方法。使用临时表或视图或存储过程来存储SQL时，可以直接调用该代码。
？视图的本质是一个临时表，
？更令人感动的是，表数据的更新不会导致视图的更新。例如，我将用户名更改为Admin123。查看查询UserName = Adm
In123不是吗？我们需要手动更新:update语句就像更新表行。
？从上面可以看到，我们当然需要手动添加和删除，与添加/删除表相同。
？视图的创建是将当前数据缓存在临时表中，然后查询它。通常，不能修改的数据不适用，因为修改需要更改表，并且更改视图非常麻烦。那么，视图有什么作用？功能是对前一天或前几天的数据进行统计。显然，此示例不适用。
？存储过程的SQL更复杂，因此我不在这里上传。实际上，在这种情况下不适用。 Mysql视图是一个临时表。它将查询结果放入其中。当查询表更改时，视图临时表数据将不会更改。 Mysql存储过程是预先将SQL语句编译为可执行的机器语言，并且仅用于查询数据。
？