Some questions about sql-parsing cache

[FakeKotaro]

I've been using Sharding-JDBC's encryption feature and have recently been working on SQL parsing and rewriting performance. In version 4.1.0, SQL parsing has only one layer of cache, the structure is <sql, SqlStatement>

private SQLStatement parse0(final String sql, final boolean useCache) {
        if (useCache) {
            Optional<SQLStatement> cachedSQLStatement = cache.getSQLStatement(sql);
            if (cachedSQLStatement.isPresent()) {
                return cachedSQLStatement.get();
            }
        }
        ParseTree parseTree = new SQLParserExecutor(databaseTypeName, sql).execute().getRootNode();
        SQLStatement result = (SQLStatement) ParseTreeVisitorFactory.newInstance(databaseTypeName, VisitorRule.valueOf(parseTree.getClass())).visit(parseTree);
        if (useCache) {
            cache.put(sql, result);
        }
        return result;
    }

In the new version, a separate layer of caching has been added for parsing: <sql, ParseASTNode>.

public ParseASTNode parse(final String sql, final boolean useCache) {
        return useCache ? parseTreeCache.get(sql) : sqlParserExecutor.parse(sql);
    }

My questions are:

1. Why add a separate layer of caching for parsing
2. Why not add a layer of caching for rewrites, structured as <originSql, rewrittenSql>. Taking the encryption function as an example, the cache is like <"SELECT name FROM user","SELECT name_encode as name FROM user">, so that the cache can be queried when the original SQL is received, and there is no need to go through the process of parsing and visiting
3. I found that the first execution of SQL statements is slow, some complex SQL in local tests even reached 100ms latency, is this normal or is there a way to speed up the first execution?