在修改这个类的过程中，顺便研究了下数据批量更新的效率问题，分析结果如下。由于对于不同的数据库，效果也不尽相同，这里以MySQL和Oracle为例，并分开描述：

MySQL：

MySQL本身并不支持批量更新，只是驱动程序提供了这个特性，只有高版本才支持该特性，并且连接URL上必须加上

rewriteBatchedStatements=true

这样的参数，这样驱动程序会自动将多条SQL语句拼接成一条，从而提高了执行效率。

...
for (int i = 0; i < sqlList.size(); i++) {
stmt.addBatch(sqlList.get(i));
}

stmt.executeBatch();
connection.commit();

效率提升是必然的，原因很简单：非批量更新方式，autoCommit=true，每一条SQL语句都会自动提交，都会产生网络数据包、磁盘IO。而批量更新方式，只会产生少量的数据包，因为很多条SQL语句被打成一个数据包，一次性的通过网络传输到服务器，相应的，服务器的IO操作也少了很多，当然效率自然会提高。

就是因为这个和网路相关，所以网络环境不同，产生的提升效果也不相同，经测试，在比较快速的网络环境下，比如局域网，我的试验结果是：10万条SQL语句，在非批量情况下，使用了约36秒，而批量操作只使用了约9秒，效率提高了3倍。

如果在比较差的网络环境下，提升的效果会更明显，我使用VPN从家里连接到公司的内网，更新1万条数据，非批量方式，大概需要270秒左右，而批量方式大约9秒，提升了近30倍。效率提升的倍数和很多因素相关，比如刚才提到的网络环境，每次提交多少条SQL语句也很关键，并且MySQL表的类型也会影响这个：MyISAM类型的表的提升效率就远远的高于InnoDB类型的表。

注：上述的所有的所有测试都没有使用Prepared Statement，只是使用普通的Statement和executeBatch()，如果使用Prepared Statement，几乎没有任何效率提升，后来发现是因为我用的mysql-connector-java的版本过低(5.1.8)，替换为5.1.17后，VPN状态，效率提升50倍左右。

Oracle：

和MySQL相反，Oracle使用批量更新，如果不使用Prepared Statement，效果可能会更差，使用了Prepared Statement，我用VPN连接到公司的内网，效率提高了75倍左右。可能是因为我用的Oracle JDBC驱动对非Prepared Statement的支持不够好吧。

MSSQL:

待测试，稍后更新…

小结

数据库更新的效率提升，由很多原因决定：网络环境，服务器内存、服务器I/O、驱动版本、代码编写方式、数据库的版本、表的类型等。我们必须综合考量所有因素，才能达到理想的效果。推荐你在你实际的环境中做相应的测试，找出最优的方法，别人的优化方法，不一定完全适用于你，比如这里提到的提升倍数，每个人的试验结果肯定不一样。

直到最近，在一个鲜有人访问的应用中发现，问题依旧，8小时候后的第一次访问，总是失败，刷新一下页面，就正常了。Google了一下，才知道MySQL不推荐使用autoReconnect=true来解决此问题，http://bugs.mysql.com/bug.php?id=5020，如下：

Note: Autoreconnect functionality will be depcreated and eventually removed in future
releases. 

The reason this isn't working for your particular case is that the methodolgy for
autoreconnect was changed to be safer after 3.0.11, and is related to autoCommit state,
which will also cause the current 'in-flight' transaction to fail (if you attempt your
transaction again _after_ the failure, the driver will reconnect). Please see the docs
for the explanation on how to correctly use this feature in the 'Troubleshooting'
section.

In any case, there is no 100% safe way that a JDBC driver can re-connect automatically if
a TCP/IP connection dies without risking corruption of the database 'state' (even _with_
transactional semantics), which is why this feature will eventually be removed.

The JDBC spec does not specify that a connection is alive no matter what happens to the
underlying network for this very reason. 

Clients of JDBC drivers are responsible for dealing with network failures, as only the
application itself (really the developer of the application) 'knows' what the 'correct'
response to a transaction failing due to the network going down is. 'Wait_timeout'
expiring on the server is basically a 'forced' network failure by the server. You can
correct this in a non-robust way by setting 'wait_timeout' higher, however, you as a
developer should be handling SQL exceptions in your code and taking appropriate recovery
actions, not just passing them up the call stack.

解决也很简单，记录最近一次的Connection访问时间，如果超过了8小时，就重新建立这个连接，经验证是可行的。另外也可以在建立Connection的同时，创建一个线程定时的去执行一个SELECT 1语句，前面的方法比较简单。

这里要指出的是，用Connection的isValid()方法去检测Connection是否有效是不行的，程序会死在那里（未调查原因），试图用isClosed()去判断Connection是否断开也是行不通的，因为只有明确的调用了Connection的close()方法后，你才能用isClosed()去判断，也就是说Connection在idle超过8小时候后，这个时候你如果去打印它的isClosed()的值，它还是显示false，但实际上却不能使用。

硬件：AMD Opteron 265 1.8G(Cache 1M), RAM:1G, HD: 350G，算是配置比较差的一台服务器。请注意，下面所提到的数据和您的服务器性能有很大的关系。

// Delete Data
2009-09-03 19:45:45 Start…
Row Count: 46500394(46M)
DELETE FROM atedata WHERE DATE < ’2009-06-01 00:00:00′
Row Count: 22699749(22M)
2009-09-03 21:18:06 End…

从上面可以看出，删除数据是比较慢的操作，46M条的数据，删除到22M条，总共用了大概93分钟，大概255,921rows/min。删除操作所需时间主要和将要删除的数据量是成正比的，删除的记录数越多，所用的时间也越多。

// Optimize Table
2009-09-04 21:33:54 Start…
Row Count: 23051455(23M) – 7.1GiB
optimize table atedata
Row Count: 23051455(23M) – 3.4GiB
2009-09-04 22:15:37 End…

对于数据量比较大的表，比如超过1G，如果只是简单的用DELETE删除了数据，这些数据所占据的磁盘空间并没有被释放，在MySQL里我们称之为：Overhead。只有对表做了OPTIMIZE操作，才能真正的释放它。

从上面的数据可以看出，优化前，表大小是7.1G，优化后表大小为3.4G，表的记录数没有变化，用时42分钟，平均88MiB每分钟。该操作耗时大致和(Table Size – Overhead)的差成正比。对于那种比较大的表，千万不要删除了几百条记录就做Optimize操作，因为它太耗费时间了，我们可以累积到一定数量再做。

Optimize命令执行后，MySQL会生产一个临时的.TMD文件，MySQL的状态显示Repair by sorting，它其实就是优化后的表。这个过程很漫长，做完后，还有一步是重建索引，MySQL状态显示Repair with Keycache，结束的时候会有个.TMM的临时文件生成，它可能就是.MYI文件的拷贝，不过官方文档没有说明，只是猜测。

在创建索引文件的过程中(Repair with Keycache)，它的耗时和表的索引多少有很大的关系，我没有验证，但我们可以猜测：索引越多，这个过程就越长。

由于在表很大的情况下，做类似DELETE、OPTIMIZE、ALTER等操作，都是非常的耗时间，所以我们在设计系统的时候就需要提前考虑到：

1. 保存数据的时间长度
2. 做Data Purge的周期、方法策略
3. 数据备份的策略
4. Data Purge的过程中，系统该如何应对（以上操作都会造成MySQL被锁定，数据库无法使用）
5. 等等

如果数据量不大的话，另当别论。

[ad]

本操作的环境为：

• CentOS 5.2
• MySQL-server-community-5.1.23-0.rhel4
• 需要同步的数据库por和misc中有旧的数据，如果是空的库，下面的操作就简单一些了。
• 这里待复制的两个库por和misc均使用MyISAM引擎

Step I：

首先编辑主服务器的my.cnf，下面是个例子：

[mysqld]

…

log-bin=mysql-bin

binlog-do-db=por

binlog-do-db=misc

binlog-ignore-db=mysql

server-id=1

 

…

Replaction是基于log文件的，所以这里必须打开MySQL的log功能，log-bin参数指明log文件的前缀，binlog-do-db参数指明你要同步的数据库名，binlog-ignore-db指明你不想同步的数据库名(在本次安装方案中，有些多余，不过我没有测试去掉它会如何)

还有一个重要的是要设置master服务器的ID，也就是serer-id。接下来，在master上创建一个用户同步的用户：

mysql> GRANT REPLICATION SLAVE ON *.*
    -> TO 'repl'@'%' IDENTIFIED BY 'this_is_your_password';

Step II

重启MySQL服务器，这样就会生成log文件，通常在/var/lib/mysql下，然后用root登录，执行如下命令

mysql> FLUSH TABLES WITH READ LOCK;

这样做的目的是，让master服务器停止更新操作，可以为接下来的同步数据做一个干净的copy。

Step III

进入/var/lib/mysql 将你要同步的的数据库打包，比如这里为：por.tar和misc.tar

然后在MySQL命令行下执行：

show master status;

系统提示：

mysql> show master status;

+——————+———–+——————-+——————+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB        |

+——————+———–+——————-+——————+

| mysql-bin.000001 | 106| por,misc,por,misc | mysql,mysql |

+——————+———–+——————-+——————+

1 row in set (0.00 sec)

这时候你就可以解除锁定了：

mysql> UNLOCK TABLES;

Step IV：

下面开始设置slave server

编辑slave 的my.cnf如下：

[mysqld]

…

server-id=2

master-host=165.204.233.38

master-user=repl

master-password=this_is_your_password

master-port=3306

master-connect-retry=60

…

Step V:

重启Slave，用root登录，执行如下命令：

>stop slave;

> change master to

-> master_host=’165.204.233.38′,

-> master_user=’repl’,

-> master_password=’this_is_your_password’,

-> master_log_file=’mysql-bin.000001′, // 注意这里的文件名就是上面提到的 show master status中显示的文件名

-> master_log_pos=106;                       // 注意这里的便宜值就是上面提到的 show master status中显示的偏移值

> slave start;

完毕。

测试一下吧，在master里面建一个新的table，看看是否在slave中出现。

附录：

1. 如果你同步不成功，请查看MySQL的日志 缺省位于：/var/log/mysqld.log
2. 最好主从服务器使用同一版本的MySQL
3. 这里所配置的只是Replication Server，不是MySQL Cluster，不要混为一谈

[ad]