根本原因是order模式强制跨节点同步，哪怕cache设得再大，只要没加noorder，每次号段耗尽时仍要走dfs锁协调各实例的nextval分配；必须用noorder+合理cache（50–500）组合，放弃全局有序以消除协调开销，否则cache形同虚设。
为什么RAC中Sequence会引发实例争用
根本原因是ORDER模式强制跨节点同步，哪怕CACHE设得再大，只要没加NOORDER，每次号段耗尽时仍要走DFS锁协调各实例的NEXTVAL分配。比如CACHE 100下，实例A用完1–100后取101，就得向实例B确认“你没用过101”，这个确认过程走的是高开销全局队列（如SVS），不是本地内存读取。
现象上表现为：enq: SQ - contention等待飙升、v$enqueue_stat里SQ类等待频繁、应用侧SELECT seq_name.NEXTVAL FROM DUAL响应毛刺明显——这不是SQL写得差，是序列参数没对齐RAC运行模型。
必须用NOORDER + 合理CACHE组合
NOORDER是RAC下解锁性能的关键开关，它放弃跨实例严格递增，允许每个实例独立维护自己的号段缓存，彻底消除ORDER引发的全局协调开销。不加NOORDER的CACHE，在RAC中实际是“伪缓存”。
-
CACHE值不是越大越好：设CACHE 10000+ORDER反而放大单点压力，一个实例独占1万号段，其他实例干等 - 推荐范围是
50–500：例如每秒200次NEXTVAL调用、每批插入50条，CACHE 200可支撑1秒内无跨节点协调 - 避免设成100的整数倍（如200、500）：减少“号段集体耗尽”导致的争用峰值
怎么查出拖后腿的Sequence
别靠猜，直接查GV$_SEQUENCES（RAC专用视图）：
SELECT SEQUENCE_OWNER, SEQUENCE_NAME, CACHE_SIZE, ORDER_FLAG FROM GV$_SEQUENCES WHERE CACHE_SIZE <p>重点关注<code>CACHE_SIZE 且<code>ORDER_FLAG = 'Y'</code>的序列。如果发现<code>SYS.AUDSESS</code>或<code>SYS.AUDSED$</code>也在列表里，说明登录风暴正在发生——这两个系统序列默认<code>CACHE 20</code>，高并发短连接极易中招。</code></p><p>注意：<code>P2</code>值就是Sequence的<code>OBJECT_ID</code>，结合<code>DBA_OBJECTS</code>能准确定位到具体对象；但更关键的是顺藤摸瓜找到调用它的SQL或PL/SQL，比如<code>p_pub_user_online_curd</code>这类高频存储过程。</p><h3>改序列参数的实操要点</h3><p>必须一步到位，不能只改<code>CACHE</code>留着<code>ORDER</code>——那等于没改：</p>
- 语法必须是
ALTER SEQUENCE seq_name CACHE N NOORDER，NOORDER不能省 - 建议从
CACHE 1000起步；若序列每秒被调用超50次，可试CACHE 5000 - 修改后无需重启实例，但旧会话里已缓存的号段仍按原
CACHE生效，新会话立即生效 - 不要直接
ALTER已有序列来加NOORDER：ORDER/NOORDER属性不可后期变更，必须重建
真正容易被忽略的是业务语义——如果应用依赖全局严格递增（如审计流水号排序），NOORDER就不能用，只能退回到CACHE + ORDER并接受性能折损，或者改用应用层ID生成方案。
