高斯数据库开发使用备忘

发表于 更新于 分类于

日常开发中碰到的问题，备忘

部分影响性能
部分影响稳定性
部分影响使用

  1. 高斯目前使用的 AStore 存储引擎，有10分钟的自动调度扫描，当碰到业务逻辑执行时，会退让不执行。
  2. 高斯目前主推的 AStore，在生产环境验证下，死元组/活动元组需要特别重视，量大情况下，会严重影响性能。
  3. 高斯目前对 Oracle 语句的接受兼容度确实较高，基本不需要大改语句。但性能退化严重。比如 start with 语法在 Oracle 是秒级及秒级以内的，而在 GaussDB 下，是小时级别的。
  4. 高斯目前监控较弱，需要项目组额外监控。
  5. 高斯目前备份较弱，无法满足生产实际需要，当前备份一次的时间完全不可接受。实测速度符合厂商提供的数据，单进程 30MB/s。
  6. 高斯承袭 PostgreSQL，纯 JDBC 模式下，若不开启 autoCommit=false，ResultSet 数据将一次性下发，容易触发 OOM。必须主动设置 autoCommit=false，这样才是传统理解的游标模式。为性能考虑，建议设置合理的 fetchSize，达到更好性能。
  7. 高斯的 SQL 中，若存在某些特定的 where ... in ...，有概率触发主从切换。
  8. 高斯的 SQL 中，若存在某些特定的 group by，有概率触发主从切换。
  9. 高斯的 C++ 库，存在计算精度问题，需要注意。
  10. 高斯的 SQL 中，若存在 count，一般而言会非常慢。慎用。这一点对 MySQL 系也适用。
  11. 高斯在 AStore 存储引擎下，执行计划中若显示 seq scan，需要小心。顺序扫描等价于其他数据库的全表扫描。
  12. 高斯的 SQL 中，若存在数据类型不一致的比对或 join，将极大影响执行速度。同时，高斯内部的隐式类型转换，也会极大影响执行速度，比如导致索引失效。建议对齐类型。
  13. 高斯承袭 PostgreSQL，两会话一个 truncate 一个 select，将有概率互锁。(见 PostgreSQL系(GaussDB、KingBase…) 在 SELECT 和 TRUNCATE之间lock冲突 )
  14. 高斯存在因执行计划走错导致的SQL劣化，与openGauss社区确认，相较于Oracle，目前openGauss不支持包含distinct/union的子查询连接谓词推入，会导致查询效率低。( gitee issue / gitcode issue )
  15. 高斯针对 int 类型不再支持 null, 改造时针对 number 型会默认赋值 0, 导致原根据 number 型是否 "is null" 的逻辑判断不正确。
  16. 高斯对存储过程中的自定义类型不支持跨会话调用，即存储过程内定义的类型，无法在另一个会话中调用。受限于 iBATIS/MyBatis 的实现，某些场合下需要通过双会话获得存储过程的返回。这时需考虑到高斯对存储过程返回值类型的限制。
  17. 高斯在不正确编写SQL情况下结果集不稳定 GaussDB(DWS)结果集不稳定常见场景和解决办法
  18. 高斯在vacuum full 与delete select语句之间可能造成死锁（等同一对象的不同锁） 『 TechTalk 』GaussDB(DWS)锁问题全解 | 打卡Last Day！完美收官