文档介绍：GaussDBT性能调优——常见解决方案
 
   
 
 
 
 
 
 
 
     
 
 
 
 
 
摘要：本文介绍GaussDB T 数据库常见解决方案。
目录
1 分页查询
2 锁并发控制
3 返回大数量级结果集
4 大批量INSERT
1 分页查询
分页查询在数据库应用中非常常见，用的不好很容易出现性能问题，下面讨论几种常见的分页查询场景。分页查询一般是要求排序的，如果可以不排序，性能一般没有问题，下面重点讨论需要排序的情况。
常见分页查询写法有以下两种：
● 第一种
select * from
( select a.*, rownum rn from
( select * from tab1 u where status = 1 order by ) a
where rownum <= 500
) b
where rn >= 1
● 第二种
select * from tab1 u where status = 1 order by limit 500, 1
场景优化及建议
● 场景1
场景描述：select * from tab1 u where status = 1查出的数据非常多，表中90%
以上的数据满足条件。
优化建议：为了避免对大表全表扫描并且排序，建议走排序字段的索引规避排序（index full sacn），尤其是大部分的查询是访问第一页或前几页的话，这样性能是很高的。
● 场景2
场景描述：select * from tab1 u where status = 1查出的数据非常少，表中5%以
下数据满足条件
优化建议：此时应该走where条件的索引。
● 场景3
场景描述：如果是对一个大表不断翻页，直到把数据处理完
优化建议：如果还用普通的分页查询的SQL，那么越往后会越慢，很多数据会重
复扫描，效率很低。
比较好的做法如下：
select a.*, rownum rn from
( select * from tab1 u where status = 1 and id > :max_id order by ) a
where rownum <= 500
或者
select * from tab1 where id > :max_id order by id limit 500;
每次获取上次的最大ID，查询时指定大于上次的最大ID，走ID索引实际不排序，
这样的效率会比较高，每次查询的效率也是比较稳定的。
● 场景4
场景描述：需要对统计分页数据的总数，并且数据量很大
优化建议：如果每次分页查询都需要统计总数，并且数据量还很大，那么性能肯
定很差，建议业务上对结果缓存或者不统计总数，例如可以显示前10页。
2 锁并发控制
场景分析
● 重复插入数据
问题描述：需要判断某条数据是否存在，如果不存在则插入该数据。在并发场景下，如果不做锁控制并且表上没有唯一键的话，就可能出现重复插入数据的情况。
例如，用户订购业务前判断下是否存在该业务，但是用户ID和业务ID并不是联合主键，并
发场景下，两个会话同时查询某个用户是否有该业务订购关系时