一个建用户动作，暴露了整套机制的裂缝
达梦安全版本里，用 SYSDBA 建用户，下面这条语句直接报错：
报错信息是第 1 行附近出现错误 [-2007]：语法分析出错。密码和默认表空间都不能带，只能先建一个空壳用户，退出，换 SYSSSO 登录，再补上密码和表空间：
SQL> CREATE USER CJC;
操作已执行
SQL> ALTER USER CJC IDENTIFIED BY "****" DEFAULT TABLESPACE CJC;
操作已执行
两条 SQL，两个账号，中间夹一次登录切换。这就是三权分立落到日常运维里的真实样子。
设计逻辑没错，错的是它假设了三个独立的人
SYSDBA 管运行，SYSSSO 管安全策略，SYSAUDITOR 管审计。谁都不能既改数据又删痕迹。四权分立再把对象运维拆给 SYSDBO，粒度更细。
这套机制的推动力来自等保。等保 2.0 三级以上明确要求数据库具备系统管理员、安全管理员、审计员三种权限的独立分配。厂商做这个功能，没毛病。
问题在于，设计时默认了一个前提：有三个独立的人，分别干这三件事。
现实里这个前提经常不成立。
被拆散的远不止建用户
建用户只是起步。日常运维里被三权切碎的操作比比皆是。
备份恢复，严格按职责分离走，SYSDBA 自己做不了主。审计记录 SYSDBA 看不了，得切 SYSAUDITOR。故障排查时想确认某个时间点谁动了什么，先得找审计员。
授权调整更微妙。给业务用户加一张表的查询权限，算安全管理员的事还是 DBA 的事？现实运维里通常还是 SYSDBA 在做，但这已经在职责分离的边界上踩线了。
业界有句话叫“三权分立成了运维的噩梦”。原话可能夸张，但意思传达到了。原本一条语句干完的事，现在要两个人、两次登录、两条语句。链路膨胀的速度，比安全风险的降低幅度快得多。
一个人演三个角色，是常态不是例外
三权分立有个隐含假设：至少三个人，各管一摊，互不汇报、不串通。
大型金融机构、运营商、政务云里或许能实现。但大量中小企业，一个 DBA 同时管着 MySQL、PostgreSQL、Oracle 和达梦，可能还兼着系统运维和开发 DBA 的活。公司不会因为达梦有个三权分立，就多招两个人专门管 SYSSSO 和 SYSAUDITOR。
常见的做法是：一个人手里攥着三个账号的密码。建用户切 SYSDBA，设密码切 SYSSSO，查审计切 SYSAUDITOR。数据库层面看，三个角色各司其职，等保测评账号隔离那项能过。组织层面看，还是同一个人。
这就引出一个尴尬的问题：当一套安全机制的组织前提不存在时，它到底在防谁？
数据库能强制账号隔离，但它验证不了“SYSDBA 的密码和 SYSSSO 的密码不是同一个人在保管”。这是技术手段解决不了的组织问题。数据库也没法强制要求两个账号不能由同一人持有——真那么干了，一大块部署场景直接没法用。
于是形成一种默契：数据库提供三权分立的“形式”，运维人员提供“一个人分饰三角”的“实质”。合规材料上的账号分离是真的，日常运维里的权力集中也是真的。
好处和代价，都摆桌面上
先说好处，不吹不黑。
防内部人作恶是真有用。特别是外包人员流动性大的环境，一个能改数据又能删审计日志的账号，永远是隐患敞口。多一道锁，多一道保险。
等保能过。这是硬指标，没得商量。很多项目上不上三权分立，不取决于技术判断，取决于测评机构那一关。
出事时能追溯。谁在什么时间干了什么，审计记录里有据可查。真出了数据问题，至少能定位到人。
再说代价。
日常运维效率往下掉。改动频繁的时候，切账号切到怀疑人生。凌晨做割接，本来脑子就不清醒，还要记住现在该用哪个账号。
密码管理反而更乱。为了省事写成一样，三权分立直接失效。写成不一样，运维人员就得维护三套密码，交接时新人第一句就问：“这三个账号密码一样吗？”
审计记录的存储和性能开销。全量审计会挤占业务负载，系统本来就跑得紧的时候，额外开销可能直接影响稳定性。一个不可用的数据库，再安全也没价值。
小团队落不了地。人不够，强行上三权，结果就是一个人管三个号。合规表格好看，实际权力集中程度和不启用没本质区别。
交接麻烦。人一走，三个账号的密码如果没交接清楚，系统可能直接卡住。
适用与不适用，得看菜下饭
三权分立和四权分立不是噱头。在对的场景里，它们有真实意义。但“对的场景”比厂商宣传的窄得多。
真正需要三权分立的，是数据敏感度高、操作审计要求严格、且有足够人力预算配独立角色的环境。政务核心系统、金融交易系统、涉及个人敏感信息的基础设施，这些场景里三权分立的成本值得付。
不需要三权分立的，是中小企业的业务库、内部管理系统、数据敏感度不高的应用。强行上三权，结果大概率是“一个人管三个号”，合规材料好看而已。这些场景里，与其在数据库层面做形式化分离，不如把精力放在更实际的地方：最小权限原则严格执行、账号密码妥善管理、关键运维记录留痕、定期权限审计。
四权分立更极端。SYSDBO 进来之后，SYSDBA 连业务表都碰不了，所有数据运维走 SYSDBO。在一个开发、测试、运维本来就不分的小组里，这只会制造更多账号切换。四权真正适用的场景，是开发人员和安全运维人员本身就是两拨人、有明确组织边界的大型系统。不具备这个条件时，强行上四权，就是在三权的形式主义上再加一层。
错位不在运维不规范，在机制假设了不存在的组织
那个建用户的例子之所以值得琢磨，是因为它暴露了一个错位：数据库安全功能的设计者，假设了一个“组织健全、人力充足”的使用环境；一线运维面对的，是一个“人手不够、一人多岗”的现实世界。
这两者之间的差距，不是运维人员“不规范操作”能解释的，是系统性的。
安全的目标不是让合规表格好看，是让真实风险可控。当一套机制把大量精力消耗在链路切换和账号管理上，却没实质增加攻击者攻破系统的难度时，该问的不是“运维为什么不用”，而是这套机制到底在保护谁。
补充一个实操层面的判断依据。验证三权分立是否真正生效，不能只看账号是否存在，要看权限是否真正隔离。可以用 SYSDBA 尝试查询审计视图，如果能查到，说明隔离没做到位。反过来，如果 SYSSSO 能直接修改业务数据，同样说明权限边界形同虚设。这些校验命令比看合规文档更能反映实际状态。
另一个容易被忽略的点：达梦不同版本对三权分立的行为有差异。安全版本默认启用三权分立，普通版本可能没有 SYSSSO 和 SYSAUDITOR 角色。部署前先确认版本类型，别在普通版上照着安全版的文档操作，否则连账号都建不出来。这个坑踩过的人不少。
