MYSQL中，存储手机号码的字段bigint(11)好，还是varchar(11)好，哪个更节省空间

当然是bingint占空间小而且速度快了， 不过我一般用varchar(11) 呵呵，这样节省的空间我觉得可以忽略。 如果varchar 和 char 选择 那还是用 char吧，会比varchar 快 嘿嘿

1 读取 *** 作开始遇到的问题是当sql查询数据量比较大时候基本读不出来。开始以为是server端处理太慢。但是在控制台是可以立即返回数据的。于是在应用

这边抓包，发现也是发送sql后立即有数据返回。但是执行ResultSet的next方法确实阻塞的。查文档翻代码原来mysql驱动默认的行为是需要把整个结果全部读取到

内存中才开始允许应用读取结果。显然与期望的行为不一致，期望的行为是流的方式读取，当结果从myql服务端返回后立即还是读取处理。这样应用就不需要大量内存

来存储这个结果集。正确的流式读取方式代码示例：

PreparedStatement ps = connection.prepareStatement("select .. from ..",

ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)

//forward only read only也是mysql 驱动的默认值，所以不指定也是可以的 比如： PreparedStatement ps = connection.prepareStatement("select .. from ..")

ps.setFetchSize(Integer.MIN_VALUE)//也可以修改jdbc url通过defaultFetchSize参数来设置，这样默认所以的返回结果都是通过流方式读取.

ResultSet rs = ps.executeQuery()

while (rs.next()) {

System.out.println(rs.getString("fieldName"))

}

我们经常会遇到 *** 作一张大表，发现 *** 作时间过长或影响在线业务了，想要回退大表 *** 作的场景。在我们停止大表 *** 作之后，等待回滚是一个很漫长的过程，尽管你可能对知道一些缩短时间的方法，处于对生产环境数据完整性的敬畏，也会选择不做介入。最终选择不作为的原因大多源于对 *** 作影响的不确定性。实践出真知，下面针对两种主要提升事务回滚速度的方式进行验证，一种是提升 *** 作可用内存空间，一种是通过停实例，禁用 redo 回滚方式进行进行验证。

仔细阅读过官方手册的同学，一定留意到了对于提升大事务回滚效率，官方提供了两种方法：一是增加 innodb_buffer_pool_size 参数大小，二是合理利用 innodb_force_recovery=3 参数，跳过事务回滚过程。第一种方式比较温和，innodb_buffer_pool_size 参数是可以动态调整的，可行性也较高。第二种方式相较之下较暴力，但效果较好。

两种方式各有自己的优点，第一种方式对线上业务系统影响较小，不会中断在线业务。第二种方式效果更显著，会短暂影响业务连续，回滚所有没有提交的事务。

---