项目中大量使用 OceanBase 存储过程做逻辑封装，但担心复杂逻辑影响性能与排查效率。
请教几个问题：
- OB 存储过程哪些写法会显著影响性能？
- 调试、日志、异常捕获怎么规范更利于维护？
- 存储过程 vs 应用层逻辑，在 OB 里该如何取舍？
2 个赞
根据提供的文档片段，OceanBase 集群扩容与缩容的关键注意点包括：
- 确保集群处于
running状态。 - 确保剩余节点有足够的资源（特别是磁盘空间）来支撑迁移过来的数据和服务。
- 缩容时需要确认减少 Zone 后仍能满足多数派原则，即 N 个 Zone 的集群缩容后 Zone 个数需要大于等于 N/2 个 Zone。
- 在进行横向缩容之前，需要先进行租户副本的缩容，确保要减少的 Zone 上已无租户副本。
- 通过修改原部署时的配置文件来进行扩容或缩容操作，确保配置正确。
关于存储过程的性能及维护：
- 避免复杂的存储过程，尤其是包含大量嵌套查询、循环和递归的逻辑。
- 遵循 SQL 编写限制和最佳实践，确保 SQL 语句高效。
- 尽量减少在存储过程中进行大量的数据传输。
- 推荐在以下情况使用异常处理程序：预计可能出现异常并期望处理它；必须放弃或关闭资源；在子程序代码的顶层记录错误日志。
- 使用自治事务记录日志，确保在异常发生时能够记录详细信息。
- 使用
DBMS_OUTPUT.PUT_LINE输出调试信息，帮助定位问题。
存储过程 vs 应用层逻辑：
- 存储过程在数据库层执行，可以减少网络传输，提高性能。但在复杂逻辑处理上，应用层可能更具优势。
- 存储过程的维护成本较高，尤其是在团队协作中。应用层逻辑更易于版本控制和团队协作。
- 存储过程可以更好地保护数据库的安全性，防止 SQL 注入等攻击。
检索到的文档如下:
1 个赞
OB 存储过程中显著影响性能的写法 
- 过度使用动态 SQL：频繁拼接字符串生成 SQL 并执行，会导致大量重复解析和编译，无法利用执行计划缓存，显著增加 CPU 开销。
- 大事务与长锁持有：在存储过程中执行大量 DML 操作且不及时提交，会导致锁持有时间过长，阻塞其他事务，引发性能瓶颈。
- 嵌套过深的循环与递归：在 PL 块中编写多层嵌套循环，或使用递归调用，会消耗大量 CPU 资源，且难以优化。
-
未优化的批量操作：使用单条
INSERT/UPDATE代替批量操作，或在循环中逐行处理数据，会产生大量网络交互和事务日志，严重影响吞吐。 -
频繁调用系统函数或自定义函数：在循环中反复调用
DBMS_OUTPUT、SYSDATE等函数，或执行自定义函数，会产生不必要的开销。 -
缺乏索引或查询条件不当：存储过程内的 SQL 语句如果缺少合适索引，或使用
LIKE '%xxx'、OR等导致全表扫描的写法，会直接拖慢整个过程。
文中提到的SQL问题很常见，通过优化OceanBase和调整Zone配置，通常可以解决。
每日学习一点点