背景

最近定位生产环境一个GC卡顿问题，这个卡顿导致k8s心跳服务检查超时触发了docker容器重启；卡顿截图如下：

问题分析（省略过程…）

通过参考jprofiler分析内存使用情况，发现有一个接口返回内容太多，最终找到原因是这个接口分页失效导致返回内容有64MB。

sharding-core-3.1.0分页代码有问题

简单来说，当sql查询语句存在group by or order by则返回所有记录；导致代码中使用的pagehelper分页不生效

io.shardingsphere.core.routing.router.sharding.ParsingSQLRouter#processLimit

private void processLimit(final List<Object> parameters, final SelectStatement selectStatement) {
    boolean isNeedFetchAll = (!selectStatement.getGroupByItems().isEmpty() || !selectStatement.getAggregationSelectItems().isEmpty()) && !selectStatement.isSameGroupByAndOrderByItems();
    selectStatement.getLimit().processParameters(parameters, isNeedFetchAll, databaseType);
}

io.shardingsphere.core.parsing.parser.context.limit.Limit#rewrite

private void rewrite(final List<Object> parameters, final boolean isFetchAll, final DatabaseType databaseType) {
    int rewriteOffset = 0;
    int rewriteRowCount;
    if (isFetchAll) {
        rewriteRowCount = Integer.MAX_VALUE;
    } else if (isNeedRewriteRowCount(databaseType)) {
        rewriteRowCount = null == rowCount ? -1 : getOffsetValue() + rowCount.getValue();
    } else {
        rewriteRowCount = rowCount.getValue();
    }
    if (null != offset && offset.getIndex() > -1) {
        parameters.set(offset.getIndex(), rewriteOffset);
    }
    if (null != rowCount && rowCount.getIndex() > -1) {
        parameters.set(rowCount.getIndex(), rewriteRowCount);
    }
}

代码优化

1. 代码逻辑允许情况下，不使用 group by 或 order by
2. 修改源代码实现
3. 官网有issue意见解决 https://github.com/apache/shardingsphere/pull/1736

其他方法还在研究