数据库资料在网络传送的方式？？

是这样的。sql server采用一种叫tds，就是表格格式数据流，那么查询结果会按照这种协议打包，然后发送到客户端。而在sql server中的数据包的一般大小时4k，所以你有1G的数据量，那么就需要发送很多次，才能发送完成，发送完后，接收端会发送一个确认的信息，然后服务器端会发送下一个，直到发送完所有的数据为为止

解决方案 »

  1.   

    另外，sql server 2008确实有存储时的压缩，和备份的压缩功能。而好像没有传输的压缩功能。你的这种情况，应该想办法，尽量减少查询返回的数据量，比如，只返回需要的列和行，否则速度肯定是比较慢的。
      

  2.   

    我一直都不建议我们的开发用select * from tb来查数据，几千万，还查的那么high，慢是一回事，查的时候还要 加载到内存，浪费资源，天天在喊为什么服务器内存占用那么高
      

  3.   


    不加条件，就自动给它加一个top 1000
      

  4.   


    不加条件，就自动给它加一个top 1000
      

  5.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。
      

  6.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。呵呵，确实，老板就是这样的，他不懂这些，只看直观的结果。我查了一下，没有找到2008r2有传输数据，压缩的特性。
      

  7.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。能不能这样，你把结果预先缓存在应用端呢，呵呵，不过这种方案的问题在于，你需要花1G的内存在存放结果。
      

  8.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。呵呵，确实，老板就是这样的，他不懂这些，只看直观的结果。我查了一下，没有找到2008r2有传输数据，压缩的特性。不知最新的2012有没有这样的功能，难道这种做法会有不良的后果？？不然为什么不实现这样的功能？？
    在网上搜了一下，有“HTTP传输中的gzip压缩，即网页压缩”这样的功能。
      

  9.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。呵呵，确实，老板就是这样的，他不懂这些，只看直观的结果。我查了一下，没有找到2008r2有传输数据，压缩的特性。不知最新的2012有没有这样的功能，难道这种做法会有不良的后果？？不然为什么不实现这样的功能？？
    在网上搜了一下，有“HTTP传输中的gzip压缩，即网页压缩”这样的功能。我查了一下2012也没这个功能，只有在数据库镜像中，传送数据库日志的时候，才会压缩。一般的数据，不会压缩，其实1G的数据，我试过压缩一下，估计也就10MB左右，如果真能压缩的话，那就好了。或者是否考虑这样 ，在应用端，安装一个sql sever，把有些数据量大的报表结果，每天晚上日结，放到应用端的数据库中，然后那个老板已查询，由于是本地，速度应该是非常快的。
      

  10.   


    不加条件，就自动给它加一个top 1000
    如果这样做，老板就会了，怎么查半年的数据是1000条，查一年的数据还是1000条？？？
    那时，就有人在问，看有的软件（包括SQL Server）能够一边快速的显示部分记录，一连在接收剩余的记录，这样的功能是怎么实现的。这种，应该先返回一个count(*)的结果，然后说：本次返回的是xxxxxx行里的前1000行
    有些多层机制就是支持多次逐渐返回的，查询分析器似乎不是多层的，但也支持这样
      

  11.   

    是否应该重新考虑一下,一次查询返回1GB数据到客户端,是否真有必要?
    分页都有几百上千页,用户翻页都要翻N久的喔,耐心逐页看完的更少.建议在前端程序中适当做处理,分批返回数据页.
    例如一次查询仅返回10页的数据和总页数,
    10页的数据用于呈现给用户当前翻页所用.
    总页数用于产生显示第11页->第N页的页码.
    当用户翻到第10页时,预先读取11页->20页的数据即可.
      

  12.   

    据我所知MSSQL应该没有这样传输压缩的机制.
    即使真有,客户端CPU/内存不够的话,解压大压缩包,也有一定的负担喔.建议另外考虑解决方法,如空间换时间,将常用的查询统计提前计算好保存为表.
    查询时直接调用即可.