vue-element-admin中table分页原理：根据currentPage与pageSize去后台精准查询，返回匹配的结果，然后前台currentPage与pageSize变化时，再去后台获取相应的结果值。这样的优点：前台存储的资源少，压力小。缺点：后端不断接收请求的次数多。
我优化了一下，不能说优化，改造了一下，增加了另一种分页机制，后台全部获取数据，前台通过computed得到table要展示的data。这种优点：当currentPage与pageSize变化时，不会去后台请求数据，前台根据vue的特性，数据双向绑定，computed中自动计算应该展示的data。
改造内容：
1、原mock.js中filter部分，即下面这句话去掉。
//const pageList = mockList.filter((item, index) => index < limit * page && index >= limit * (page - 1))//这种只把请求页返给前台
2、前台vue部分处理，computed增加currentPageList()，在这个方法中将1中的计算逻辑加入
currentPageList() {
var limitC = this.listQuery.limit
var pageC = this.listQuery.page
console.log("computed currentPageList this.list", this.list);
if (this.list == null || this.list == undefined) {
console.log("enter computed currentPageList()，但是还没有数据created（），等待。。。");
return null;
}
return this.list.filter((item, index) => index < limitC * pageC && index >= limitC * (pageC - 1))
}
3、前台vue部分 table绑定改为
:data="currentPageList"
4、增加新的分页模版paginationNoRequestBack'
import Pagination from '@/components/paginationNoRequestBack'
paginationNoRequestBack这个模版与pagination大同小异，只是将里面的this.$emit('pagination')去掉了。
5、前台vue部分 模版pagination调用里面去掉@pagination事件。
目前项目中就存在了两种分页请求方式，在以后的使用中根据各自的优缺点，选取最优的方式即可。
当然新加的这种方式也可称作‘假分页’。
真分页 和 假分页，真分页是不会去取所有数据的，假分页虽然也达到了分页效果，数据量少还好说，在未来数据量大的时候，接口性能就降低了。所以还是看具体的业务场景。
“真分页”显然是效率更高,面对庞大的数据量也能够从容自若,但是缺点便是每次都需要和后台交互。“假分页”不需要和后台交互,但是一旦面对大数据量时,加载将十分缓慢,影响用户的体验。
因此个人认为数据量不是很大时，可以考虑使用假分页，这种只与数据库请求一次。
补充点分页SQL原理，参考：https://www.cnblogs.com/sunliyuan/p/5804355.html