You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>
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
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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>
In the new version, a separate layer of caching has been added for parsing: <sql, ParseASTNode>.
My questions are:
Beta Was this translation helpful? Give feedback.
All reactions