TiDB 是 PingCAP 自主研发的开源分布式关系型数据库，具备商业级数据库的数据可靠性，可用性，安全性等特性，支持在线弹性水平扩展，兼容 MySQL 协议及生态，创新性实现 OLTP 及 OLAP 融合。
TiDB 3.0 版本显著提升了大规模集群的稳定性，集群支持 150+ 存储节点，300+TB 存储容量长期稳定运行。易用性方面引入大量降低用户运维成本的优化，包括引入 Information_Schema 中的多个实用系统视图、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特别是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升约 4.5 倍，Sysbench 性能提升约 1.5 倍，OLAP 方面，TPC-H 50G Q15 因实现 View 可以执行，至此 TPC-H 22 个 Query 均可正常运行。新功能方面增加了窗口函数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）。
截止本文发稿时 TiDB 已在 500+ 用户的生产环境中长期稳定运行，涵盖金融、保险、制造，互联网， 游戏 等领域，涉及交易、数据中台、 历史 库等多个业务场景。不同业务场景对关系型数据库的诉求可用 “百花齐放”来形容，但对关系数据库最根本的诉求未发生任何变化，如数据可靠性，系统稳定性，可扩展性，安全性，易用性等。请跟随我们的脚步梳理 TiDB 3.0 有什么样的惊喜。
3.0 与 2.1 版本相比，显著提升了大规模集群的稳定性，支持单集群 150+ 存储节点，300+TB 存储容量长期稳定运行，主要的优化点如下：
1. 优化 Raft 副本之间的心跳机制，按照 Region 的活跃程度调整心跳频率，减小冷数据对集群的负担。
2. 热点调度策略支持更多参数配置，采用更高优先级，并提升热点调度的准确性。
3. 优化 PD 调度流程，提供调度限流机制，提升系统稳定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 时间，提升系统稳定性。
众所周知，数据库查询计划的稳定性对业务至关重要，TiDB 3.0 版本采用多种优化手段提升查询计划的稳定性，如下：
1. 新增 Fast Analyze 功能，提升收集统计信息的速度，降低集群资源的消耗及对业务的影响。
2. 新增 Incremental Analyze 功能，提升收集单调递增的索引统计信息的速度，降低集群资源的消耗及对业务的影响。
3. 在 CM-Sketch 中新增 TopN 的统计信息，缓解 CM-Sketch 哈希冲突导致估算偏大，提升代价估算的准确性，提升查询计划的稳定性。
4. 引入 Skyline Pruning 框架，利用规则防止查询计划过度依赖统计信息，缓解因统计信息滞后导致选择的查询计划不是最优的情况，提升查询计划的稳定性。
5. 新增 SQL Plan Management 功能，支持在查询计划不准确时手动绑定查询计划，提升查询计划的稳定性。
1. OLTP
3.0 与 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升约 1.5 倍，TPC-C 性能提升约 4.5 倍。主要的优化点如下：
1. TiDB 持续优化 SQL 执行器，包括：优化 NOT EXISTS 子查询转化为 Anti Semi Join，优化多表 Join 时 Join 顺序选择等。
2. 优化 Index Join 逻辑，扩大 Index Join 算子的适用场景并提升代价估算的准确性。
3. TiKV 批量接收和发送消息功能，提升写入密集的场景的 TPS 约 7%，读密集的场景提升约 30%。
4. TiKV 优化内存管理，减少 Iterator Key Bound Option 的内存分配和拷贝，多个 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存储引擎插件，提升 Value 值超过 1KB 时性能，缓解 RocksDB 写放大问题，减少磁盘 IO 的占用。
6. TiKV 新增多线程 Raftstore 和 Apply 功能，提升单节点内可扩展性，进而提升单节点内并发处理能力和资源利用率，降低延时，大幅提升集群写入能力。
TiDB Lightning 性能与 2019 年年初相比提升 3 倍，从 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，优化点，如下：
1. 提升 SQL 转化成 KV Pairs 的性能，减少不必要的开销。
2. 提升单表导入性能，单表支持批量导入。
3. 提升 TiKV-Importer 导入数据性能，支持将数据和索引分别导入。
4. TiKV-Importer 支持上传 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的权限访问控制） 是商业系统中最常见的权限管理技术之一，通过 RBAC 思想可以构建最简单“用户-角色-权限”的访问权限控制模型。RBAC 中用户与角色关联，权限与角色关联，角色与权限之间一般是多对多的关系，用户通过成为什么样的角色获取该角色所拥有的权限，达到简化权限管理的目的，通过此版本的迭代 RBAC 功能开发完成。
IP 白名单功能（企业版特性） ：TiDB 提供基于 IP 白名单实现网络安全访问控制，用户可根据实际情况配置相关的访问策略。
Audit log 功能（企业版特性） ：Audit log 记录用户对数据库所执行的操作，通过记录 Audit log 用户可以对数据库进行故障分析，行为分析，安全审计等，帮助用户获取数据执行情况。
加密存储（企业版特性） ：TiDB 利用 RocksDB 自身加密功能，实现加密存储的功能，保证所有写入到磁盘的数据都经过加密，降低数据泄露的风险。
完善权限语句的权限检查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 语句权限检查。
1. 新增 SQL 方式查询慢查询，丰富 TiDB 慢查询日志内容，如：Coprocessor 任务数，平均/最长/90% 执行/等待时间，执行/等待时间最长的 TiKV 地址，简化慢查询定位工作，提高排查慢查询问题效率，提升产品易用性。
2. 新增系统配置项合法性检查，优化系统监控项等，提升产品易用性。
3. 新增对 TableReader、IndexReader 和 IndexLookupReader 算子内存使用情况统计信息，提高 Query 内存使用统计的准确性，提升处理内存消耗较大语句的效率。
4. 制定日志规范，重构日志系统，统一日志格式，方便用户理解日志内容，有助于通过工具对日志进行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 调优的易用性。
6. 新增 SQL 语句 Trace 功能，方便排查问题。
7. 新增通过 unix_socket 方式连接数据库。
8. 新增快速恢复被删除表功能，当误删除数据时可通过此功能快速恢复数据。
TiDB 3.0 新增 TiFlash 组件，解决复杂分析及 HTAP 场景。TiFlash 是列式存储系统，与行存储系统实时同步，具备低延时，高性能，事务一致性读等特性。 通过 Raft 协议从 TiKV 中实时同步行存数据并转化成列存储格式持久化到一组独立的节点，解决行列混合存储以及资源隔离性问题。TiFlash 可用作行存储系统（TiKV）实时镜像，实时镜像可独立于行存储系统，将行存储及列存储从物理隔离开，提供完善的资源隔离方案，HTAP 场景最优推荐方案；亦可用作行存储表的索引，配合行存储对外提供智能的 OLAP 服务，提升约 10 倍复杂的混合查询的性能。
TiFlash 目前处于 Beta 阶段，计划 2019 年 12 月 31 日之前 GA，欢迎大家申请试用。
未来我们会继续投入到系统稳定性，易用性，性能，弹性扩展方面，向用户提供极致的弹性伸缩能力，极致的性能体验，极致的用户体验。
稳定性方面 V4.0 版本将继续完善 V3.0 未 GA 的重大特性，例如：悲观事务模型，View，Table Partition，Titan 行存储引擎，TiFlash 列存储引擎；引入近似物理备份恢复解决分布数据库备份恢复难题；优化 PD 调度功能等。
性能方面 V4.0 版本将继续优化事务处理流程，减少事务资源消耗，提升性能，例如：1PC，省去获取 commit ts 操作等。
弹性扩展方面，PD 将提供弹性扩展所需的元信息供外部系统调用，外部系统可根据元信息及负载情况动态伸缩集群规模，达成节省成本的目标。
我们相信战胜“未知”最好的武器就是社区的力量，基础软件需要坚定地走开源路线。截止发稿我们已经完成 41 篇源码阅读文章。TiDB 开源社区总计 265 位 Contributor，6 位 Committer，在这里我们对社区贡献者表示由衷的感谢，希望更多志同道合的人能加入进来，也希望大家在 TiDB 这个开源社区能够有所收获。
TiDB 3.0 GA Release Notes： https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/
【功能权限】 ：对菜单栏目进行权限控制，查询，增加，删除，修改功能，一般来说这种对资源的权限控制模型可以做到比较统一（用户、角色、资源）。
【数据权限】 ：哪些人能看到哪些数据，例如淘宝本人只能看自己订单，北京地区部门领导可以看到电器类部门订单， 最高领导能看到人所有订单等等。 这种跟业务高度相关，（网络上资料暂时比较少）原理主要是对SQL语句添加where 条件
【字段权限】 ：订单能看到哪些字段，如供应商，看不到内部价、 出厂价等信息。 （网络上资料暂时比较少）实现原理跟数据权限控制是一致的。对SQL语句添加select 条件
这次，我们主要讲解最常用的 功能权限控制 的实现过程，这类WEB权限控制，在任意后端语言上都可以实现Java、Golang、PHP、Nodejs、Python等等，主要理解其数据模型。
这一篇最后介绍下 Casbin是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。并指出主流后端语言，目前Casbin权限控制支持的语言有Go JavaNode.js PHP Python C# Delphi，使用Casbin可以极大提高权限控制开发效率。当然你不用这个库，自己设计表，实现原理是一样。
B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。需求陈述
不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
关于设计
借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。
我们先来分析一下数据库结构：
首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：
由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：
另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：
根据上面的分析，我们进行数据库结构设计，如下图：
点击这里查看权限管理系统数据表字段设计
为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。
一 权限映射表 如下图：
首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。
看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：
如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。
使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。
action字段相关联在数据库中的表现如下图：
通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。
或许你会问，为什么不使用actionid字段相关联呢？因为：
权限表中的id字段在经过多次的数据库操作之后可能会发生更改。
权限映射表中仅仅记录着一个管理组可以执行的权限。
一旦权限表中的id更改，那么权限映射表中的记录也就更改了。
一个管理组可以执行的权限势必将出错，这是非常不希望的。
考虑到上面的情况，所以应该使用action字段相关联，因为：
在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。
权限映射表中记录的action字段也就不会变。
一个管理组可以执行的权限就不会出错了。
二 人员映射表 如下图：
我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：
看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：
如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。
使用这种关联方式，是为了查到一个管理组中的人员有谁。和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。
id字段（人员映射表中是masterid字段）关联表现在数据库中的形式如下图：
一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。所以，在人员映射表中关于administrator的记录就会是两条。
这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。
再结合上面谈到的权限表和权限映射表，就实现了需求中的“组”操作，如下图：
其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。
我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图：
两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：
如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。
现在，数据库结构已经很清晰了，分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。
为什么使用这种数据库设计方式搭建起来的系统可以重用呢？
三张实体表中记录着系统中的三个决定性元素。“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。
两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动结构。
权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏，修改分栏还是减少分栏，也只不过是操作记录而已。
综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。
总结：
此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。
附录：
权限管理系统数据表的字段设计
下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：
action表：
action表中记录着系统中所有的动作，以及动作相关描述。
actioncolumn表：
actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。
actiongroup表：
actiongroup表记录着动作所在的组。
groupmanager表：
groupmanager表记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。
mastergroup表：
mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。
master表：
master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。
