如果我对相应的db列实际上是MySql PreparedStatement.setLong的参数使用integer，则显然在Java中传递int会使其自动扩大。但是在jdbc的“较低”级别中，这有什么关系吗？如果我期望db列的数据类型在相对不久的将来更改为long，使用biginteger可以避免额外的工作吗？
编辑：我的意思是，设置long的方法始终会收到一个int，因此我不会意外地传递一个对于数据库而言太大的值列。
答案 0 :(得分：2)
从100％形式上看，setLong列使用INTEGER可能是不安全的。 JDBC 4.3规范说setXXX方法（setObject除外）遵循附录B.2的映射，附录B.2表示Java long映射到SQL {{1} }。然后，这取决于驱动程序或数据库是否可以在BIGINT列中使用BIGINT值。
关于此问题的JDBC 1.20规范说：
7.2.1 IN参数上的数据类型符合性
PreparedStatement.setXXX方法不执行任何常规数据 类型转换。而是将Java值简单地映射到 对应的SQL类型（遵循表3中指定的映射 页28），该值将发送到数据库。
确保Java类型是程序员的责任 每个参数的映射都映射到与SQL兼容的SQL类型 数据库期望的数据类型。为了最大的便携性 程序员，应使用与确切的SQL相对应的Java类型 数据库期望的类型。
如果程序员需要IN参数的数据类型转换，则他们 可以使用PreparedStatement.setObject方法来转换Java 在将值发送到 数据库。
此措辞在最新的JDBC规范中不再存在，但其意图仍然适用，并且由JDBC 4.3中的附录B.2定义。
但是，实际上，许多JDBC驱动程序-包括MySQL Connector / J-支持更广泛的转换，类似于附录B.5中为INTEGER定义的转换，尽管每个驱动程序都有其注意事项和怪癖在这里。对于setObject，这意味着Long可以定位getObject，TINYINT，SMALLINT，INTEGER，BIGINT，REAL ，FLOAT，DOUBLE，DECIMAL，NUMERIC，BIT，BOOLEAN，CHAR，VARCHAR和通常，这意味着您也可以使用LONGVARCHAR做同样的事情。
这也为附录B.6中定义的setLong的转换提供了统一性。
它是否有缺点，取决于实现方式。 MySQL Connector / J驱动程序是开源的，因此，如果您想了解更多细节，请查看源代码。
但是，如果您的应用程序实际使用getLong，为什么数据库类型为long？在数据库中使用INTEGER来匹配您的应用程序，或者在应用程序中使用BIGINT来匹配数据库。