其实这篇博文写不写都一样，主要还是跟着前面数据库封装来的。算是一种数据库查询的优化升级吧。
前面封装了多种类型数据库，用了开源的数据库来组合需要的方案，任你选取。我通过组个项目一步步实现封装。最后把它整理成服务化的处理。给出了客户端请求，服务端回复的模式。还定义了请求结构，回复结构以及UDP分包组包还有序列化，还有方便替换的模型。以及自定义的连接池。基本包含完了数据库的操作，还可以通过连接池提供多个数据库访问。剩下一个优化了，我先写这篇博文，再升级源码。
我们在优化速度方面，其实遵循的就一个原则，空间换取时间。所以在数据库程序服务化也同样使用。这里的原理就是作为服务，那么有很多客户端使用，客户端就有可能查询相同数据，把这些数据缓存下来，就提升了程序速度，缓存在内存或者本地数据库或者本地文件中，然后给一个方案进行删除，如果是缓存内存中，就采用LRU的缓存模型。
对于自己的缓存怎么做，简单。直接比较SQL语句，SQL语句相同，数据库相同，那么认为数据相同（这个是一段时间的，例如你的表在实时更新，你缓存了，当然拿不到最新的）。在你的业务允许的范围或者时间内，这当然提升速度。
基于上面的优化，那我们的分页就更加能够优化了，基本原理同上。但是还有差别。
（1）客户端写整个分页语句，就如同基本的SQL语句查询，那么就是最基本的优化原理和查询了。
（2）服务端模板化。这个意思是你写一个分页的语句模板，在客户端请求时，SQL语句直接写出模板名称，分页页码，然后在服务端替换模板。这里就有意思了，这里其实有2个优化地方。1.上面的基本优化原理。2.构造分页缓存。按照模板名称，模板页码缓存数据，同时查询完成后立即在服务端缓存下一页。这样服务端给你缓存好下一页，必然要快。只不过需要增加功能，来删除缓存的数据（一般就是最后一次使用的时间，或者缓存的分页个数等等，合理的删除需要根据业务设置。
（3）客户端模板化。这个主要针对服务端在使用以后，不能增加或者不方便增加时使用，和服务端模板化一样的效果。
其实数据库查询服务化以后，有一个隐藏的优化。很多数据库都会缓存一定时间的数据载内存中，本身的原理我不清楚，但是估计更加优秀，是数据库根据SQL语句解析，一步一步缓存的。服务端采用连接不移除，本身在数据库层面机会缓存，同时编译了解析了SQL语句，数据库本身也会快。
差不多就这样一点。我会增加分页缓存的设计结构以及SQL语句规整，主要是空格个数。但是我不提供完整例子，只实现功能。为大家使用提供思路依据。代码做到借鉴或者直接使用。但是直接能够允许服务我不会提供。
后面还会增加各种优化方案。包括通信层，数据库替换等等，欢迎大家关注项目的git.还是那句话，适合的就是最好的，这些优化有的可能不会替换老的方案，只是放在解决方案中让大家直接使用尝试。
当然你能够直接优化SQL来满足自己业务，这个是最万能的。