运用MySQL JDBC读取过较大数据量的人应当清晰（比方凌驾1GB），在读取的时刻内存很可以会Java堆内存溢出，而我们的处理计划是statement.setFetchSize(Integer.MIN_VALUE)并确保游标是只读向前转动的即可（为游标的默许值），也可以强迫范例转换为com.mysql.jdbc.StatementImpl，然后挪用其内部要领：enableStreamingResults()如许读取数据内存就不会挂掉了，这两者到达的效果是一致的。固然也可以运用useCursorFetch，然则这类体式格局测试效果机能要比StreamResult慢许多，为何？在本文会论述其大抵的道理。
我在前面的部份文章和书本中都有引见过其MySQL JDBC在这一块内部处置惩罚的代码分红三个差别的类来完成的，不过我一向没有去穷究过数据库和JDBC之间究竟是怎样通讯的历程。有一段时候我一向认为这都属于服务端行动或许是客户端与服务端合营的行动，然后并不其然，本日我们来说一下这个行动是怎么回事。
【先回忆一下简朴的通讯】：
JDBC与数据库之间的通讯是经由过程Socket完成的，因而我们可以把数据库当做一个SocketServer的提供方，因而当SocketServer返回数据的时刻（类似于SQL效果集的返回）其流程是：服务端顺序数据（数据库） -> 内核Socket Buffer -> 收集 -> 客户端Socket Buffer -> 客户端顺序（JDBC地点的JVM内存）
到目前为止，IT行业中人人所看到的JDBC无论是：MySQL JDBC、SQL Server JDBC、PG JDBC、Oracle JDBC。以至因而NoSQL的Client：Redis Client、MongoDB Client、Memcached，数据的返回基础也是如许一个逻辑。
【运用MySQL JDBC默许直接读取数据为何会挂？】
（1）MySQL Server方在提议的SQL效果聚会会议悉数经由过程OutputStream向外输出数据，也就是向当地的Kennel对应的socket buffer中写入数据，这是一次内存拷贝（内存拷贝这个不是本文的重点）。
（2）此时Kennel的Buffer有数据的时刻就会把数据经由过程TCP链路（JDBC主动提议的Socket链路），回传数据，此时数据会回传到JDBC地点机械上，会先进入Kennel地区，一样进入到一个Buffer区。
（3）JDBC在提议SQL操纵后，Java代码是在inputStream.read()操纵上壅塞，当缓冲区有数据的时刻，就会被叫醒，然后将缓冲区的数据读取到Java内存中，这是JDBC端的一次内存拷贝。
（4）接下来MySQL JDBC会不停读取缓冲区数据到Java内存中，MySQL Server会不停发送数据。注重在数据没有完整组装完之前，客户端提议的SQL操纵不会响应，也就是给你的觉得MySQL服务端还没响应，实在数据已到当地，JDBC还没对挪用execute要领的处所返回效果集的第一条数据，而是不停从缓冲器读取数据。
（5）关键是这个傻帽就像一把这个数据读取完，基础不管家里放不放的下，就会将全部表的内容读取到Java内存中，先是FULL GC，接下来就是内存溢出。
【JDBC参数上设置useCursorFetch=true可以处理】
这个计划合营FetchSize设置，确切可以处理题目，这个计划实在就是通知MySQL服务端我要若干数据，每次要若干数据，通讯历程有点像如许：
如许做就像我们生活中的那样，我须要什么就去超市买什么，须要若干就去买若干。不过这类交互不像如今网购，坐在家里就可以把东西送到家里来，它肯定要走路（收集链路），也就是须要收集的时候开支，假如数据有1亿数据，将FetchSize设置成1000的话，会举行10万次往返通讯；假如收集耽误同机房0.02ms，那末10万次通讯会增添2秒的时候，不算大。那末假如跨机房2ms的耽误时候会多出来200秒（也就是3分20秒），假如国内跨都市10~40ms耽误，那末时候将会1000~4000秒，假如是跨国200~300ms呢？时候会多出十多个小时出来。
在这里的盘算中，我们还没有包括体系挪用次数增添了许多，线程守候和叫醒的上下文次数变多，收集包重传的状况对团体机能的影响，因而这类计划看似合理，然则机能确不怎么样。
别的，由于MySQL方不晓得客户端什么时刻将数据消耗完，而自身的对应表可以会有DML写入操纵，此时MySQL须要竖立一个暂时表空间来寄存须要拿走的数据。因而关于当你启用useCursorFetch读取大表的时刻会看到MySQL上的几个征象：
（1）IOPS飙升，由于存在大批的IO读取，假如是平常硬盘，此时可以会引起营业写入的发抖
（2）磁盘空间飙升，这块暂时空间可以比原表更大，假如这个表在全部库内部占用相当大的比重有可以会致使数据库磁盘写满，空间会在效果集读取完成后或许客户端提议Result.close()时由MySQL去接纳。
（3）CPU和内存会有肯定比例的上升，依据CPU的才决议。
（4）客户端JDBC提议SQL后，长时候守候SQL响应数据，这段时候就是服务端在预备数据，这个守候与原始的JDBC不设置任何参数的体式格局也表现出守候，在内部道理上是不一样的，前者是一向在读取收集缓冲区的数据，没有响应给营业，如今是MySQL数据库在预备暂时数据空间，没有响应给JDBC。
【Stream读取数据】
我们晓得第1种体式格局会致使Java挂掉，第2种体式格局效力低而且对MySQL数据库的影响较大，客户端响应也较慢，仅仅可以处理题目罢了，那末如今来看下Stream读取体式格局。
前面提到当你运用statement.setFetchSize(Integer.MIN_VALUE)或com.mysql.jdbc.StatementImpl.enableStreamingResults()就可以开启Stream读取效果集的体式格局，在提议execute之前FetchSize不能再手工设置，且确保游标是FORWARD_ONLY的。
这类体式格局很奇异，好像内存也不挂了，响应也变快了，对MySQL的影响也变小了，最少IOPS不会那末大了，磁盘占用也没有了。之前仅仅看到JDBC中走了零丁的代码，认为这是MySQL和JDBC之间的另一种通讯协定，却不知，它竟然是“客户端行动”，没错，你没看错，它就是客户端行动。
它在提议enableStreamingResults()的时刻，险些不会做任何与服务端的交互事变，也就是服务端会根据体式格局1回传数据，那末服务端用力向缓冲区怼数据，客户端是怎样扛得住压力的呢？
在JDBC当中，当你开启Stream效果集处置惩罚的时刻，它并非一把将一切数据读取到Java内存中的，也就是图1中并非一次性将数据读取到Java缓冲区的，而是每次读取一个package（这个package可以明白成Java中的一个byte[]数组），一次最多读取这么多，然后会看是不是继承向下读取保证数据的完整性。营业代码是根据字节剖析成行也营业方运用的。
服务端刚最先用力向缓冲区怼数据，这些数据也会怼满客户端的内核缓冲区，当双方的缓冲区都被怼满的时刻，服务端的1个Buffer尝试经由过程TCP通报数据给接收方时，此时由于消耗方的缓冲区也是满的，因而发送方的线程会壅塞住，守候对方消耗，对方消耗一部份，就可以推送一部份数据过去。连起来看就是JDBC的Stream数据未来得及消耗之前，缓冲区数据假如是满的，那末MySQL发送数据的线程就壅塞住了，如许确保了一个均衡（关于这一点，人人可以运用Java的Socket来尝试下是不是是如许的）。
关于JDBC客户端，数据猎取的时刻每次都在当地的内核缓冲区当中，就在小区的快递包裹箱拿回家一个间隔，那末天然比起每次去超市的RT要小得多了，而且这个历程是预备好的数据，所以没有IO壅塞的历程（除非MySQL服务端通报的数据还不如消耗端处置惩罚数据来得快，那平常也只需消耗端不做任何营业，拿到数据直接摒弃的测试代码，才会发作如许的事变），这个时刻不管：跨机房、跨地区、跨国度，只需服务端最先响应就会源源不停地通报数据过来，而这个行动纵然是第1种体式格局也是必定须要阅历的历程。
相干于第1种体式格局，JDBC运用的时刻会不致使内存溢出，纵然读取大表不内存溢出也会很长时候才会响应；不过这类体式格局相对体式格局1来说对数据库影响相对较大，在通报的数据的历程当中，响应的数据行会被上锁（防备被修正），运用InnoDB会分段加锁处置惩罚，运用MyISAM会加全表锁，可以致使营业壅塞。
【理论上可以更进一步，只需你情愿】
理论上这类体式格局是比较好的了，然则就圆满主义来说，我们可以继承讨论一下，关于懒人来说，我们连到小区楼下快递包裹箱去拿一下的动力也是没有的，我们内心想的就是如果谁给我拿到家里来送到我嘴巴里，连嘴巴都给我掰开多好。
在技术上理论上确切可以做到如许，由于JDBC从内核拷贝内存到Java当中是须要花时候的，如果有另一个人把这个事变做了，我在家里干别的事变的时刻它就给我送到家里来了，我要用的时刻就直接从家里来，这个时候岂不是省掉了。每错，关于你来说确切省掉了，不过题目就是谁来送？
在顺序中肯定须要加一个线程来干这个事变，把内核的数据拷贝到运用内存，以至于剖析成行数据，运用顺序直接运用，但这肯定圆满吗？实在这个中心就有个谐和题目了，比方家里要炒菜，缺一包调料，底本可以自身到楼下买，然则非要让他人送家里，这个时刻别的的菜都下锅了，就剩一包调料，那末你没别的方法，只能等这包调料送到家里来今后才举行炒菜的下一道工序。所以，在抱负状况下，它可以勤俭许屡次内存拷贝时候，会增添一些谐和锁的开支。
那末可以不可以直接从内核缓冲区读取数据呢？
理论上也是可以的，在诠释这个题目之前，我们先了解下除了这一次内存拷贝另有那些：
JDBC根据二进制将内核缓冲区的数据读取后，也会进一步剖析成细致的结构化数据，由于此时要给营业方返回ResultSet的细致行的结构化数据，也就是生成RowData的数据肯定会有一次拷贝，而且JDBC返回某些对象范例数据的时刻（比方byte []数组），在某些场景的完成，它不愿望你经由过程效果集修正返回效果中的byte []的内容（byte[1] = 0xFF）去修正ResultSet自身内容，可以还会再做1次内存拷贝，营业代码运用历程当中还会存在拼字符串，收集输出等，又是一堆的内存拷贝，这些在营业层面是没法防止的，相对这点点拷贝来说，险些眇乎小哉，所以我们也没去干这事变，认为从团体上看险些眇乎小哉，除非你的顺序瓶颈在这里。
因而从团体上看内存拷贝是没法防止的，多的这一次无非是体系级的挪用，开支会更大一点，从技术上来说，我们是可以做到直接从内核态直接读取数据的；但这个时刻就须要根据字节将Buffer从的数据拿走才让长途更多的数据通报过来，没有第三个位置寄存Buffer了，否则又回到了内核到运用的内存拷贝上来了。
相对来说，服务端却是可以优化直接将数据经由过程直接IO的体式格局通报（不过这类体式格局数据的协定就和数据的存储花样一致了，明显只是理论上的）， 要真正做到自定义的协定，又要经由过程内核态数据直接发送，须要经由过程修正OS级别的文件体系协定，来到达转换的目标。
以上就是浅谈MySQL JDBC StreamResult通讯道理的细致内容，更多请关注ki4网别的相干文章！
