だからここに解決策があります:
プリペアドステートメントを使用せず、文字列SQLステートメントを使用して挿入するだけの場合、JDBCはステートメントをMySQLサーバーに移動するだけで、MySQLサーバーは文字列を符号なし64の数値(BigInt-20)に正しく解析できるため、心配する必要はありません。
準備ステートメントを使用すると、問題が発生します。行う場合:
BigInteger bi = new BigInteger("18446744073709551615"); // max unsigned 64-bit number
statement.setObject(2, bi, Types.BIGINT);
statement.execute();
JDBCはこれを長い署名付きに切り捨てたいため、MySqlDataTruncation例外が発生します。
行う場合:
BigInteger bi = new BigInteger(new Long(Long.MAX_VALUE).toString());
statement.setObject(2, bi, Types.BIGINT);
statement.execute();
値はJavaのsignedlong内にあるため、これは機能します。
したがって、常に機能する回避策は次のとおりです。
BigInteger bi = new BigInteger("18446744073709551615"); // max unsigned 64-bit number
statement.setString(2, bi.toString());
statement.execute();
最終的にデータを文字列として渡し、MySQLサーバーに適切に解析させます。
符号なし64ビット数は多くの統計アプリケーションで発生し続けるため、誰かがJDBCドライバーを修正する必要があります。