关于分页
是一次性把数据取出来，在客户端控制显示好呢，还是每次就取出来几条显示好。求大神降临 
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
是一次性把数据取出来，在客户端控制显示好呢，还是每次就取出来几条显示好。求大神降临
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（10）
引用来自#3楼“三阶魔方”的帖子
分页是一个比较细节的问题。
我通常都是在数据库中只取出用户需要的记录，显示给用户。
但是，在计算总页数的时候，我必须要知道总记录数，为此我通常会添加一个表示记录数的列，然后用两个trigger去自动更新该列的值，在insert时记录数加1，在delete时记录数减1。
这种方式屡试不爽。我们需要在数据库设计范式与性能之间取得一个平衡。虽然这个表示记录数的列有些没必要，但它确实大大提高了性能，不需要对整个表进行select count(id)了。
引用来自#6楼“蒙塔基的钢蛋”的帖子
引用来自#3楼“三阶魔方”的帖子
分页是一个比较细节的问题。
我通常都是在数据库中只取出用户需要的记录，显示给用户。
但是，在计算总页数的时候，我必须要知道总记录数，为此我通常会添加一个表示记录数的列，然后用两个trigger去自动更新该列的值，在insert时记录数加1，在delete时记录数减1。
这种方式屡试不爽。我们需要在数据库设计范式与性能之间取得一个平衡。虽然这个表示记录数的列有些没必要，但它确实大大提高了性能，不需要对整个表进行select count(id)了。
条件查询的时候，我是只能想到 老老实实的查询数据库，展现结果
和真的需要的时候，将特定查询条件的结果作缓存输出
还有更好的办法吗？
引用来自#2楼“红薯”的帖子
这个要看数据量了，如果100条（或者更少）以内，我觉得可以在客户端处理
超过100条当然要在服务器处理，否则如果有1万、10万甚至更多的数据，根本在客户端处理不过来的。
但综合来看，不如统一在服务器端处理，简单方便而且统一。
分页这个问题确实很麻烦的
不同的数据库 不同的应用场景 不同的框架用起来都要注意
不会有银弹
见过有兄弟说DZ论坛，貌似是回帖时直接将主题回帖数字段+1，对这种场景就很适合
引用来自#3楼“三阶魔方”的帖子
分页是一个比较细节的问题。
我通常都是在数据库中只取出用户需要的记录，显示给用户。
但是，在计算总页数的时候，我必须要知道总记录数，为此我通常会添加一个表示记录数的列，然后用两个trigger去自动更新该列的值，在insert时记录数加1，在delete时记录数减1。
这种方式屡试不爽。我们需要在数据库设计范式与性能之间取得一个平衡。虽然这个表示记录数的列有些没必要，但它确实大大提高了性能，不需要对整个表进行select count(id)了。
引用来自#4楼“Jumkey”的帖子
我觉得select count(*)效率更高
我觉得select count(*)效率更高
分页是一个比较细节的问题。
我通常都是在数据库中只取出用户需要的记录，显示给用户。
但是，在计算总页数的时候，我必须要知道总记录数，为此我通常会添加一个表示记录数的列，然后用两个trigger去自动更新该列的值，在insert时记录数加1，在delete时记录数减1。
这种方式屡试不爽。我们需要在数据库设计范式与性能之间取得一个平衡。虽然这个表示记录数的列有些没必要，但它确实大大提高了性能，不需要对整个表进行select count(id)了。
这个要看数据量了，如果100条（或者更少）以内，我觉得可以在客户端处理
超过100条当然要在服务器处理，否则如果有1万、10万甚至更多的数据，根本在客户端处理不过来的。
但综合来看，不如统一在服务器端处理，简单方便而且统一。