高斯数据库开发使用备忘

发表于 更新于 分类于

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

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

  1. 高斯目前使用的 AStore 存储引擎，有10分钟的自动调度扫描，当碰到业务逻辑执行时，会退让不执行。
  2. 高斯目前主推的 AStore，在生产环境验证下，死元组/活动元组需要特别重视，量大情况下，会严重影响性能。
  3. 高斯目前对 Oracle 语句的接受兼容度确实较高，基本不需要大改语句。但性能退化严重。比如 start with 语法在 Oracle 是秒级及秒级以内的，而在 GaussDB 下，是小时级别的。
  4. 高斯目前监控较弱，需要项目组额外监控。
  5. 高斯目前备份较弱，无法满足生产实际需要，当前备份一次的时间完全不可接受。
  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冲突 )