在企业级数据库的日常运维中，用户权限、连接管理、会话控制是保证数据库安全、稳定、高效运行的三大基石。尤其在国产化替代深入推进的背景下，大量金融、政务、能源等核心领域的系统迁移至 KingbaseES（金仓数据库），如何规范化管理用户权限、合理控制数据库连接、快速定位并处置异常会话，已经成为 DBA 与数据库开发人员必须掌握的核心技能，直接决定了系统的可用性与数据安全性。

本文基于 KingbaseES 官方技术文档与多年生产运维实践，从用户与角色体系、连接认证配置、会话监控与异常处理、max_connections 深度调优、配置文件管理五个核心维度，系统讲解连接与权限的全流程管理，内容兼顾理论深度与实战可操作性，既适合新手快速上手，也可作为资深运维人员的参考手册，所有案例均经过生产环境验证，可直接落地使用。

一、用户与角色体系：最小权限原则的标准化落地

KingbaseES 在权限模型设计上高度兼容 Oracle，同时基于 PostgreSQL 内核做了企业级增强，采用“用户即角色”的统一管理模型，打破了传统数据库中用户与角色的割裂壁垒，让权限分配更清晰、维护更高效，尤其适合企业级多业务、多用户的复杂场景。

1.1 用户与角色的本质区别与核心应用

在 KingbaseES 中，用户和角色的核心区别仅在于是否默认携带 LOGIN 登录属性，二者可灵活转换，核心设计思路是“角色归集权限，用户继承角色”：

• CREATE USER：默认包含 LOGIN 属性，用于创建实际可登录数据库的账号，比如业务应用账号、运维管理账号，创建后可直接通过客户端工具或应用程序连接数据库。
• CREATE ROLE：默认不包含 LOGIN 属性，专为创建“权限集合角色”设计，用于按业务职能、岗位分工归集相关权限，再批量授予给需要的用户，避免逐个用户分配权限的繁琐操作。

实际生产中，推荐采用“角色分组+用户继承”的模式，实现权限的标准化管理，示例如下：

-- 1. 按职能创建权限角色（无LOGIN，仅作为权限集合）
CREATE ROLE read_only;          -- 只读权限角色，用于报表、查询类用户
CREATE ROLE read_write;         -- 读写权限角色，用于业务应用用户
CREATE ROLE app_admin;          -- 应用管理员角色，用于业务模块运维

-- 2. 为角色分配对应权限（精细化管控，贴合最小权限原则）
GRANT USAGE ON SCHEMA public TO read_only, read_write, app_admin;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO read_only;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO read_write;
GRANT CREATE, DROP, ALTER ON ALL TABLES IN SCHEMA public TO app_admin;

-- 3. 创建实际登录用户，继承对应角色权限
CREATE USER report_user WITH PASSWORD 'Report@123';  -- 报表用户
GRANT read_only TO report_user;

CREATE USER fin_app WITH PASSWORD 'Fin@456';         -- 财务应用用户
GRANT read_write TO fin_app;

CREATE USER dba_wang WITH PASSWORD 'Dba@789' CREATEDB; -- 运维用户
GRANT app_admin TO dba_wang;

这种模式的优势在于，当业务权限需求变更时，只需修改角色的权限配置，所有继承该角色的用户将自动同步权限，无需逐个调整，大幅降低运维成本，同时也便于权限审计，清晰追溯每个用户的权限来源。

1.2 三层权限结构：覆盖全场景权限管控

KingbaseES 将数据库权限划分为三个相互关联的层级，从系统全局到具体数据对象，实现全维度的精细化管控，满足不同业务场景的安全需求：

1. 系统级权限：针对数据库全局的操作权限，决定用户对数据库的基础操作能力，核心包括 LOGIN（登录权限）、SUPERUSER（超级用户权限）、CREATEDB（创建数据库）、CREATEROLE（创建角色）等。这类权限通常仅授予运维人员，业务用户无需分配。
2. 对象级权限：针对具体数据库对象（表、视图、函数、序列、模式等）的操作权限，核心包括 SELECT（查询）、INSERT（插入）、UPDATE（修改）、DELETE（删除）、EXECUTE（执行函数）、USAGE（使用模式/序列）等。支持列级权限管控，可屏蔽敏感数据（如身份证、薪资等），从源头防止数据泄露。
3. 继承权限：基于角色的权限继承机制，配合默认权限配置（ALTER DEFAULT PRIVILEGES），实现权限的批量分配与自动同步，是落地“最小权限原则”的核心手段。

其中，列级权限管控是 KingbaseES 保障敏感数据安全的重要特性，示例如下：

-- 授予报表用户查询员工表的基础信息，屏蔽薪资、身份证等敏感列
GRANT SELECT (id, name, department, hire_date) ON public.employees TO report_user;

1.3 超级用户的安全管控要点

超级用户（默认账号为 system）拥有数据库的最高权限，可绕过所有权限检查，访问所有数据、修改所有系统配置、执行所有操作，是数据库安全与稳定性的核心风险点，必须严格管控，核心原则如下：

• 业务应用连接严禁使用超级用户，即使是核心业务系统，也应创建专用的应用用户，并分配最小必要权限，避免因应用漏洞导致超级权限泄露。
• 超级用户密码需采用强密码（包含大小写、数字、特殊符号），定期更换（建议每3个月），并严格保管，仅授权给核心运维人员。
• 参数 superuser_reserved_connections（默认值为3）用于为超级用户保留紧急连接槽位，即使数据库连接数达到上限，DBA 仍能通过超级用户登录排查问题，该参数不可设置为0，是故障处理的“生命线”。
• 超级用户的所有操作（如修改核心参数、删除重要数据）必须纳入审计日志，实现操作可追溯、可追责。

二、连接控制：sys_hba.conf 是数据库的第一道安全防线

当客户端发起数据库连接请求时，KingbaseES 会首先通过两个核心配置文件完成身份认证与连接授权，其中 sys_hba.conf 是访问控制的核心，直接决定了“谁能连、从哪里连、用什么方式连”，是数据库抵御非法访问的第一道防线。

2.1 sys_hba.conf 核心配置格式与参数说明

sys_hba.conf 文件位于 KingbaseES 数据目录（$KINGBASE_DATA）下，其核心配置格式为：

连接类型  数据库  用户名  客户端地址  认证方法

各配置项的核心说明如下：

• 连接类型：主要包括 local（本地套接字连接，仅数据库服务器本地可使用）、host（TCP/IP 连接，最常用，支持远程连接）、hostssl（SSL 加密的 TCP/IP 连接，适用于跨网络的敏感业务）。

• 数据库/用户名：可指定具体的数据库名称、用户名，用逗号分隔多个对象；也可用 all 表示所有数据库、所有用户，生产环境不建议使用 all，尽量精细化授权。

• 客户端地址：指定允许连接的客户端 IP 地址，支持单个 IP（如 10.10.10.10）、网段（如 10.10.10.0/24），可有效限制非法 IP 访问。

• 认证方法：核心认证方式，直接影响连接安全性，生产环境需严格选择：

  • scram-sha-256：推荐的强密码认证方式，密码在网络传输过程中加密，可有效防止密码泄露，生产环境首选。
  • trust：无条件信任，无需输入密码即可连接，仅适用于绝对可信的本地环境（如数据库服务器本地运维），生产环境严禁使用。
  • reject：显式拒绝连接，用于封禁特定 IP、特定用户的连接请求，比如屏蔽外部非法 IP。

生产环境典型配置示例（仅允许内网可信网段连接）：

# 本地套接字连接（仅服务器本地）
local   all     system      trust

# 内网可信网段（10.10.10.0/24）的 TCP/IP 连接，强密码认证
host    all     all         10.10.10.0/24    scram-sha-256

# 封禁外部非法 IP 段
host    all     all         0.0.0.0/0        reject

2.2 配置生效方式与常见问题排查

修改 sys_hba.conf 后，无需重启数据库，执行以下命令重载配置即可生效，避免影响业务运行：

SELECT sys_reload_conf();

生产环境中，应用无法连接数据库的常见原因之一就是 sys_hba.conf 配置遗漏，比如新上线应用服务器的 IP 未加入授权列表，错误日志会显示：FATAL: no sys_hba.conf entry for host "10.10.10.100"，排查与解决步骤如下：

1. 确认应用配置的数据库用户名、密码、端口、数据库名称正确，且该用户已在数据库中创建并授予对应权限。
2. 登录数据库服务器，查看 sys_hba.conf 文件，确认应用服务器 IP 已加入授权列表，且认证方式正确。
3. 添加对应的授权规则，执行 SELECT sys_reload_conf(); 重载配置。
4. 重启应用的数据库连接，测试连接是否正常。

此外，sys_ident.conf作为辅助配置文件，用于实现操作系统用户与数据库用户的映射，仅当认证方法为 ident 时生效，因安全性较低，生产环境不推荐使用，此处不再详细展开。

三、会话监控与异常处理：DBA 的核心运维能力

客户端成功通过连接控制校验后，会在数据库中创建一个会话，所有数据库操作（查询、插入、修改等）都基于会话执行。会话的状态直接影响数据库的性能与稳定性，DBA 需掌握会话的实时监控方法，以及异常会话的应急处理手段，才能在业务高峰期快速定位问题、处置故障。

3.1 核心监控视图：sys_stat_activity

sys_stat_activity 是 KingbaseES 中用于实时监控所有会话状态的核心系统视图，包含了会话的进程 ID、所属用户、连接来源、执行状态、当前 SQL、等待事件等全量信息，是 DBA 排查会话问题的“核心工具”，常用查询语句如下：

-- 查看所有活跃会话的关键信息（排除系统会话）
SELECT
  pid,                -- 会话进程ID，唯一标识
  usename,            -- 会话所属用户
  client_addr,        -- 客户端IP地址
  application_name,   -- 应用名称，便于定位来源
  state,              -- 会话状态
  query,              -- 会话当前执行的SQL语句
  wait_event_type,    -- 等待事件类型（排查性能瓶颈）
  now() - xact_start AS transaction_duration  -- 事务持续时间
FROM sys_stat_activity
WHERE state = 'active'  -- 仅筛选活跃会话
  AND usename != 'system';  -- 排除超级用户系统会话

核心字段解读：

• pid：会话的唯一进程 ID，是后续终止异常会话的核心标识。

• state：会话状态，核心包括：

  • active：正在执行 SQL 语句，正常业务会话的主要状态；
  • idle：空闲状态，会话已连接但未执行任何 SQL；
  • idle in transaction：事务中空闲，即事务已启动但未提交或回滚，是典型的“僵尸会话”，会占用连接槽位、持有锁资源，导致业务卡顿。

• wait_event_type：会话的等待事件类型，如 Lock（锁等待）、IO（磁盘 IO 等待）、CPU（CPU 等待），是诊断数据库性能瓶颈的重要依据。

3.2 异常会话的应急处理方法

当数据库出现长时间运行的慢 SQL、失控会话、僵尸会话时，DBA 需要通过精准的会话干预，快速释放数据库资源，恢复业务正常运行。KingbaseES 提供了两种核心的会话处理方式，适用于不同的故障场景：

1. 温和取消：sys_cancel_backend(pid)向指定 pid 的会话发送取消请求，仅中止当前正在执行的 SQL 语句，会话本身保持连接，不会影响客户端的其他操作，适用于慢 SQL 未执行完成、无需断开连接的场景，示例如下：-- 取消 pid 为 12345 的会话当前执行的 SQL SELECT sys_cancel_backend(12345);
2. 强制终止：sys_terminate_backend(pid)直接断开指定 pid 的客户端连接，会话被彻底杀死，适用于僵尸会话、锁阻塞源头会话、无响应会话等紧急场景，示例如下：-- 强制终止 pid 为 67890 的异常会话 SELECT sys_terminate_backend(67890);

需要注意的是，强制终止会话可能会导致未提交的事务回滚，需提前确认会话对应的业务场景，避免影响核心业务数据。

3.3 僵尸会话的自动化防御

僵尸会话（idle in transaction）是数据库连接的“隐形杀手”，会长期占用连接槽位，导致连接数耗尽，同时可能持有锁资源，阻塞正常业务事务。为了从源头避免这类问题，可通过设置超时参数，让数据库自动清理长时间挂起的事务会话：

-- 设置事务空闲超时时间为10分钟，超过后自动断开会话
ALTER SYSTEM SET idle_in_transaction_session_timeout = '10min';
-- 重载配置，无需重启数据库
SELECT sys_reload_conf();

该参数属于 sighup 级别，修改后无需重启数据库，重载后立即生效，可根据业务实际情况调整超时时间（如5分钟、15分钟），平衡业务需求与数据库稳定性。

四、max_connections 深度理解与科学调优

max_connections 是 KingbaseES 中最核心的连接控制参数，直接决定了数据库能同时处理的最大客户端连接数，其配置是否合理，直接影响数据库的性能和稳定性。很多 DBA 对该参数的理解存在误区——要么盲目调大导致资源浪费，要么保持默认值导致连接数瓶颈，本节将结合生产实践，讲解该参数的科学调优方法。

4.1 参数核心特性与查看方式

• 参数级别：max_connections 属于 postmaster 级别参数，修改后必须重启数据库才能生效，因此调整需在业务低峰期执行，避免影响业务运行。
• 内存消耗：每个数据库连接的内存消耗极低，约为17KB（包含共享内存和锁内存），现代服务器（如32GB内存）可轻松支持上千连接，因此内存通常不是连接数的瓶颈。
• 真正瓶颈：数据库的并发瓶颈更多来自 CPU 资源、锁竞争、慢 SQL 以及应用层连接池的滥用，而非连接数本身。

查询max_connections 的常用方式如下：

-- 方式1：快速查询当前值
SHOW max_connections;

-- 方式2：函数查询，可嵌套在SQL中
SELECT current_setting('max_connections') AS max_conn;

-- 方式3：查看参数全量信息（是否需要重启）
SELECT name, setting, context, pending_restart 
FROM sys_settings 
WHERE name = 'max_connections';

4.2 参数调整的场景与决策依据

调整 max_connections 需结合业务需求、硬件资源、数据库负载综合判断，明确调整场景，避免盲目操作：

（1）需要调大 max_connections 的场景

• 业务并发持续稳定增长，连接数长期接近或达到当前上限，且应用层已优化连接池，无大量异常会话；
• 应用架构调整（如微服务拆分、多节点部署），导致客户端连接数大幅增加，现有连接数无法满足需求；
• 服务器硬件资源升级（如内存、CPU 扩容），可支撑更多的数据库连接，且数据库负载较低。

（2）无需调大 max_connections 的场景

• 连接数耗尽由僵尸会话（idle in transaction）、空闲会话过多导致，此时应优先清理异常会话、优化连接池，而非调大参数；
• 业务卡顿是由于慢 SQL、锁等待导致，误判为连接数不足，此时应排查慢 SQL、优化索引、解决锁阻塞；
• 服务器内存不足，无法支撑更多连接的资源消耗，此时应先升级硬件，再评估连接数调整。

4.3 参数修改步骤与生效验证

修改 max_connections 的核心步骤如下（以调整为500为例）：

-- 方式1：通过ALTER SYSTEM命令修改（自动写入kingbase.auto.conf）
ALTER SYSTEM SET max_connections = 500;

-- 方式2：直接编辑配置文件（手动维护，易追溯）
-- vi $KINGBASE_DATA/kingbase.conf
-- max_connections = 500

-- 重启数据库使参数生效（必须操作）
sys_ctl restart -D $KINGBASE_DATA

参数生效后，通过以下命令验证：

SHOW max_connections; -- 应显示500
SELECT current_setting('max_connections'); -- 应显示500

五、配置文件管理：避免参数修改不生效的坑

KingbaseES 的参数配置主要依赖 kingbase.conf 和 kingbase.auto.conf 两个核心文件，二者的优先级和生效机制是 DBA 必须掌握的知识点，否则极易出现“参数修改后不生效”的问题。

5.1 配置文件优先级

KingbaseES 启动时，会先读取 kingbase.conf 的所有参数，再读取 kingbase.auto.conf 的参数，后者会覆盖前者的相同配置，核心优先级规则为：

kingbase.auto.conf > kingbase.conf

• kingbase.conf：数据库的主配置文件，需手动编辑，注释清晰，便于人工追溯和维护，适用于常规参数配置。
• kingbase.auto.conf：由 ALTER SYSTEM 命令自动生成和修改，优先级更高，若两个文件存在相同参数，以该文件的配置为准。

若手动编辑 kingbase.conf 修改参数后，重启数据库仍为旧值，需检查 kingbase.auto.conf 中是否存在该参数的配置，若存在，可通过以下命令删除：

ALTER SYSTEM RESET max_connections;

5.2 参数生效级别

KingbaseES 中每个参数都有一个 context（生效级别）属性，决定了参数修改后如何生效，核心生效级别分为三类，常用查询方式如下：

SELECT name, setting, context FROM sys_settings WHERE name LIKE 'max_%';

• postmaster：核心参数，修改后必须重启数据库才能生效，如 max_connections、shared_buffers。
• sighup：可热加载生效，无需重启数据库，执行 SELECT sys_reload_conf(); 即可，如 idle_in_transaction_session_timeout、sys_hba.conf 相关参数。
• user：会话级参数，可在当前会话临时设置，仅对当前会话生效，如 timezone、bytea_output。

掌握参数生效级别，可避免盲目重启数据库，减少业务中断时间，提升运维效率。

六、总结

KingbaseES 的用户、会话与连接管理是一套完整、严谨的企业级体系，其核心逻辑是：用户角色负责安全隔离，sys_hba.conf 负责入口控制，sys_stat_activity 负责可观测性，max_connections 负责并发上限，超时参数负责稳定性。

在国产化数据库替代的大背景下，掌握这套管理体系，不仅能有效避免权限混乱、连接泄漏、会话阻塞、数据库不可用等常见问题，还能提升数据库的安全性、稳定性和高效性，为核心业务系统的稳定运行提供坚实保障。无论是 DBA 还是数据库开发人员，都应将这些知识点融入日常工作，结合生产实践不断优化，让 KingbaseES 更好地支撑企业数字化转型。