应用在本地运行以及部署在服务器上，查询接口的耗时差距太大

[liuyuay]

数据库是MySQL，用了ShardingJDBC进行分表，ORM框架用的是MyBatis-plus
数据库是在另一个服务器上，不是在部署应用的服务器中。
分页数据大小是每页500条，在本地运行，查询第一页和第19页，响应速度差距不大。
但是在服务器中运行，查询第一页和第19也，响应速度差了2秒多
本地-第一页

本地-第十九页

部署服务器中-第一页

部署服务器中-第十九页


实在是想了半天也没有想出来是什么问题，望各位大牛告知。

[viewgroup]

在进行io 的开销哪里进行输出耗时操作，，看一下查询数据库用了多久 剩下的时间就全部是http的开销了，，看看是不是http的问题

[再写三行]

加上mybatis缓存

[liuyuay]

引用 1 楼 viewgroup 的回复:

在进行io 的开销哪里进行输出耗时操作，，看一下查询数据库用了多久 剩下的时间就全部是http的开销了，，看看是不是http的问题

不是http的问题，这个我测试了

[乀(ˉεˉ乀)]

mysql分页查询越到后面消耗的时间就会越长，你可以把sql单独拿出来去数据库试试。另外条件加上索引

[一只三黄鸡]

我看到你的数据size>2M 网络传输和你服务器带宽有关，如果假设你的服务器带宽是5M，那么你可以达到的下载速率就是500K/s，但是实际上是大于500K/s的，假设数据是2M来计算，估算就是2*1024/500 大约为4s，所以楼主你说的只是正常现象 关乎第1页和第19页，可能与sql语句有关，在数据量不大的时候，可以忽略不计

[liuyuay]

引用 6 楼 一只三黄鸡 的回复:

我看到你的数据size>2M 网络传输和你服务器带宽有关，如果假设你的服务器带宽是5M，那么你可以达到的下载速率就是500K/s，但是实际上是大于500K/s的，假设数据是2M来计算，估算就是2*1024/500 大约为4s，所以楼主你说的只是正常现象 关乎第1页和第19页，可能与sql语句有关，在数据量不大的时候，可以忽略不计

好像不是带宽问题，因为第一页的数据和第19页的数据，大小也没差多少，可是他们速度却相了那么多，并且我有在查询前后打印了当前时间，我计算了一下，确实是查询花了那么久时间，实际传输到本地仅花了200多毫秒时间。

[一只三黄鸡]

引用 7 楼 liuyuay 的回复:

[quote=引用 6 楼 一只三黄鸡 的回复:]我看到你的数据size>2M 网络传输和你服务器带宽有关，如果假设你的服务器带宽是5M，那么你可以达到的下载速率就是500K/s，但是实际上是大于500K/s的，假设数据是2M来计算，估算就是2*1024/500 大约为4s，所以楼主你说的只是正常现象 关乎第1页和第19页，可能与sql语句有关，在数据量不大的时候，可以忽略不计

好像不是带宽问题，因为第一页的数据和第19页的数据，大小也没差多少，可是他们速度却相了那么多，并且我有在查询前后打印了当前时间，我计算了一下，确实是查询花了那么久时间，实际传输到本地仅花了200多毫秒时间。[/quote] 但是既然你说连的是 另外一个服务器上的数据库，理论上不可能，难道后台服务器连接数据库服务器的网络延时？不确定了

[liuyuay]

引用 4 楼 乀(ˉεˉ乀) 的回复:

mysql分页查询越到后面消耗的时间就会越长，你可以把sql单独拿出来去数据库试试。另外条件加上索引

时间越来越长我知道，但是我在本地运行的话，第一页和第19页，仅仅相差差不多300多毫秒而已，如果放到服务器上，第一页和第19页，相差了3秒多，这就让我很疑惑，查的数据库是同一个数据库，在另一个服务器。

[liuyuay]

引用 10 楼 nayi_224 的回复:

执行查询前后打印时间发出来，再把分页相关的代码发出来

时间就是差了那么多，不是带宽慢占用的时间，分页用的MyBatis-plus的分页插件，查询的时候是 limit

[liuyuay]

引用 12 楼 冰思雨 的回复:

像楼主的这种情况，如果频繁进行第十九页查询的时候，时间依然还是大于3秒。那么，只有一种可能了。 本地的查询命中了索引，远程服务器的查询，没有命中索引。 楼主去看看关联表的索引，肯定是本地服务器的索引和服务器上的索引有所差别，从而，使得服务器未命中索引，导致全表查询，耗时较大。

查19页很多次，还是一样的速度，暂时还没创建索引

[nayi_224]

引用 13 楼 liuyuay 的回复:

[quote=引用 10 楼 nayi_224 的回复:]执行查询前后打印时间发出来，再把分页相关的代码发出来

时间就是差了那么多，不是带宽慢占用的时间，分页用的MyBatis-plus的分页插件，查询的时候是 limit[/quote] 查询相关的代码发出来

[luj_1768]

看看系统为你的数据提供了多大的系统缓存池，缓存池足够大的话，速度是一样的，否则，第一页快很多。

[nayi_224]

执行查询前后打印时间发出来，再把分页相关的代码发出来

[冰思雨]

数据库对查询是有缓存的， 楼主的第一页查询，经常做，所以，已经被缓存了，所以，响应速度要快。 第十九页的查询结果，因为没有缓存，所以，查询速度要慢。因为，分页查询要动硬盘，所以，速度要慢。 楼主可以多查询几次第十九页的内容，然后，在看看响应速度。频繁查询的结果，如果SQL语句没有变化的话，查询结果会自动被数据库缓存。 当然，被缓存的结果集，是数据量比较小的，数据量太大的结果集，数据库是不会缓存的。 另外，查询超过3秒，说明，没有针对查询做优化，比如建立索引。因为，常用的索引数据，也会被数据库自动缓存，第一页用了索引，那么，很可能第二页的索引也会被缓存起来，那么，查询完第一页之后，查询第二次的时候，会直接用到缓存的索引，从而提速。但是，第十九页的索引，有可能因为索引数据量的大小不会在查询第一页的时候载入到内存当中，但是，一般来讲，只要你经过一次查询后，索引和结果集都有可能被缓存，关键看数据库的缓存策略。

[冰思雨]

像楼主的这种情况，如果频繁进行第十九页查询的时候，时间依然还是大于3秒。那么，只有一种可能了。 本地的查询命中了索引，远程服务器的查询，没有命中索引。 楼主去看看关联表的索引，肯定是本地服务器的索引和服务器上的索引有所差别，从而，使得服务器未命中索引，导致全表查询，耗时较大。

[冰思雨]

引用 14 楼 liuyuay 的回复:

[quote=引用 12 楼 冰思雨 的回复:]像楼主的这种情况，如果频繁进行第十九页查询的时候，时间依然还是大于3秒。那么，只有一种可能了。 本地的查询命中了索引，远程服务器的查询，没有命中索引。 楼主去看看关联表的索引，肯定是本地服务器的索引和服务器上的索引有所差别，从而，使得服务器未命中索引，导致全表查询，耗时较大。

查19页很多次，还是一样的速度，暂时还没创建索引[/quote] 没创建索引，查询当然会慢了。 服务器上的数据库，查询一定要命中索引才行的。 服务器上的数据库，表里面的数据量非常大，没有索引，查询速度巨慢。 本地数据库，一般只是开发测试使用，数据量小的可怜。

[liuyuay]

引用 16 楼 冰思雨 的回复:

[quote=引用 14 楼 liuyuay 的回复:][quote=引用 12 楼 冰思雨 的回复:]像楼主的这种情况，如果频繁进行第十九页查询的时候，时间依然还是大于3秒。那么，只有一种可能了。 本地的查询命中了索引，远程服务器的查询，没有命中索引。 楼主去看看关联表的索引，肯定是本地服务器的索引和服务器上的索引有所差别，从而，使得服务器未命中索引，导致全表查询，耗时较大。

查19页很多次，还是一样的速度，暂时还没创建索引[/quote] 没创建索引，查询当然会慢了。 服务器上的数据库，查询一定要命中索引才行的。 服务器上的数据库，表里面的数据量非常大，没有索引，查询速度巨慢。 本地数据库，一般只是开发测试使用，数据量小的可怜。[/quote] 查的是同一个数据库，在另一台服务器上，不在部署应用的服务器。 没索引，但我在本地查询很快。 分表了，用的ShardingJDBC，我猜可能是ShardingJDBC有怎么样的处理要占用系统资源，比如CPU啥的，所以我本地跑得更快

[liuyuay]

引用 16 楼 冰思雨 的回复:

[quote=引用 14 楼 liuyuay 的回复:][quote=引用 12 楼 冰思雨 的回复:]像楼主的这种情况，如果频繁进行第十九页查询的时候，时间依然还是大于3秒。那么，只有一种可能了。 本地的查询命中了索引，远程服务器的查询，没有命中索引。 楼主去看看关联表的索引，肯定是本地服务器的索引和服务器上的索引有所差别，从而，使得服务器未命中索引，导致全表查询，耗时较大。

查19页很多次，还是一样的速度，暂时还没创建索引[/quote] 没创建索引，查询当然会慢了。 服务器上的数据库，查询一定要命中索引才行的。 服务器上的数据库，表里面的数据量非常大，没有索引，查询速度巨慢。 本地数据库，一般只是开发测试使用，数据量小的可怜。[/quote] 如图为ShardingJDBC官网简介，ShardingJDBC以客户端方式运行 所以他运行的效率是跟运行环境的硬件配置有关系的。 我用我电脑创建了一个虚拟机，将应用部署在那上面，如图是测试结果 可以看到，跟我电脑本地运行时的查询速度相比，仅差了200多毫秒。