Sidecar 目前还没有成熟的产品，但是从架构上来说它的性能应该介于 SDK 和 Proxy 之间，并且也没有单体故障、集群管理等烦恼。
面试准备
还需要弄清楚几个问题：
- 公司是如何解决分库分表中的分页问题的？
- 有没有因为排序或分页而引起的性能问题？最终怎么解决的
还可以去看看公司的监控数据，注意下分页查询的响应时间。并且在业务高峰期或是频繁执行分页的时候，看看内存和CPU的使用率。这些数据可以作为分页查询比较引起性能问题的证据。
面试策略上来说，最好把分页查询优化作为你性能优化的一个举措，可以进一步和前面的查询优化、数据库参数优化相结合，这样方案会更完善，能力会更全面。
如果面试官问到了数据库性能优化和数据库分页查询，你都可以尝试把话题引导到分页查询上。
基本思路
可以尝试介绍一下是如何优化数据库性能的，比如SQL本身优化、数据库优化，然后罗列出准备的SQL案例，说明你在SQL优化方面做过哪些事情，比如优化过分库分表的查询，其中最典型的就是优化分页查询。
假设之前是全局查询，现在采用禁用跨页查询的方案来优化
最开始我在公司监控慢查询的时候，发现有一个分页查询非常慢。这个分页查询是按照更新时间降序来排序的。后来我发现那个分页查询用的是全局查询法，因为这个接口原本是提供给 Web 端用的，而 Web 端要支持跨页查询，所以只能使用全局查询法。当查询的页数靠后的时候，响应时间就非常长。 后来我们公司搞出 App 之后，类似的场景直接复用了这个接口。但是事实上在 App 上是没有跨页需求的。所以我就直接写了一个新接口，这个接口要求分页的时候带上上一页的最后一条数据的更新时间。也就是我用这个更新时间构造了一个查询条件，只查询早于这个时间的数据。那么分页查询的时候 OFFSET 就永远被我控制在 0 了，查询的时间就非常稳定了。
最后你可以加一个总结。
分页查询在分库分表里面是一个很难处理的问题，要么查询可能有性能问题，比如说这里使用的全局查询法，要么就是要求业务折中，比如说我优化后禁用了跨页，以及要求数据平均分布的平均分页法，当然还有各方面都不错，但是实现比较复杂的二次查询法、中间表法。
