JDBC参数说明表 | ||||||||
---|---|---|---|---|---|---|---|---|
序号 | 参数名 | 类别 | 参数说明 | 依赖/互斥参数 | 使用指导 | 取值范围 | 默认值 | GoldenDB扩展参数 |
1 | connectTimeout | 连接 | socket连接超时(以毫秒为单位),0表示无超时。仅适用于JDK-1.4或更高版本。 默认值为0。 | 无 | 如果与数据库请求建立连接的时间超过ConnectionTimeOut,就会ConnectionTimeOutException,即服务器连接超时,没有在规定的时间内建立连接。 | >=0 | 10000 | 否 |
2 | socketTimeout | 连接 | 网络socket操作超时(以毫秒为单位)。默认值0表示没有超时。 | 无 | 如果服务器处理数据用时过长,超过了SocketTimeOut,就会抛出SocketTimeOutExceptin,即服务器响应超时,服务器没有在规定的时间内返回给客户端数据。 | >=0 | 0 | 否 |
3 | useServerPrepStmts | 性能 | 如果服务端支持prepare模式,则使用服务端的prepare模式。 | useServerPrepStmts=true&cachePrepStmts=true | 1)useServerPrepStmts=true表示开启prepare模式,调用服务端的prepare来使用; 2)useServerPrepStmts=false表示默认服务端不支持prepare模式,只使用cachePrepStmts缓存,简单解析SQL信息。 | TRUE/FALSE | FALSE | 否 |
4 | cachePrepStmts | 性能 | 是否开启缓存预处理语句的功能,如果开启,jdbc会缓存预处理statement信息,而不需要每次都重新发起预编译 | useServerPrepStmts或者useCursorFetch | 1.该缓存依赖开启预处理功能,通过设置参数useServerPrepStmts=true或者useCursorFetch=true开启预处理功能; 2.该缓存指的是jdbc将预处理的语句存储到jvm内存里,而不是DB上的缓存; 3.PreparedStatement调用close()方法时,才会将预处理语句存到该缓存中,所以在多并发编程中,关闭该statement后,才能真正使用到缓存的预处理语句。 4.获取该缓存里的statament时,是根据预处理sql进行完全匹配,包括大小写、长度、空格等。 5.该缓存连接(connect)级别的,不同连接的该缓存互不影响,关闭连接后,该缓存释放。 7.数据库参数max_prepared_stmt_count控制数据库可以支持预处理语句个数,当客户端发起的预处理语句个数超过max_prepared_stmt_count,不会报错,只是走普通语句执行流程: 1)当客户端创建的预处理语句个数大于max_prepared_stmt_count时,数据库返回如下错误,但jdbc会捕捉异常,不报错,而是重新创建普通的statement; 2)repStmtCacheSize<max_prepared_stmt_count时,可以正常使用到服务端使用的预处理语句。 | TRUE/FALSE | TRUE | 否 |
5 | prepStmtCacheSize | 性能 | 可以缓存预处理语句的个数 | cachePrepStmts 数据库参数:max_prepared_stmt_count | 1.该缓存采用LRU队列,当达到最大预处理语句个数时,替换最久未被使用的预处理语句。 | 大于0的整数 | 2000 | 否 |
6 | prepStmtCacheSqlLimit | 性能 | 预处理语句长度限制 | jdbc参数:cachePrepStmts 数据库参数:max_prepared_stmt_count | 1.当预处理语句的长度小于prepStmtCacheSqlLimit,预处理语句缓存功能正常使用 2.当预处理语句的长度大于prepStmtCacheSqlLimit,不会报错,但实际没有将该预处理语句加入到预处理缓存队列里,预处理缓存功能并没有起到作用 | 大于0的整数 | 2000 | 否 |
7 | useCursorFetch | 性能 | 是否启用游标功能 | 无 | 1.useCursorFetch打开后,useServerPrepStmts默认打开。 2.使用游标方式读取数据,可减少大结果集对客户端内存的冲击。 | TRUE/FALSE | FALSE | 否 |
8 | defaultFetchSize | 性能 | 使用游标读取数据时,每批次默认读取行数 | useCursorFetch | 1.当代码显示设置批次步长时,设置的值覆盖defaultFetchSize,例如: statement.setFetchSize(100) | 大于0的整数 | 0 | 否 |
9 | cacheCallableStmts | 性能 | 是否缓存调用存储过程的语句 | 无 | 无 | TRUE/FALSE | FALSE | 否 |
10 | cacheResultSetMetadata | 性能 | 是否启用缓存sql语句涉及的元数据功能,如果启用,则会将sql语句涉及的元数据缓存起来 | 与allowMultiQueries参数互斥 | 1.获取的元数据只有sql语句中涉及的,例如select id from tableA where id=1;则元数据包含的字段只有id | TRUE/FALSE | FALSE | 否 |
11 | callableStmtCacheSize | 性能 | 可以缓存存储过程语句的个数 | cacheCallableStmts | 无 | 大于0的整数 | 100 | 否 |
12 | metadataCacheSize | 性能 | 缓存sql语句涉及的元数据的个数 | cacheResultSetMetadata | 1.一个sql对应一个元数据结果对象 | 大于0的整数 | 50 | 否 |
13 | enableQueryTimeouts | 性能 | 是否启用查询语句超时检测功能 | 无 | 1.配合设置超时时间 statement.setQueryTimeout(xxxx),当超过设置的超时时间仍未返回信息,则报错。 | TRUE/FALSE | TRUE | 否 |
14 | largeRowSizeThreshold | 性能 | 定义行记录长度为大数据的阀值 | 无 | 1.行记录长度超过该阀值,采用不同的传输模式 | 大于0的整数 | 2048 | 否 |
15 | loadBalanceStrategy | 性能 | 负载均衡策略 | 无 | 1.配置loadblance负载均衡url: jdbc:mysql:loadbalance://xxx.xxx.xxx.xxx:xxx,xxx.xxx.xxx.xxx:xxx 2.支持以下策略: random-随机 bestResponseTime-最小响应时间优先 serverAffinity-指定服务器列表 | random bestResponseTime serverAffinity | random | 否 |
16 | rewriteBatchedStatements | 性能 | 是否开启构造多值批量插入功能 | useServerPrepStmts或者useCursorFetch | 1.前提使用preparestatement预编译功能 2.将批量插入的数据构造成 insert into tableA(xx,xx) values(xx,xx),(xx,xx)… 3.可以提升批量插入语句性能 4.对update和delete无效,且会降低性能 | TRUE/FALSE | FALSE | 否 |
17 | useLocalSessionState | 性能 | 是否使用本地属性(autocommit,read_only和transaction isolation) | 无 | 无 | TRUE/FALSE | FALSE | 否 |
18 | maxRows | 其他 | JDBC 返回查询的最大行数,默认返回所有行。 | 无 | 1)maxRows=数字,表示JDBC查询返回的最大行数(举例,maxRows=10,如果表中共有15行数据,则通过JDBC select * 最多只能获取10行数据 ) | INT | -1 | 否 |
19 | netTimeoutForStreamingResults | 其他 | JDBC会自动设置数据库的’net_write_timeout’变量为本参数配置的时间,单位是秒,值为0表示驱动不会调整该参数; 客户端超时断链时间:如果该参数大于0,JDBC驱动通过调用PreparedStatement的executeQuery()方法默认执行"“SET net_write_timeout= ?”" 这个命令去重新设置timeout时间。 | 无 | 使用场景:一般在网络条件比较差的时,或者客户端处理每个block耗时比较长时 1)netTimeoutForStreamingResults=时间,单位/s,该参数大于0表示JDBC驱动需要在每次查询请求发出之前会自动调整net_write_timeout,避免出现服务端等待时间超时导致断链; 2)netTimeoutForStreamingResults=0,驱动不会去修改net_write_timeout,默认为600s,当服务端等待时间超过600秒,服务端会与客户端断链,JDBC抛出异常: Communications link failure | >=0 | 600 | 否 |
20 | noTimezoneConversionForDateType | 其他 | 如果 ‘useTimezone’=‘true’ or ‘useLegacyDatetimeCode’=‘false’ 配合本参数配置为TRUE,则不使用服务器时区 | useLegacyDatetimeCode=true&useTimezone=true&noTimezoneConversionForDateType=true useLegacyDatetimeCode=false&noTimezoneConversionForDateType=true | 1)使用场景:客户端与服务端时区不一致; 2)根据依赖关系有两种使用方式; 3)使用举例: serverTimezone=UTC&useLegacyDatetimeCode=false&noTimezoneConversionForDateType=true 参数生效,此时客户端映射的时区为UTC,服务端时区为CST,客户端会自动将CST改成UTC时间,如果改成noTimezoneConversionForDateType=false或删掉该参数,客户端返回为CST时间。 | TRUE/FALSE | TRUE | 是 |
21 | queryTimeoutKillsConnection | 其他 | 当设置queryTimeout超时时间时,执行语句返回超时,是否将连接中断 | 无 | 请求超时强制断链开关,默认为关闭 | TRUE/FALSE | TRUE | 否 |
22 | useOldAliasMetadataBehavior | 其他 | 驱动程序是否应该对列和表的“ AS”子句使用旧式行为,并且仅返回ResultSetMetaData.getColumnName()或ResultSetMetaData.getTableName()的别名(如果有),而不是原始的列/表名?在5.0.x中,默认值为true。 | 无 | useOldAliasMetadataBehavior=true表示使用别名作为返回的 列名/表名; | TRUE/FALSE | TRUE | 否 |
23 | useSqlStateCodes | 其他 | 使用SQL标准状态码代替“旧版” X / Open / SQL状态码(true/false),默认值为“true” | 无 | 无 | TRUE/FALSE | TRUE | 否 |
24 | useTimezone | 其他 | Convert time/date types between client and server time zones (true/false, defaults to ‘false’)? This is part of the legacy date-time code, thus the property has an effect only when "“useLegacyDatetimeCode=true.” | |||||
在客户端和服务器时区之间转换time/date类型(true/false,默认为“false”)?这是旧版日期时间代码的一部分,因此该属性仅在“ useLegacyDatetimeCode = true”时有效。" | useLegacyDatetimeCode=true&useTimezone=true | 1)serverTimezone=UTC&useLegacyDatetimeCode=true&useTimezone=true 表示使用全球标准时间(UTC),即将服务器时区与客户端时区区分开来; 2)serverTimezone=UTC&useLegacyDatetimeCode=true&useTimezone=false 表示会将客户端的时区转换成服务器的时区。 | TRUE/FALSE | FALSE | 否 | |||
25 | zeroDateTimeBehavior | 其他 | What should happen when the driver encounters DATETIME values that are composed entirely of zeros (used by MySQL to represent invalid dates)? Valid values are ““exception””, ““round”” and ““convertToNull””. 当驱动程序遇到完全由零组成的DATETIME值(MySQL用来表示无效日期)时,应该怎么办?有效值为“ exception”,“ round”和“ convertToNull”。 | 无 | 1)zeroDateTimeBehavior=exception 默认参数,表示JDBC 驱动在处理’0000-00-00 00:00:00’这种全是0 的timestamp的时候,通过该配置项会选择直接抛出异常;2)zeroDateTimeBehavior=round 表示会转换成临近的日期; 3)zeroDateTimeBehavior=convertToNull 表示转换成NULL。 | ““exception””, ““round”” and ““convertToNull”” | exception | 否 |
26 | useUnicode | 其他 | Should the driver use Unicode character encodings when handling strings? Should only be used when the driver can’t determine the character set mapping, or you are trying to ‘force’ the driver to use a character set that MySQL either doesn’t natively support (such as UTF-8), true/false, defaults to ‘true’ 在处理字符串时,驱动程序是否应该使用Unicode字符编码?仅在驱动程序无法确定字符集映射时使用,或者您试图“强制”驱动程序使用MySQL本身不支持的字符集(例如UTF-8),true / false ,默认为“ true” | characterEncoding=latin1&useUnicode=true | 1)强制使用mysql本身不支持的字符集时需要使用该参数characterEncoding=gbk&useUnicode=true 表示使用gbk字符集; 2)驱动程序无法确定字符集时使用Unicode字符集。 | TRUE/FALSE | TRUE | 否 |
27 | characterEncoding | 其他 | If ‘useUnicode’ is set to true, what character encoding should the driver use when dealing with strings? (defaults is to ‘autodetect’) 如果将’useUnicode’设置为true,则驱动程序在处理字符串时应使用哪种字符编码?(默认为“自动检测”) | useUnicode=true&characterEncoding=latin1 | 当useUnicode设置为true时,指定字符编码。比如可设置为gb2312或gbk | autodetect/LATIN1、GBK、UTF8 | GBK | 否 |
28 | characterSetResults | 其他 | Character set to tell the server to return results as. 告诉服务器返回结果的字符集。 | 无 | 以指定字符集返回结果; | LATIN1、GBK、UTF-8、utf8mb4 | 否 | |
29 | autoReconnect | 高可用 | 是否启用自动连接功能 | 无 | 当数据库连接异常中断时,是否自动重新连接(mysql5以上该参数不起作用) (MySQL服务器默认的“wait_timeout”是8小时,如果一个连接的空闲时间超过8个小时,MySQL将自动断开该连接,而连接池却认为该连接还是有效的(因为并未校验连接的有效性),当应用申请使用该连接时,就会报错。) | TRUE/FALSE | FALSE | 否 |
30 | maxReconnects | 高可用 | 如果autoReconnect为true,则尝试进行的最大重新连接数, 默认值为’3’。 | 无 | autoReconnect设置为true时,根据该参数限制重试连接的次数。 | >=0 | 3 | 否 |
31 | initialTimeout | 高可用 | 如果启用了autoReconnect,则两次尝试重新连接之间的初始 时间(以秒为单位,默认为2)。 | 无 | autoReconnect设置为true时,根据该参数判断两次重连之间的时间间隔。 | >=0 | 2 | 否 |
32 | retriesAllDown | 高可用 | 使用负载平衡或故障转移时,驱动程序应在可用主机之间循环 尝试连接的次数。 在两个周期之间,如果没有可用服务器,驱动程序将暂停250ms。 | 无 | 无 | >=0 | 120 | 否 |
33 | useSSL | 安全 | 与服务器通信时使用SSL,连接到MySQL 5.5.45+,5.6.26+或5.7.6+时默认为“true”,否则为“ false” | 无 | MySQL在高版本需要指明是否进行SSL连接,否则会出现告警 | TRUE/FALSE | FALSE | 否 |
34 | allowMultiQueries | 在一个语句(真/假)期间允许使用“;”分隔多个查询,默认为“假”,并且不影响依赖于rewriteBatchStatements的addBatch()和executeBatch()方法。 | 无 | 一个sql中通过分号分割(或包含)了多个独立sql的话,如: String sql = ““select ‘hello’;select ‘world’””; 执行时会报MySQLSyntaxErrorException异常。 当显式设置allowMultiQueries为true的话,就可以正常执行不会报错 | TRUE/FALSE | FALSE | 否 | |
35 | maxAllowedPacket | 网络 | 发送到服务器的最大允许数据包大小。 如果未设置,则使用数据库中的’max_allowed_packet’的值初始化它;如果设置的值大于“max_allowed_packet”,则该值不会生效。 另外,由于内部依赖项具有属性“blobSendChunkSize”,如果将“ useServerPrepStmts”设置为“true”,则此设置的最小值为“8203”。 | 无 | 如果maxAllowedPacket的值设置大于mysql中的max_allowed_packet,则插入的数据大小根据max_allowed_packet值判断,反之。 (MySQL中会根据max_allowed_packet 参数限制server接受的数据包的大小。如果写入大数据时,因为默认的配置太小,插入和更新操作会因为 max_allowed_packet 参数限制,而导致失败。) | 取自 mysql.max_allowed_packet | 取自 mysql.max_allowed_packet | 否 |
36 | logSlowQueries | 调试 | 是否应该记录比’slowQueryThresholdMillis’时间更长的查询? | 无 | jdbc记录慢日志 | TRUE/FALSE | FALSE | 否 |
37 | slowQueryThresholdMillis | 调试 | 如果启用了“logSlowQueries”,查询耗时多长时间(以毫秒为单位),会被记录为“慢”? | 无 | logSlowQueries设为true,慢日志的阈值(毫秒) | >=0 | 2000 | 否 |
38 | slowQueryThresholdNanos | 调试 | 如果将“useNanosForElapsedTime”设置为true,并且 此属性设置为非零值,则驱动程序将使用此阈值(以纳秒为单位)来确定查询是否缓慢。 | 无 | useNanosForElapsedTime设为true,确定查询缓慢的时长(纳秒) | >=0 | 0 | 否 |
39 | dumpListSize | 调试 | 异常码流信息条数 | 无 | 异常码流信息条数 | >=0 | 0 | 是 |
40 | dumpInfoLength | 调试 | 每条异常码流信息长度 | dumpListSize | 每条异常码流信息长度 | >=0 | 1000 | 是 |
41 | isConnectionLevel | LoadBalance | 使用LoadBanlance协议可打开此功能 如果为false或者不填则走原来的LoadBanlance协议逻辑 | 无 | 使用原生协议不填参数或者为FALSE 使用修改后的协议填TRUE | TRUE/FALSE | TRUE | 是 |
42 | intervalTime | LoadBalance | 控制select 1发送间隔时间 单位毫秒 | isConnectionLevel | 设置为2000 | >=0 | 6000 | 是 |
43 | blackTaskTime | LoadBalance | 黑名单移除间隔时间 单位秒 | isConnectionLevel | 设置为20 | >=0 | 60 | 是 |
44 | shadowThreadSwitch | LoadBalance | 监控线程开关 | isConnectionLevel | true为开启 false为不开启,导入大量数据时候建议设置为FALSE | TRUE/FALSE | FALSE | 是 |
45 | prepareStrategy | 性能 | preparedStatement对象创建策略 | useServerPrepStmts | 通过该参数选择两种preparedStatement对象创建方式: 1、增删改使用客户端prepare,查询使用服务端prepare,2、全服务端prepare | 1,2, | 1 | 是 |
46 | errorCount | LoadBalance | 异常次数判断 | isConnectionLevel | 通过增加独立心跳检测,判断节点是否故障,统计心跳异常的次数,如果大于等于errorCount,则将该节点放入黑名单中,处于黑名单列表中的计算节点不会给连接池使用。隔离后在1分钟内再检查心跳后激活。 | >=0 | 1 | 是 |
47 | locatorFetchBuffer Size | 性能 | 缓存区的大小 | isConnectionLevel | 缓冲区是在解析SQL时分配的。因此缓冲区的大小不取决于查询返回的行数据的实际大小,而取决于行数据可能的最大大小。 其值与以下三点有关:(1)数据表的定义(2)代码查询的方式(3)FetchSize的值 | >=0 | 12400 | 是 |
48 | comStmtBatchFlag | 性能 | 是否开启新协议批量插入功能 | 无 | 1.使用新协议批量插入insert数据,理论上比只使用rewriteBatchedStatements=true性能更好 2.可以提升批量插入语句性能 3.对update和delete无效 | TRUE/FALSE | FALSE | 是 |
49 | proxygroups | LoadBalance | loadbalance配置的组数 | isConnectionLevel | proxygroups应为配置的proxygroup个数,示例:minconnectionproxys=1&proxygroups=2&proxygroup1=192.168.100.7:7788,192.168.100.8:7788&proxygroup2=192.168.100.9:7788,192.168.100.10:7788 | >=0 | 0 | 是 |
50 | minconnectionproxys | LoadBalance | loadbalance配置的组是有效的最小连接数 | isConnectionLevel | 当高优先级proxygroup中有效连接数小于此阈值,则部分请求下发到下一个优先级proxy节点,下一个优先级所有的proxy参与负载。 | >=0 | 0 | 是 |
51 | proxygroup(n) | LoadBalance | loadbalance配置的组内地址 | isConnectionLevel | 配置的一组连接,ip:port | ip:port | 无 | 是 |
51 | dbgroup | 其他 | 配置proxy下发分片 | 无 | 设置为下发分片,如g1,g2,g3,只能设置一个 示例:dbgroup=g1 | 有效分片g1,g2…gn | 无 | 是 |
52 | convertClientPstmts | 其他 | 是否转化为客户端prepare | 无 | convertClientPstmts=FALSE时,若prepare报错后,驱动直接抛出异常信息 | TRUE/FALSE | TRUE | 是 |
53 | reclaimBufferLength | 其他 | result buffer长度超过超过阈值,会被重新初始化 | 无 | 无 | 1024 * 50 ~ 1024 * 1024 | 1048576 | 是 |
54 | trackConnection | 其他 | 是否启用链路追踪 | 无 | trackConnection=FALSE时,则不会将已关闭链路加入链路释放队列中 | TRUE/FALSE | TRUE | 是 |
55 | closeStmtOnCompletionAction | 其他 | 当closeOnCompletion=true后,是否关闭prepare | 无 | closeStmtOnCompletionAction=TRUE时,当closeOnCompletion=true后,关闭prepare | TRUE/FALSE | FALSE | 是 |
56 | readFromSlave | 其他 | readFromSlave=true,打开单分片备机查询只读功能 | 无 | readFromSlave=true,链路属性会设置为只读,只能执行查询sql。 | TRUE/FALSE | FALSE | 是 |
57 | batchUpdateDelete | 其他 | batchUpdateDelete=true,支持update、delete批量新协议 | comStmtBatchFlag | 当comStmtBatchFlag=true,批量新协议开关打开时,batchUpdateDelete=true,支持insert、update、delete批量新协议,batchUpdateDelete=false,只支持insert批量新协议 | TRUE/FALSE | FALSE | 是 |
58 | oracleGeneratedKey | 其他 | 是否返回rowid | 无 | 当oracleGeneratedKey=true后,getGeneratedKeys返回RowId, 否则返LastInsertID | TRUE/FALSE | FALSE | 是 |
59 | oracleMode | 其他 | 是否启Oracle模式 | 无 | 当oracleMode=true后,兼容oracle 语法解析prepare | TRUE/FALSE | TRUE | 是 |
60 | closeCachePrepStmts | 其他 | 是否主动关闭cachePrepStmts | 无 | closeCachePrepStmts=false时,业务调用close,已经入缓存的statement对象不会被主动close,而是在缓存队列满时,被动close | TRUE/FALSE | TRUE | 是 |
61 | clientUser | 其他 | 是否设置JDBC运行所在的用户名 | 无 | clientUser=true时,通过set命令,将JDBC运行所在的用户名发送给CN | TRUE/FALSE | FALSE | 是 |
08-31
2万+
![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png)
11-17