PL/SQL无内置位移操作符，左移用value*POWER(2,n)，右移用FLOOR(value/POWER(2,n))；BITAND是唯一原生位函数，BITOR/BITXOR需公式模拟；注意数值类型、NULL及溢出边界。
PL/SQL 里没有内置的左移右移操作符，BITAND 是唯一原生位与函数
oracle 12c 及以前版本的 pl/sql 不支持 << 或 >> 这类 c 风格位移运算符，连 bitor、bitxor 都得靠 bitand 拼出来。所以想做左移右移，必须自己算——本质是乘除 2 的幂次，但得小心整数截断和符号问题。
常见错误现象：BITAND(5, 2) 返回 0（正确），但有人误以为 BITAND(5, 1 << 2) 能直接左移，结果报错：ORA-00907: 缺失右括号 —— 因为 << 根本不是合法 PL/SQL 运算符。
- 所有位移必须转成算术表达式：
value * POWER(2, n)表示左移 n 位，FLOOR(value / POWER(2, n))表示无符号右移 n 位 - 注意
POWER(2, n)在 n ≥ 64 时可能溢出或返回 0（取决于 Oracle 版本和数值类型） - 负数右移要额外处理符号位，PL/SQL 没有算术右移原语，直接除会丢符号；建议先转成无符号等价数（如用
UTL_RAW.CAST_TO_BINARY_INTEGER+ 掩码）再操作
用 BITAND 模拟 BITOR 和 BITXOR 的可靠写法
BITAND 是 Oracle 唯一保证跨版本稳定的位函数，但它只能“取共同位”。想实现或/异或，得靠布尔代数恒等式：比如 a OR b = a + b - BITAND(a, b)，但这个只对非负整数成立，且容易溢出。
使用场景：解析标志位字段（如权限掩码）、协议解析、状态合并。别指望它高性能——每次调用都走 SQL 引擎层，比纯 PL/SQL 算术慢一个数量级。
-
BITOR(a, b)安全写法：a + b - BITAND(a, b)，前提是a和b非负且a + b不超INTEGER范围（通常 ≤ 2^31−1） -
BITXOR(a, b)推荐：BITAND(a + b, UTL_RAW.CAST_TO_BINARY_INTEGER('FFFFFFFF')) - 2 * BITAND(a, b)—— 更稳妥的做法是拆成逐位判断，但太重；简单场景直接用ABS(a - b)仅当两数无重叠位时成立 - 性能影响：每多一层
BITAND嵌套，执行计划里就多一次 SQL 函数调用开销；批量处理时，改用UTL_RAW包批量转换字节更高效
自定义左移右移函数要注意的三个边界条件
你写的 shift_left(v, n) 很可能在某些输入下返回错值，不是逻辑错，而是 Oracle 数值类型隐式转换惹的祸。
常见错误现象：传入 v => 1, n => 31，期望得到 2147483648，结果返回负数（因为默认 PLS_INTEGER 是有符号 32 位）；或者 n 为负数时没校验，直接进 POWER 导致 ORA-01428 错误。
- 输入参数类型必须显式声明为
NUMBER（而非PLS_INTEGER），否则大数自动截断 - 必须检查
n < 0并抛出自定义异常，或自动转为右移逻辑（但语义不一致，不推荐） - 右移时用
FLOOR而非TRUNC：因为-5 / 2 = -2.5，TRUNC(-2.5) = -2（错误），而FLOOR(-2.5) = -3（符合无符号右移补 0 的行为）
真正需要高性能位运算时，别硬扛 PL/SQL
如果你在循环里反复调用自定义位移函数，尤其是处理上万行数据，性能瓶颈几乎一定卡在 PL/SQL → SQL 函数调用切换上。这时候该换思路。
使用场景：ETL 中解析二进制日志、实时风控规则匹配、IoT 设备状态解包。
- 优先把位运算逻辑下沉到 SQL 层，用
BITAND+ 算术表达式写在SELECT里，让 Oracle 优化器统一处理 - 若逻辑复杂，考虑用
UTL_RAW包：比如UTL_RAW.BIT_AND、UTL_RAW.CONVERT处理 RAW 字节，再转回数字，比纯数学运算快 3–5 倍 - 极端情况（如高频交易系统），直接写 Java 存储过程，用
java.lang.Integer.bitCount等原生方法，但运维成本陡增
最易被忽略的一点：BITAND 对 NULL 输入返回 NULL，而你的自定义位移函数如果没显式处理 NULL，下游 NVL 判断就会漏掉——这种 bug 在测试数据全非空时根本发现不了。
