常见的几种分页方式:
1.扶梯方式
扶梯方式在导航上通常只提供上一页/下一页这两种模式,部分产品甚至不提供上一页功能,只提供一种“更多/more”的方式,也有下拉自动加载更多的方式,在技术上都可以归纳成扶梯方式。
扶梯方式在技术实现上比较简单及高效,根据当前页最后一条的偏移往后获取一页即可。写成SQL可能类似
SELECT*FROMLIST_TABLEWHEREid> offset_id LIMIT n;
1.电梯方式
另外一种数据获取方式在产品上体现成精确的翻页方式,如1,2,3……n,同时在导航上也可以由用户输入直达n页。国内大部分场景采用电梯方式,但电梯方式在技术实现上相对成本较高。
在MySQL中,通常提到的b-tree,在存储引擎实现上,通常都是b+tree。
使用电梯方式时候,当用户指定翻到第n页时候,并没有直接方法寻址到该位置,而是需要从第一楼逐个count,scan到count*page时候,获取数据才真正开始,所以导致效率不高。
传统分页技术(电梯方式)
首先前端需要传给你的分页实体,以及查询条件
//分页实体 structFinanceDcPage{ 1:i32 pageSize,//页容量 2:i32 pageIndex,//当前页索引 }
然后你需要返回查询总条数给前端;
SELECTCOUNT(*)FROMmy_tableWHEREx= y ORDERBYid;
然后再返回指定页面条数给前端:
SELECT*FROMmy_tableWHEREx= y ORDERBYdate_colLIMIT (pageIndex - 1)* pageSize, pageSize;
由上面两条sql语句查询出来的结果需要返回给前端的分页实体,以及单页结果集
//分页实体 structFinanceDcPage{ 1:i32 pageSize,//页容量 2:i32 pageIndex,//当前页索引 3:i32 pageTotal,//总页数 4:i32 totalRecod,//总条数 }
传统查询方法,每次请求变化的只有pageIndex值,也就是limit offset,num的offset
如limit 0,10; limit 10,10; …. limit10000,10;
上面的变化会导致每次查询所执行的时间会有偏差,offset值越大需要的时间越长,如limit10000,10 需要读取10010个数据才能得到想要的10条数据。
优化方法
传统方法中我们了解到,影响效率的关键是程序遍历了许多不需要的数据,找到了关键点那么就从这里着手。
如果没有必须使用电梯方式的时候,我们可以使用扶梯的方式,来提高性能。
但是大多数情况,电梯形式更能满足用户的需求,所以我们就需要另找方法来优化电梯形式。
基于传统方式的优化
上面提到的优化方式,要么难以满足用户的需求,要么实现起来过于复杂,所以如果数据量不是特别大的时候,像百来万条数据,其实根本没有必要使用上面的优化方法。
传统方法已经足够用了,只不过传统方法也可能需要优化的地方。例如:
orderby优化
SELECT*FROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5
这条语句中使用了ORDERBY关键字,那么对什么进行排序又非常重要了,如果你是对自增id进行排序的话,那么这条语句就不需要优化了,如果是索引甚至非索引的话,那就需要优化了。
首先你要保证它是索引,不然真的会很慢。然后如果他是索引,但是本身不像自增id那样有序的话,那么就要改写成下面的语句。
SELECT*FROMpa_dc_flowINNERJOIN(SELECTidFROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5)ASpa_dc_flow_idUSING(id);
下面是对两条sql的 EXPLAIN
由图中我们可以看出,第二个sql可以少扫面很多页面。
其实这涉及到order by的优化问题,第一条sql中并没有利用到subject_code索引。如果你改为select subject_code …则用到了索引。下面是对order by的优化。
order by后的字段,如果要走索引,须与where 条件里的某字段建立复合索引!!或者说orcerby后的字段如果要走索引排序,它要么与where条件里的字段建立复合索引【这里建立复合索引的时候,需要注意复合索引的列顺序为(where字段,order by字段),这样才能满足最左列原则,原因可能是order by字段并能算在where 查询条件中!】,要么它自身要在where条件里被引用到!
表asubject_code为普通字段,上面建有索引,id是自增主键
select*fromaorderbysubject_code//用不上索引 selectidfromaorderbysubject_code//能用上索引 selectsubject_codefromaorderbysubject_code//能用上索引 select*fromawheresubject_code= XX orderbysubject_code//能用上索引
意思是说order by 要避免使用文件系统排序,要么把order by的字段出现在select后,要么使用order by字段出现在where 条件里,要么把order by字段与where条件字段建立复合索引!
第二条sql就是巧妙的利用第二种方式利用上了索引。 select id from a order bysubject_code,这种方式
count优化
当数据量非常大时,其实可以输出总数的大概数据,利用explain语句,他并没有真正去执行sql,而是进行的估算。
总结
以上所述是小编给大家介绍的mysql分页性能探索,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对网站的支持!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]