分页优化一例

ndb引擎 每次都要orderby来保持顺序

user_id是索引列

原始的代码

SELECT

sc_user_id            userId,

sc_user_nm            userName,

sc_user_sex           userSex,

sc_user_real_name     userRealName,

sc_mobile_no          mobileNo,

email              email,

scL_register_dts       registerDts,

scL_account_balance    accountBalance,

scL_recharge_amt       rechargeAmt,

scL_invest_amt         investAmt,

scX_redemption_amt     redemptionAmt,

scx_freeze_amt         freezeAmt,

scx_freeze_amtf       withdrawAmt,

create_dtss         createDts,

update_dtstime         updateDts

FROM tbL_custdserv_7user

WHERE update_dtstime >= CONCAT(‘20141021‘,‘000000‘)

ORDER BY sc_user_nm

LIMIT 35950,50;

执行时间 7.45秒

========================================================================

优化后代码

SELECT

a.sc_user_id            userId,

a.sc_user_nm            userName,

a.sc_user_sex           userSex,

a.sc_user_real_name     userRealName,

a.sc_mobile_no          mobileNo,

a.email              email,

a.scL_register_dts       registerDts,

a.scL_account_balance    accountBalance,

a.scL_recharge_amt       rechargeAmt,

a.scL_invest_amt         investAmt,

a.scX_redemption_amt     redemptionAmt,

a.scx_freeze_amt         freezeAmt,

a.scx_freeze_amtf       withdrawAmt,

a.create_dtss         createDts,

a.update_dtstime         updateDts

FROM tbL_custdserv_7user a

JOIN

(SELECT

sc_user_id,

sc_user_nm

FROM tbL_custdserv_7user

WHERE update_dtstime >= CONCAT(‘20141021‘,‘000000‘)

ORDER BY sc_user_nm

LIMIT 35950,50) b

ON a.sc_user_id = b.user_id

执行时间 0.2秒

尝试了 on a.sc_user_nm = b.sc_user_nm  失败

时间: 2024-11-09 00:07:43

分页优化一例的相关文章

MySQL分页优化中的“INNER JOIN方式优化分页算法”到底在什么情况下会生效?

本文出处:http://www.cnblogs.com/wy123/p/7003157.html 最近无意间看到一个MySQL分页优化的测试案例,并没有非常具体地说明测试场景的情况下,给出了一种经典的方案,因为现实中很多情况都不是固定不变的,能总结出来通用性的做法或者说是规律,是要考虑非常多的场景的,同时,面对能够达到优化的方式要追究其原因,同样的做法,换了个场景,达不到优化效果的,还要追究其原因.个人对此场景在不用情况表示怀疑,然后自己测试了一把,果然发现一些问题,同时也证实了一些预期的想法.

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.

分页优化+表锁和库存优化+数据库的备份和导入

一.分页优化技术 代码参看: php/classic.php 把50331651记录进行分页,每页显示2条记录,于是我们用传统php编码方式,编写分页代码如下: 上传到/var/www/html下进行测试,结果如下: 如果访问第1页和第4页,返回语句: 使用explain执行计划查询比较靠前的页数,发觉速度很快因为可以使用上索引: 如果访问第4100000页,返回语句: 使用explain分析结果如下: 发觉这时如果分页到了中间的页数,这时我们既需要排序又要分页检索数据的时候,就会出现Using

php+mysql分页优化版

效果图: 1 <table align="center" cellspacing="2"> 2 <?php 3 include('conn/conn2.php'); 4 $pagesize=10; 5 $url=$_SERVER["REQUEST_URI"];//取当前url路径 6 $url=parse_url($url); //查询当前路径所以值 7 $url=$url[path];//查询当前路径path的值 8 9 $n

mysql limit分页优化方法分享

MySQL的优化是非常重要的.其他最常用也最需要优化的就是limit.MySQL的limit给分页带来了极大的方便,但数据量一大的时候,limit的性能就急剧下降. 同样是取10条数据 select * from yanxue8_visit limit 10000,10 和 select * from yanxue8_visit limit 0,10 就不是一个数量级别的. 网上也很多关于limit的五条优化准则,都是翻译自MySQL手册,虽然正确但不实用.今天发现一篇文章写了些关于limit优

MYSQL 分页慢加速器 解决方案 MYSQL 分页优化 MYSQL 分页解决方案 LIMIT 优化

无论你是InnoD引擎LIMIT分页慢还是MyISAM引擎LIMIT分页慢,大伙SELECT查询分页一般都是这样的[数据总共2万条,需要查询3个字段]: SELECT `id` , `url` , `content` FROM `product` WHERE 1 ORDER BY `id` LIMIT 10000 , 100 执行速度是: 45.7秒 哈哈,慢的掉渣吧! 作者LET再次隆重推荐 MySql LIMIT 分页查询加速利器解决方案: http://my.oschina.net/car

java MongoDB分页优化

最近项目在做网站用户数据新访客统计,数据存储在MongoDB中,统计的数据其实也并不是很大,1000W上下,但是公司只配给我4G内存的电脑,让我程序跑起来气喘吁吁...很是疲惫不堪. 最常见的问题莫过于查询MongoDB内存溢出,没办法只能分页查询.这种思想大家可能都会想到,但是如何分页,确实多有门道! 网上用的最多的,也是最常见的分页采用的是skip+limit这种组合方式,这种方式对付小数据倒也可以,但是对付上几百上千万的大数据,却只能望而兴叹... 经过网上各种查找资料,寻师问道的,发现了

Oracle优化——单表分页优化

单表分页优化思路: --创建测试表: SQL> create table t_test as select * from dba_objects; Table created. 如,下面的sql (没有过滤条件,只有排序),要将查询结果分页显示,每页显示10条,如: select * from t_test order by object_id; 例子: 1.分页查询sql语句,如下(通常会采用下面的方法,但是这是错误的分页框架) 语法:select * from (select t.*,row

正确使用索引(sql优化),limit分页优化,执行计划,慢日志查询

查看表相关命令 - 查看表结构   desc 表名- 查看生成表的SQL   show create table 表名- 查看索引   show index from  表名 使用索引和不使用索引 由于索引是专门用于加速搜索而生,所以加上索引之后,查询效率会快到飞起来. # 有索引 mysql> select * from tb1 where name = 'zhangqiye'; +-----+-------------+---------------------+--------------