Issue 1:
Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

Searched open and closed GitHub issues.

Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.

If no response more than 7 days and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-core</artifactId>
<version>4.0.0-RC1</version>
</dependency>
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-namespace</artifactId>
<version>4.0.0-RC1</version>
</dependency>

Which project did you use? Sharding-JDBC or Sharding-Proxy?

Sharding-JDBC

Expected behavior

want to complete in 3s

Actual behavior

14s

Reason analyze (If you can)

When i debug into code:

class=SQLExecuteCallback

method:execute0

line:T result = this.executeSQL(routeUnit.getSqlUnit().getSql(), statementExecuteUnit.getStatement(), statementExecuteUnit.getConnectionMode());

I found spent long

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

init data->total size:1,0000,000

1.execute sql script:sql:SELECT SUM(size) as size_sum FROM table_test

spent: 26s

2.add properties:max.tolerate.time.difference.milliseconds:8 ->restart application

3.execute sql script:sql:SELECT SUM(size) as size_sum FROM table_test

spent:14s

Example codes for reproduce this issue (such as a github link).

Issue 2:
Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

Searched open and closed GitHub issues.

Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.

If no response anymore and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

shardingsphere version: 5.0.0-RC1-SNAPSHOT

shardingsphere-example version: 5.0.0-alpha

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-JDBC

Expected behavior

The order_id and order_item_id should include odd and even numbers respectively. But all order_id is even number and all order_item_id is odd number.

Actual behavior

---------------------------- Print Order Data -----------------------

order_id: 609400984137347072, user_id: 1, address_id: 1, status: INSERT_TEST_JPA

order_id: 609400984552583168, user_id: 2, address_id: 2, status: INSERT_TEST_JPA

order_id: 609400984581943296, user_id: 3, address_id: 3, status: INSERT_TEST_JPA

order_id: 609400984607109120, user_id: 4, address_id: 4, status: INSERT_TEST_JPA

order_id: 609400984628080640, user_id: 5, address_id: 5, status: INSERT_TEST_JPA

order_id: 609400984644857856, user_id: 6, address_id: 6, status: INSERT_TEST_JPA

order_id: 609400984661635072, user_id: 7, address_id: 7, status: INSERT_TEST_JPA

order_id: 609400984682606592, user_id: 8, address_id: 8, status: INSERT_TEST_JPA

order_id: 609400984703578112, user_id: 9, address_id: 9, status: INSERT_TEST_JPA

order_id: 609400984724549632, user_id: 10, address_id: 10, status: INSERT_TEST_JPA

---------------------------- Print OrderItem Data -------------------

order_item_id:609400984498057217, order_id: 609400984137347072, user_id: 1, status: INSERT_TEST_JPA

order_item_id:609400984569360385, order_id: 609400984552583168, user_id: 2, status: INSERT_TEST_JPA

order_item_id:609400984594526209, order_id: 609400984581943296, user_id: 3, status: INSERT_TEST_JPA

order_item_id:609400984615497729, order_id: 609400984607109120, user_id: 4, status: INSERT_TEST_JPA

order_item_id:609400984636469249, order_id: 609400984628080640, user_id: 5, status: INSERT_TEST_JPA

order_item_id:609400984653246465, order_id: 609400984644857856, user_id: 6, status: INSERT_TEST_JPA

order_item_id:609400984674217985, order_id: 609400984661635072, user_id: 7, status: INSERT_TEST_JPA

order_item_id:609400984690995201, order_id: 609400984682606592, user_id: 8, status: INSERT_TEST_JPA

order_item_id:609400984711966721, order_id: 609400984703578112, user_id: 9, status: INSERT_TEST_JPA

order_item_id:609400984732938241, order_id: 609400984724549632, user_id: 10, status: INSERT_TEST_JPA

Reason analyze (If you can)

SNOWFLAKE algorithm causes data skew.

I had check FAQ, https://shardingsphere.apache.org/document/current/en/faq/#12-why-are-the-default-distributed-auto-augment-key-strategy-provided-by-shardingsphere-not-continuous-and-most-of-them-end-with-even-numbers, but it isn't the same issue.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

run org.apache.shardingsphere.example.sharding.spring.boot.jpa.ExampleMain#main

Example codes for reproduce this issue (such as a github link).

application.properties:

spring.profiles.active=sharding-tables