ultiple identical sql caches are large h2statementcache、IgniteH2Indexing

select case when c2 in ('B1','B2','B3'.....,'B10000') then '0' else 1 end from t_test where c1 in ('A1','A2','A3'.....,'A9999','A10000');
select case when c2 in ('B2','B3','B4'.....,'B10000','B1') then '0' else 1 end from t_test where c1 in ('A2','A3','A4'.....,'A10000','A1');
select case when c2 in ('B3','B4','B5'.....,'B10000','B1','B2') then '0' else 1 end from t_test where c1 in ('A3','A4'.....,'A10000','A1','A2');
....
select case when c2 in ('B10000','B1','B2'.....,'B9997','B9998','B9999') then '0' else 1 end from t_test where c1 in ('A10000','A1'.....,'A9997','A9998','A9999');
These sql execution results are the same, but a large number of h2statementcache、IgniteH2Indexing objects are cached

Start by tracing how H2StatementCache and IgniteH2Indexing cache the SQL statements shown in the issue. Compare the cache entries produced by the reordered IN-list queries and identify why equivalent results remain separate. Done means the reported query pattern no longer creates an unnecessarily large number of cached objects, with relevant behavior verified in the existing SQL or cache tests.

Written by the indexing model from the issue text.