mysql游标场景_数据库游标的应用场景

我们大部分数据库在查询完成后返回给客户端的基本上都是以一个游标的方式，游标到底是一个什么东西呢，下面是我对它的理解：

我们把数据库服务端叫A，客户端叫B，B有一天突然想查询关于台风的相关新闻，于是就产生了以下的对话：

B开始拨打A的电话，电话接通了。

B问A：喂，A，我要查询关于台风的相关新闻！

A回答：稍等，我去查一查。

过了一会儿。

A响应了:喂，B，我查到数据了，你还在吗？

B回答道：还在的，那你说一条，我记一条，你先发第一条给我。

A：第一条：xxxx

B:下一条。

。。。。。。此处省略若干字

B：再下一条。

A：没有了。

然后B挂断了电话。

其实这个过程中，我们能看到B是一条一条向A要数据，但这里的B是可以取一条先用笔记着，但如果B想做数据分析，也可以取一条数据去做数据分析，然后分析完去取下一条数据，所以这里的处理方式如果应用的好其实可以很好的节约这个电话费。

所以我们的客户端每次在查询到数据后其实是快速将数据取到客户端的缓存然后再展示出来。其实每次客户端查询到的结果都是一个游标，由于客户端屏蔽了这一层，用户是无感知的。

但有一个场景，比如B要查询一个分页，先查第一页，取完断开电话，开始去处理第一页的数据，其实第一页的数据也是游标取出来的，然后B处理数据这期间，A可能开始去处理其他事了，这个时候B处理完了，B以相同的条件要来查第二页，对于A来说，可能有点印象(缓存)能马上查到，如果没印象(缓存)了又的从头开始找，然后跳过第一页的数据，去找第二页，返回游标给B。

在我们实际的开发当中，分页是无可避免的，因为这个动作取决于用户是否去查下一页。

但是在某些特殊的场景，比如某个定时任务，要查某个表，这个表的数据可能很多，至少上百万，对于B来说没办法把这些数据一下全部缓存到B的本地，但如果分页去查询，又会导致A可能要重复的去查询这个结果集，还得去根据分页路由到新一页的第一行，这时A岂不是做了很多重复的操作，性能是不是就会很差，那这个时候就可以由B发起查询，直接根据游标一条一条的取过来，甚至可以取到一批数据后，立马异步让其他人C给他处理一下，他继续取下面的数据，当新的一批数据取到以后，说不定C这群人已经把上一批数据给处理完了，继续处理这新的一批数据。这样是不是可以节约数据库的性能，又成功的避免了数据库分页带来offset的性能影响。