发一篇mysql JDBC URL格局及其参数申明

DBaaS系统其实具有更大的市场机遇：像其他云服务一样，DBaaS意味着更短的销售周期，更少的启动费用，持续不断的收入，也意味着比之前更多的客户。比来碰到如许的成绩
会报atcom.MySQL.jdbc.MysqlIO.readFully(MysqlIO.java:1905)
atcom.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2351)
atcom.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2862)
atcom.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571)
atcom.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666)
atcom.mysql.jdbc.Connection.execSQL(Connection.java:2988)
atcom.mysql.jdbc.Connection.execSQL(Connection.java:2917)
atcom.mysql.jdbc.Statement.executeQuery(Statement.java:824)
atcom.zycy.db.DbTrans.executeQuery(DbTrans.java:127)
如许的毛病，重启Tomcat服务后就行了，可是过一夜就有呈现如许的成绩


mysqlJDBCURL格局以下：

jdbc:mysql://[host:port],[host:port].../[database][?参数名1][=参数值1][&参数名2][=参数值2]...

经常使用的几个较为主要的参数：

参数称号参数申明缺省值最低版本请求
user数据库用户名（用于毗连数据库）一切版本
passWord用户暗码（用于毗连数据库）一切版本
useUnicode是不是利用Unicode字符集，假如参数characterEncoding设置为gb2312或gbk，本参数值必需设置为truefalse1.1g
characterEncoding当useUnicode设置为true时，指定字符编码。好比可设置为gb2312或gbkfalse1.1g
autoReconnect当数据库毗连非常中止时，是不是主动从头毗连？false1.1
autoReconnectForPools是不是利用针对数据库毗连池的重连战略false3.1.3
failOverReadOnly主动重连乐成后，毗连是不是设置为只读？true3.0.12
maxReconnectsautoReconnect设置为true时，重试毗连的次数31.1
initialTimeoutautoReconnect设置为true时，两次重连之间的工夫距离，单元：秒21.1
connectTimeout和数据库服务器创建socket毗连时的超时，单元：毫秒。0暗示永不超时，合用于JDK1.4及更高版本03.0.1
socketTimeoutsocket操纵（读写）超时，单元：毫秒。0暗示永不超时03.0.1

对应中文情况，一般mysql毗连URL能够设置为：
jdbc:mysql://localhost:3306/test?user=root&password=&useUnicode=true&characterEncoding=utf8&autoReconnect=true&failOverReadOnly=false

在利用数据库毗连池的情形下，最好设置以下两个参数：
autoReconnect=true&failOverReadOnly=false

必要注重的是，在xml设置文件中，url中的&标记必要本义成&。好比在tomcat的server.xml中设置数据库毗连池时，mysqljdbcurl样比方下：
jdbc:mysql://localhost:3306/test?user=root&password=&useUnicode=true&characterEncoding=utf8&autoReconnect=true&failOverReadOnly首先我们要知道，或许有一项技术存在很多理由让我们可以选择使用MySQL学习教程，但是让我们不使用它往往只要有一个理由就足够了。

一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

SP4是一个累积性的ServicePack，包含自以前的ServicePack发布以来所有的修补程序（包括MS03-031安全公告）。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录.