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