B树是一种数据结构它按排序顺序在其节点中存储数据，B树存储数据使得每个节点按升序包含密钥，这些键中的每一个都有两个对另外两个子节点的引用，Te左侧子节点键小于当前键右侧子节点键多于当前键，如果单个节点具有n个键则它可以具有最大n+1个子节点。
为什么索引在数据库中使用？想象一下您需要在文件中存储数字列表并搜索该列表上的给定数字，最简单的解决方案是将数据存储在数组中并在新值到来时附加值，但是如果需要检查数组中是否存在给定值则需要逐个搜索所有数组元素并检查给定值是否存在，如果你足够幸运你可以在第一个元素中找到给定的值，在最坏的情况下该值可以是数组中的最后一个元素，我们可以将这种最坏的情况表示为渐进符号中的O（n），这意味着如果您的数组大小最多为n则需要执行n次搜索才能在数组中查找给定值。
你怎么能改善这个时间？最简单的解决方案是对数组进行排序并使用二进制搜索来查找值，每当您向数组中插入一个值时它应该保持顺序，通过从数组中间选择一个值来搜索然后将所选值与搜索值进行比较，如果所选值大于搜索值则忽略数组的左侧并搜索右侧的值反之亦然。
如何在数据库中使用索引？当B-tree进入数据库索引时这个数据结构变得有点复杂，不仅有一个键还有一个与键相关的值，该值是对实际数据记录的引用，密钥和值一起称为有效负载。
结论数据库应该有一种有效的方式来存储读取和修改数据，B树提供了插入和读取数据的有效方法，在实际的数据库实现中数据库同时使用B树和B+树来存储数据，用于索引的B树和用于存储实际记录的B+树，除了二进制搜索之外B+树还提供顺序搜索功能，这使数据库能够更好地控制数据库中的非索引值。
数据库调优集训课为了让大家更快的了解和熟悉数据库调优，给大家推荐一门高级架构师Zilor的在线直播课程~Zilor老师拥有12年软件开发经验，7年大型互联网架构经验。扫码进集训学习群7月14日~16日，Zilor老师将带领大家复盘数据库调优的经典场景，从原理到实战，干货满满，让大家快速掌握数据库调优的技巧。集训课课程目录听课送福利预览时标签不可点收录于话题#个上一篇下一篇文字：独木
图片：独木
排版：独木
图图的基本概念
无向图有向图
简单图多重图
完全图
子图
连通与强连通
生成树、生成森林
路径
图的基本概念图G由顶点集V和边集E组成，记为G=(V,E)，其中V(G)表示图G中顶点的有限非空集;E(G)表示图G中顶点之间的关系(边）集合线性表，树都可以为空，但图不能为空
V
表示图G中顶点的个数，也称图G的阶;
E
表示图G中边的条数
无向图有向图简单图多重图完全图子图设有两个图G=(VE)和G’=(v，E’)，若V是V的子集，且E’是E的子集，则称G’为G的子图，且若V(G)=V(G’)则称G’为G的生成子图生成子图
无向图有向图连通与强连通连通图与强连通图
连通分量与强连通分量
生成树、生成森林n个顶点图的生成树有n-1条边
顶点的度以该顶点为一个端点的边的数目网每个边都有权值有向树一个顶点的入度为0、其余顶点的入度均为1的有向图
路径图中顶点v到顶点w的顶点序列，序列中顶点不重复的路径称为简单路径。路径长度路径上边的数目，若该路径最短则称其为距离。回路―第一个顶点和最后一个顶点相同的路径
End
1
发现更多精彩
权限管理系统的应用者应该有三种不同性质上的使用，
A,使用权限
B,分配权限
C,授权权限
本文只从《使用权限》和《分配权限》这两种应用层面分析，暂时不考虑《授权权限》这种。
二，初步分析用户和角色说到权限管理，首先应该想到，当然要设计一个用户表，一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐，如果公司里面所有员工都有这样的权限呢，每一个人都要配置？那是一件很痛苦的事情。因此再添加一个角色表，把某些人归为一类，然后再把权限分配给角色。角色属下的用户也就拥有了权限。
用户、角色之间的关系是一个用户可以对应多个角色，一个角色可以对应多个用户。多对多关系。
所以需要一个中间表，相信大家都很熟悉，自然不会有疑问。
应用场景有了用户和角色以后，就需要设计应用场景，比如一个应用程序有几大模块（系统模块、项目管理模块、销售模块），
类似这样的模块就是一种应用场景，常见的还有菜单、操作等等。
假设现在我们设计好了，应用场景包括模块、菜单、和操作，那么应该有以下六种关系
一个用户可以对应多个模块，一个模块可以对应多个用户。多对多关系。
一个用户可以对应多个菜单，一个菜单可以对应多个用户。多对多关系。
一个用户可以对应多个操作，一个操作可以对应多个用户。多对多关系。
一个角色可以对应多个模块，一个模块可以对应多个角色。多对多关系。
一个角色可以对应多个菜单，一个菜单可以对应多个角色。多对多关系。
一个角色可以对应多个操作，一个操作可以对应多个角色。多对多关系。
于是建立六张表来维护这六种关系。
这样设计看起来没什么问题。是的，如果没有加入新的关系的话，这样是已经可以满足大部分的需求了。可是如果就是如果，新的关系（需求）往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。
可以看出，这样的设计有几个问题：
数据表设计太复杂
应对系统方案过于固定
三，把问题简单化不同的应用场合，你可能会想出不同的需求，提了一个新的需求以后，可能会发现原来的设计没方法实现了，于是还要添加一个新的表。这也是上面所提到的问题。
其实不必想得那么复杂，权限可以简单描述为：
某某主体在某某领域有某某权限
1，主体可以是用户，可以是角色，也可以是一个部门
2，领域可以是一个模块，可以是一个页面，也可以是页面上的按钮
3，权限可以是“可见”，可以是“只读”，也可以是“可用”(如按钮可以点击)
其实就是Who、What、How的问题
因此上面所提到的六张表其实可以设计一张表：
四，实例说明下面用一个例子做设计说明。“用户、角色在页面上的是使用权限”
详细设计：
1，把菜单的配置放在数据库上，每一个菜单对于一个唯一的编码MenuNo，每一个“叶节点”的菜单项对于一个页面(url)。
2，把按钮的配置放在数据库上，并归属于一个菜单项上（其实就是挂在某一个页面上）。应该一个页面可能会有几个按钮组，比如说有两个列表，这两个列表都需要有“增加、修改、删除”。所以需要增加一个按钮分组的字段来区分。
3,把菜单权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Menu",PrivilegeAccessValue为MenuNo,PrivilegeOperation为"enabled"
4,把按钮权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Button",PrivilegeAccessValue为BtnID,PrivilegeOperation为"enabled"
5,如果需要禁止单个用户的权限，PrivilegeOperation设置为"disabled"。
如果不清楚的可以看下图：
数据库设计：
四，结语说了这么多，其实我推荐的只是Privilege的表设计。这个表是who、what、how问题原型的设计。不仅扩展性、灵活性都很好，而且将复杂的权限管理系统浓缩成一句话。
而PrivilegeOperation不仅仅只是使用和禁止两种，包括分配权限、授权权限，都可以用这个字段定义。只是这无疑加大了应用程序的设计难度，但是对于表设计可以不做出任何的修改就可以完成，可以看出其灵活性。
预览时标签不可点收录于话题#个上一篇下一篇