doc: refactor docs

docs/zh/07-operation/04-monitor.md

@@ -0,0 +1,99 @@
+---
+sidebar_label: 可视化管理
+title: 可视化管理工具
+toc_max_heading_level: 4
+---
+
+## 集群运行监控
+
+为了确保集群稳定运行，TDengine 集成了多种监控指标收集机制，并通 过taosKeeper 进行汇总。taosKeeper负责接收这些数据，并将其写入一个独立的 TDengine 实例中，该实例可以与被监控的 TDengine 集群保持独立。
+
+用户可以使用第三方的监测工具比如 Zabbix 来获取这些保存的系统监测数据，进而将 TDengine 的运行状况无缝集成到现有的 IT 监控系统中。此外，TDengine 还提供了 TDinsight 插件，用户可以通过 Grafana 平台直观地展示和管理这些监控信息，如下图所示。这为用户提供了灵活的监控选项，以满足不同场景下的运维需求。
+
+~[通过监控组件管理监控信息](./grafana.png)
+
+### taosKeeper 的安装与配置
+
+taosKeeper 的配置文件默认位于 `/etc/taos/taoskeeper.toml`。 下面为一个示例配置文件，更多详细信息见参考手册。
+
+```toml
+# gin 框架是否启用 debug
+debug = false
+
+# 服务监听端口, 默认为 6043
+port = 6043
+
+# 日志级别，包含 panic、error、info、debug、trace等
+loglevel = "info"
+
+# 程序中使用协程池的大小
+gopoolsize = 50000
+
+# 查询 TDengine 监控数据轮询间隔
+RotationInterval = "15s"
+
+[tdengine]
+host = "127.0.0.1"
+port = 6041
+username = "root"
+password = "taosdata"
+
+# 需要被监控的 taosAdapter
+[taosAdapter]
+address = ["127.0.0.1:6041"]
+
+[metrics]
+# 监控指标前缀
+prefix = "taos"
+
+# 集群数据的标识符
+cluster = "production"
+
+# 存放监控数据的数据库
+database = "log"
+
+# 指定需要监控的普通表
+tables = []
+
+# database options for db storing metrics data
+[metrics.databaseoptions]
+cachemodel = "none"
+```
+
+### 基于 TDinsight 的监控
+
+为了简化用户在 TDengine 监控方面的配置工作，TDengine 提供了一个名为 TDinsight 的 Grafana 插件。该插件与 taosKeeper 协同工作，能够实时监控 TDengine 的各项性能指标。
+
+通过集成 Grafana 和 TDengine 数据源插件，TDinsight 能够读取 taosKeeper 收集并存储的监控数据。这使得用户可以在 Grafana 平台上直观地查看 TDengine 集群的状态、节点信息、读写请求以及资源使用情况等关键指标，实现数据的可视化展示。
+
+此外，TDinsight 还具备针对 vnode、dnode 和 mnode 节点的异常状态告警功能，为开发者提供实时的集群运行状态监控，确保 TDengine 集群的稳定性和可靠性。以下是TDinsight 的详细使用说明，以帮助你充分利用这一强大工具。
+
+#### 前置条件
+
+若要顺利使用 TDinsight，应满足如下条件。
+- TDengine 已安装并正常运行。
+- taosAdapter 已经安装并正常运行。
+- taosKeeper 已经安装并正常运行。
+- Grafana 已安装并正常运行，以下介绍以 Grafna 10.4.0 为例。
+
+同时记录以下信息。
+- taosAdapter 的 RESTful 接口地址，如 http://www.example.com:6041。
+- TDengine 集群的认证信息，包括用户名及密码。
+
+#### 导入仪表盘
+
+TDengine 数据源插件已被提交至 Grafana 官网，完成插件的安装和数据源的创建后，可以进行 TDinsight 仪表盘的导入。
+
+在 Grafana 的 Home-Dashboards 页面，点击位于右上角的 New → mport 按钮，即可进入 Dashboard 的导入页面，它支持以下两种导入方式。
+- Dashboard ID：18180。
+- Dashboard URL：https://grafana.com/grafana/dashboards/18180-tdinsight-for-3-x/
+
+填写以上 Dashboard ID 或 Dashboard URL 以后，点击 Load 按钮，按照向导操作，即可完成导入。导入成功后，Dashboards 列表页面会出现 TDinsight for 3.x 仪盘，点击进入后，就可以看到 TDinsight 中已创建的各个指标的面板，如下图所示：
+
+![TDinsight 界面示例](./tdinsight.png)
+
+**注意** 在 TDinsight 界面左上角的 Log from 下拉列表中可以选择 log 数据库。
+
+## 可视化管理
+
+为方便用户更高效地使用和管理 TDengine，TDengine 3.0 版本推出了一个全新的可视化组件—taosExplorer。这个组件旨在帮助用户在不熟悉 SQL 的情况下，也能轻松管理 TDengine 集群。通过 taosExplorer，用户可以轻松查看 TDengine 的运行状态、浏览数据、配置数据源、实现流计算和数据订阅等功能。此外，用户还可以利用taosExplorer 进行数据的备份、复制和同步操作，以及配置用户的各种访问权限。这些功能极大地简化了数据库的使用过程，提高了用户体验。

docs/zh/07-operation/05-backup.md

@@ -0,0 +1,38 @@
+---
+sidebar_label: 备份和恢复
+title: 数据备份和恢复
+toc_max_heading_level: 4
+---
+
+为了防止数据丢失、误删操作，TDengine 提供全面的数据备份、恢复、容错、异地数据实时同步等功能，以保证数据存储的安全。本节简要说明备份和恢复功能。
+
+## 基于 taosdump 进行数据备份恢复
+
+taosdump 是一个开源工具，用于支持从运行中的 TDengine 集群备份数据并将备份的数据恢复到相同或另一个正在运行的 TDengine 集群中。taosdump 可以将数据库作为逻辑数据单元进行备份，也可以对数据库中指定时间段内的数据记录进行备份。在使用taosdump 时，可以指定数据备份的目录路径。如果不指定目录路径，taosdump 将默认将数据备份到当前目录。
+
+以下为 taosdump 执行数据备份的使用示例。
+```shell
+taosdump -h localhost -P 6030 -D dbname -o /file/path
+```
+
+执行上述命令后，taosdump 会连接 localhost:6030 所在的 TDengine 集群，查询数据库 dbname 中的所有数据，并将数据备份到 /f ile/path 下。
+
+在使用 taosdump 时，如果指定的存储路径已经包含数据文件，taosdump 会提示用户并立即退出，以避免数据被覆盖。这意味着同一存储路径只能用于一次备份。如果你看到相关提示，请谨慎操作，以免误操作导致数据丢失。
+
+要将本地指定文件路径中的数据文件恢复到正在运行的 TDengine 集群中，可以通过指定命令行参数和数据文件所在路径来执行 taosdump 命令。以下为 taosdump 执行数据恢复的示例代码。
+```shell
+taosdump -i /file/path -h localhost -P 6030
+```
+
+执行上述命令后，taosdump 会连接 localhost:6030 所在的 TDengine 集群，并将 /file/path 下的数据文件恢复到 TDengine 集群中。
+
+## 基于 TDengine Enterprise 进行数据备份恢复
+
+TDengine Enterprise 提供了一个高效的增量备份功能，具体流程如下。
+
+第 1 步，通过浏览器访问 taosExplorer 服务，访问地址通常为 TDengine 集群所在 IP 地址的端口 6060，如 http://localhost:6060。
+第 2 步，在 taosExplorer 服务页面中的“系统管理 - 备份”页面新增一个数据备份任务，在任务配置信息中填写需要备份的数据库名称和备份存储文件路径，完成创建任务
+后即可启动数据备份。
+第 3 步，在数据备份任务完成后，在相同页面的已创建任务列表中找到创建的数据备份任务，直接执行一键恢复，就能够将数据恢复到 TDengine 中。
+
+与 taosdump 相比，如果对相同的数据在指定存储路径下进行多次备份操作，由于TDengine Enterprise 不仅备份效率高，而且实行的是增量处理，因此每次备份任务都会很快完成。而由于 taosdump 永远是全量备份，因此 TDengine Enterprise 在数据量较大的场景下可以显著减小系统开销，而且更加方便。

docs/zh/07-operation/06-disaster.md

@@ -0,0 +1,29 @@
+---
+sidebar_label: 容错与灾备
+title: 容错与灾备
+toc_max_heading_level: 4
+---
+
+为了防止数据丢失、误删操作，TDengine 提供全面的数据备份、恢复、容错、异地数据实时同步等功能，以保证数据存储的安全。本节简要说明 TDengine 中的容错与灾备。
+
+## 容错
+
+TDengine 支持 WAL 机制，实现数据的容错能力，保证数据的高可用。TDengine 接收到应用程序的请求数据包时，会先将请求的原始数据包写入数据库日志文件，等数据成功写入数据库数据文件后，再删除相应的 WAL。这样保证了 TDengine 能够在断电等因素导致的服务重启时，从数据库日志文件中恢复数据，避免数据丢失。涉及的配置参数有如下两个：
+
+- wal_level ：WAL 级别，1 表示写 WAL，但不执行 fsync ； 2 表示写 WAL，而且执行 fsync。默认值为 1。
+- wal_fsync_period：当 wal_level 设置为 2 时，执行 fsync 的周期；当 wal-level 设置为 0 时，表示每次写入，立即执行 fsync。
+
+如果要 100% 保证数据不丢失，则需要将 wal_level 设置为 2，wal_fsync_period 设置为 0。这时写入速度将会下降。但如果应用程序侧启动的写数据的线程数达到一定的数量（超过 50），那么写入数据的性能也会很不错，只会比 wal_fsync_period 设置为 3000ms 下降 30% 左右。
+
+## 灾备
+
+在异地的两个数据中心中部署两个 TDengine Enterprise 集群，利用其数据复制能力即可实现数据灾备。假定两个集群为集群 A 和集群 B，其中集群 A 为源集群，承担写入请求并提供查询服务。集群 B 可以实时消费集群 A 中新写入的数据，并同步到集群 B。如果发生了灾难，导致集群 A 所在数据中心不可用，可以启用集群 B 作为数据写入和查询的主节点。
+
+以下步骤描述了如何轻松在两个 TDengine Enterprise 集群之间搭建数据灾备体系：
+第 1 步，在集群 A 中创建一个数据库 db1，并向该数据库持续写入数据。
+第 2 步， 通过 Web 浏览器访问集群 A 的 taosExplorer 服务， 访问地址通常 为TDengine 集群所在 IP 地址的端口 6060，如 http://localhost:6060。
+第 3 步，访问 TDengine 集群 B，创建一个与集群 A 中数据库 db1 参数配置相同的数据库 db2。
+第 4 步，通过 Web 浏览器访问集群 B 的 taosExplorer 服务，在 “数据浏览器” 页面找到 db2，在 “查看数据库配置” 选项中可以获取该数据库的 DSN，例如 taos+ws://root:taosdata@clusterB:6041/db2
+第 5 步，在 taosExplorer 服务的“系统管理 - 数据同步”页面新增一个数据同步任务，在任务配置信息中填写需要同步的数据库 db1 和目标数据库 db2 的 DSN，完成创建任务后即可启动数据同步。
+ 6 步，访问集群 B，可以看到集群 B 中的数据库 db2 源源不断写入来自集群 A 数据库 db1 的数据，直至两个集群的数据库数据量基本保持一致。至此，一个简单的基于
+TDengine Enterprise 的数据灾备体系搭建完成。

docs/zh/07-operation/07-multi.md

@@ -0,0 +1,54 @@
+---
+sidebar_label: 多级存储
+title: 多级存储
+toc_max_heading_level: 4
+---
+
+TDengine  特有的多级存储功能，其作用是将较近的热度较高的数据存储在高速介质上，而时间久远热度很低的数据存储在低成本介质上，达成了以下目标：
+- 降低存储成本 -- 将数据分级存储后，海量极冷数据存入廉价存储介质带来显著经济性
+- 提升写入性能 -- 得益于每级存储可支持多个挂载点，WAL 预写日志也支持 0 级的多挂载点并行写入，极大提升写入性能（实际场景测得支持持续写入每秒 3 亿测点以上），在机械硬盘上可获得极高磁盘 IO 吞吐（实测可达 2GB/s）
+- 方便维护 -- 配置好各级存储挂载点后，系统数据迁移等工作，无需人工干预；存储扩容更灵活、方便
+- 对 SQL 透明 -- 无论查询的数据是否跨级，一条 SQL 可返回所有数据，简单高效
+
+## 配置方式
+
+多级存储支持 3 级，每级最多可配置 16 个挂载点。
+
+**Tips** 典型的配置方案有：0 级配置多个挂载点，每个挂载点对应单块 SAS 硬盘；1 级配置多个挂载点，每个挂载点对应单块或多块 SATA 硬盘；2 级可配置 S3 存储或其他廉价网络存储。
+
+TDengine 多级存储配置方式如下（在配置文件/etc/taos/taos.cfg 中）：
+```shell
+dataDir [path] <level> <primary>
+```
+
+- path: 挂载点的文件夹路径。
+- level: 介质存储等级，取值为 0，1，2。 0 级存储最新的数据，1 级存储次新的数据，2 级存储最老的数据，省略默认为 0。 各级存储之间的数据流向：0 级存储 -> 1 级存储 -> 2 级存储。 同一存储等级可挂载多个硬盘，同一存储等级上的数据文件分布在该存储等级的所有硬盘上。 需要说明的是，数据在不同级别的存储介质上的移动，是由系统自动完成的，用户无需干预。
+- primary: 是否为主挂载点，0（否）或 1（是），省略默认为 1。
+在配置中，只允许一个主挂载点的存在（level=0，primary=1），例如采用如下的配置方式：
+```shell
+dataDir /mnt/data1 0 1
+dataDir /mnt/data2 0 0
+dataDir /mnt/data3 1 0
+dataDir /mnt/data4 1 0
+dataDir /mnt/data5 2 0
+dataDir /mnt/data6 2 0
+```
+
+**注意** 1. 多级存储不允许跨级配置，合法的配置方案有：仅 0 级，仅 0 级+ 1 级，以及 0 级+ 1 级+ 2 级。而不允许只配置 level=0 和 level=2，而不配置 level=1。
+2. 禁止手动移除使用中的挂载盘，挂载盘目前不支持非本地的网络盘。
+
+## 负载均衡
+
+在多级存储中，有且只有一个主挂载点，主挂载点承担了系统中最重要的元数据存储，同时各个 vnode 的主目录均存在于当前 dnode 主挂载点上，从而导致该 dnode 的写入性能受限于单个磁盘的 IO 吞吐能力。
+
+从 TDengine 3.1.0.0 开始，如果一个 dnode 配置了多个 0 级挂载点，我们将该 dnode 上所有 vnode 的主目录均衡分布在所有的 0 级挂载点上，由这些 0 级挂载点共同承担写入负荷。
+
+在网络 I/O 及其它处理资源不成为瓶颈的情况下，通过优化集群配置，测试结果证明整个系统的写入能力和 0 级挂载点的数量呈现线性关系，即随着 0 级挂载点数量的增加，整个系统的写入能力也成倍增加。
+
+## 同级挂载点选择策略
+
+一般情况下，当 TDengine 要从同级挂载点中选择一个用于生成新的数据文件时，采用 round robin 策略进行选择。但现实中有可能每个磁盘的容量不相同，或者容量相同但写入的数据量不相同，这就导致会出现每个磁盘上的可用空间不均衡，在实际进行选择时有可能会选择到一个剩余空间已经很小的磁盘。
+
+为了解决这个问题，从 3.1.1.0 开始引入了一个新的配置 minDiskFreeSize，当某块磁盘上的可用空间小于等于这个阈值时，该磁盘将不再被选择用于生成新的数据文件。该配置项的单位为字节，其值应该大于 2GB，即会跳过可用空间小于 2GB 的挂载点。
+
+从 3.3.2.0 版本开始，引入了一个新的配置 disable_create_new_file，用于控制在某个挂载点上禁止生成新文件，其缺省值为 false，即每个挂载点上默认都可以生成新文件。

docs/zh/07-operation/08-user.md

@@ -0,0 +1,66 @@
+---
+sidebar_label: 用户管理
+title: TDengine 用户管理
+toc_max_heading_level: 4
+---
+
+TDengine 默认仅配置了一个 root 用户，该用户拥有最高权限。
+
+## 创建用户
+
+创建用户的操作只能由 root 用户进行，语法如下。
+```sql
+create user user_name pass'password' [sysinfo {1|0}]
+```
+
+相关参数说明如下。
+- user_name：最长为 23 B。
+- password：最长为 128 B，合法字符包括 a~z、A~Z、0~9、!、?、\、$、%、\、^、&、*、( )、_、–、+、=、{、[、}、]、:、;、@、~、#、|、\、<、,、>、.、?、/、，不可以出现单双引号、撇号、反斜杠和空格，且不可以为空。
+- sysinfo ：用户是否可以查看系统信息。1 表示可以查看，0 表示不可以查看。系统信息包括服务端配置信息、服务端各种节点信息，如 dnode、查询节点（qnode）等，以及与存储相关的信息等。默认为可以查看系统信息。
+
+如下 SQL 可以创建密码为 123456 且可以查看系统信息的用户 test。
+
+```sql
+create user test pass '123456' sysinfo 1
+```
+
+## 查看用户
+
+查看系统中的用户信息可使用如下 SQL。
+```sql
+show users;
+```
+
+也可以通过查询系统表 information_schema.ins_users 获取系统中的用户信息，示例如下。
+```sql
+select * from information_schema.ins_users;
+```
+
+## 修改用户信息
+
+修改用户信息的 SQL 如下。
+```sql
+alter user user_name alter_user_clause 
+alter_user_clause: { 
+ pass 'literal' 
+ | enable value 
+ | sysinfo value
+}
+```
+
+相关参数说明如下。
+- pass：修改用户密码。
+- enable：是否启用用户。1 表示启用此用户，0 表示禁用此用户。
+- sysinfo ：用户是否可查看系统信息。1 表示可以查看系统信息，0 表示不可以查看系统信息
+
+如下 SQL 禁用 test 用户。
+```sql
+alter user test enable 0
+```
+
+## 删除用户
+
+删除用户的 SQL 如下。
+```sql
+drop user user_name
+```

docs/zh/07-operation/09-grant.md

@@ -0,0 +1,197 @@
+---
+sidebar_label: 权限管理
+title: 权限管理
+toc_max_heading_level: 4
+---
+
+TDengine 支持对系统资源、库、表、视图和主题的访问权限控制。root 用户可以为每个用户针对不同的资源设置不同的访问权限。
+
+## 资源管理
+
+仅 root 用户可以管理用户、节点、vnode、qnode、snode 等系统信息，包括查询、新增、删除和修改。
+
+## 授权
+
+### 库和表的授权
+
+在 TDengine 中，库和表的权限分为 read （读）和 write （写）两种。这些权限可以单独授予，也可以同时授予用户。
+
+- read 权限：拥有 read 权限的用户仅能查询库或表中的数据，而无法对数据进行修改或删除。这种权限适用于需要访问数据但不需要对数据进行写入操作的场景，如数据分析师、报表生成器等。
+- write 权限：拥有 write 权限的用户既可以查询库或表中的数据，也可以向库或表中写入数据。这种权限适用于需要对数据进行写入操作的场景，如数据采集器、数据处理器等。
+
+对某个用户进行库和表访问授权的语法如下。
+
+```sql
+grant privileges on resources [with tag_filter] to user_name
+privileges: {
+ all,
+ | priv_type [, priv_type] …
+}
+priv_type：{
+ read
+ | write
+}
+resources ：{
+ dbname.tbname
+ | dbname.*
+ | *.*
+}
+```
+
+相关参数说明如下。
+- resources ：可以访问的库或表。. 之前为数据库名称，. 之后为表名称。dbname.tbname 的意思是名为 dbname 的数据库中的 tbname 表必须为普通表或超级表。dbname.* 的意思是名为 dbname 的数据库中的所有表。*.* 的意思是所有数据库中的所有表。
+- tag_f ilter：超级表的过滤条件。
+
+上述 SQL 既可以授权一个库、所有库，也可以授权一个库下的普通表或超级表，还可以通过 dbname.tbname 和 with 子句的组合授权符合过滤条件的一张超级表下的所有子表。
+如下 SQL 将数据库 power 的 read 权限授权给用户 test。
+```sql
+grant read on power to test
+```
+
+如下 SQL 将数据库 power 下超级表 meters 的全部权限授权给用户 test。
+```sql
+grant all on power.meters to test
+```
+
+如下 SQL 将超级表 meters 离标签值 groupId 等于 1 的子表的 write 权限授权给用户test。
+```sql
+grant all on power.meters with groupId=1 to test
+```
+
+如果用户被授予了数据库的写权限，那么用户对这个数据库下的所有表都有读和写的权限。但如果一个数据库只有读的权限或甚至读的权限都没有，表的授权会让用户能读或写部分表，详细的授权组合见参考手册。
+
+### 视图授权
+
+在 TDengine 中，视图（view）的权限分为 read、write 和 alter 3 种。它们决定了用户对视图的访问和操作权限。以下是关于视图权限的具体使用规则。
+- 视图的创建者和 root 用户默认具备所有权限。这意味着视图的创建者和 root 用户可以查询、写入和修改视图。
+- 对其他用户进行授权和回收权限可以通过 grant 和 revoke 语句进行。这些操作只能由 root 用户执行。
+- 视图权限需要单独授权和回收，通过 db.* 进行的授权和回收不包含视图权限。
+- 视图可以嵌套定义和使用，对视图权限的校验也是递归进行的。
+
+为了方便视图的分享和使用，TDengine 引入了视图有效用户（即视图的创建用户）的概念。被授权用户可以使用视图有效用户的库、表及嵌套视图的读写权限。当视图被replace 后，有效用户也会被更新。
+
+视图操作和权限要求的详细对应关系请见参考手册。
+
+视图授权语法如下。
+```sql
+grant privileges on [db_name.]view_name to user_name
+privileges: {
+ all,
+ | priv_type [, priv_type] ...
+}
+priv_type: {
+ read
+ | write
+ alter
+}
+```
+
+在数据库 power 下将视图 view_name 的读权限授权给用户 test，SQL 如下。
+```sql
+grant read on power.view_name to test
+```
+
+在数据库 power 库下将视图 view_name 的全部权限授权给用户 test，SQL 如下。
+```sql
+grant all on power.view_name to test
+```
+
+### 消息订阅授权
+
+消息订阅是 TDengine 独具匠心的设计。为了保障用户订阅信息的安全性，TDengine 可针对消息订阅进行授权。在使用消息订阅授权功能前，用户需要了解它的如下特殊使用规则。
+- 任意用户在拥有读权限的数据库上都可以创建主题。root 用户具有在任意数据库上创建主题的权限。
+- 每个主题的订阅权限可以独立授权给任何用户，无论其是否具备该数据库的访问权限。
+- 删除主题的操作只有 root 用户或该主题的创建者可以执行。
+- 只有超级用户、主题的创建者或被显式授权订阅权限的用户才能订阅主题。这些权限设置既保障了数据库的安全性，又保证了用户在有限范围内的灵活操作。
+
+消息订阅授权的 SQL 语法如下。
+```sql
+grant privileges on priv_level to user_name 
+privileges : { 
+ all 
+ | priv_type [, priv_type] ...
+} 
+priv_type : { 
+ subscribe
+} 
+priv_level : { 
+ topic_name
+}
+```
+
+将名为 topic_name 的主题授权给用户 test，SQL 如下。
+```sql
+grant subscribe on topic_name to test
+```
+
+## 查看授权
+
+当企业拥有多个数据库用户时，使用如下命令可以查询具体一个用户所拥有的所有授权，SQL 如下。
+```sql
+show user privileges
+```
+
+## 撤销授权
+
+由于数据库访问、数据订阅和视图的特性不同，针对具体授权的撤销语法也略有差异。下面列出具体的撤销授权对应不同授权对象的语法。
+撤销数据库访问授权的 SQL 如下。
+```sql
+revoke privileges on priv_level [with tag_condition] from user_name
+privileges : {
+ all
+ | priv_type [, priv_type] ...
+}
+priv_type : {
+ read
+ | write
+}
+priv_level : {
+ dbname.tbname
+ | dbname.*
+ | *.*
+}
+```
+
+撤销视图授权的 SQL 如下。
+```sql
+revoke privileges on [db_name.]view_name from user_name
+privileges: {
+ all,
+ | priv_type [, priv_type] ...
+}
+priv_type: {
+ read
+ | write
+ | alter
+}
+```
+
+撤销数据订阅授权的 SQL 如下。
+```sql
+revoke privileges on priv_level from user_name 
+privileges : {
+    all 
+ | priv_type [, priv_type] ...
+} 
+priv_type : { 
+ subscribe
+} 
+priv_level : { 
+ topic_name
+}
+```
+
+撤销用户 test 对于数据库 power 的所有授权的 SQL 如下。
+```sql
+revoke all on power from test
+```
+
+撤销用户 test 对于数据库 power 的视图 view_name 的读授权的 SQL 如下。
+```sql
+revoke read on power.view_name from test
+```
+
+撤销用户 test 对于消息订阅 topic_name 的 subscribe 授权的 SQL 如下。
+```sql
+revoke subscribe on topic_name from test
+```