最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
问答文章1 问答文章501 问答文章1001 问答文章1501 问答文章2001 问答文章2501 问答文章3001 问答文章3501 问答文章4001 问答文章4501 问答文章5001 问答文章5501 问答文章6001 问答文章6501 问答文章7001 问答文章7501 问答文章8001 问答文章8501 问答文章9001 问答文章9501
当前位置: 首页 - 科技 - 知识百科 - 正文

MySQL数据库下limit与join的优化方案

来源:懂视网 责编:小采 时间:2020-11-09 14:05:25
文档

MySQL数据库下limit与join的优化方案

MySQL数据库下limit与join的优化方案:以下的文章主要描述的是MySQL数据库下limit与join的实际优化方案,我们大家都知道其在实际中的应用比例还是占为多数的,如果你对这一技术,心存好奇的话,以下的文章将会揭开它的神秘面纱。 PHP中分页肯定会使用到MySQL的limit,大部分对类似select *
推荐度:
导读MySQL数据库下limit与join的优化方案:以下的文章主要描述的是MySQL数据库下limit与join的实际优化方案,我们大家都知道其在实际中的应用比例还是占为多数的,如果你对这一技术,心存好奇的话,以下的文章将会揭开它的神秘面纱。 PHP中分页肯定会使用到MySQL的limit,大部分对类似select *

以下的文章主要描述的是MySQL数据库下limit与join的实际优化方案,我们大家都知道其在实际中的应用比例还是占为多数的,如果你对这一技术,心存好奇的话,以下的文章将会揭开它的神秘面纱。 PHP中分页肯定会使用到MySQL的limit,大部分对类似select * from ti

以下的文章主要描述的是MySQL数据库下limit与join的实际优化方案,我们大家都知道其在实际中的应用比例还是占为多数的,如果你对这一技术,心存好奇的话,以下的文章将会揭开它的神秘面纱。

PHP中分页肯定会使用到MySQL的limit,大部分对类似”select * from title where uid =** order by id desc limit m,n”很熟悉,也不是全部都能看出里面有什么不对,可是当是在大数据量下操作呢,比如百万类似”select * from title where uid =177 order by id desc limit 1234567,20″就会发现sql执行的时间明显变得很长,为什么呢?

先从MySQL数据库的limit原理说起,使用limit m,n是时候,MySQL先扫描(m+n)条记录,然后从m行开始取n行.比如上面的例子就是先扫描1234587条数据,这样的话sql能快吗?这就要 求我们尽可能的减少m的值,甚至没有m直接limit n这样是sql.

看个例子:

  1. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 limit 888888,10;
  2. +———-+—————————–+———————+——+———————-+
  3. | id | substr(mobile from 1 for 7) | time | cpid | linkid |
  4. +———-+—————————–+———————+——+———————-+
  5. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |
  6. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |
  7. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |
  8. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |
  9. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |
  10. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |
  11. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |
  12. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |
  13. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |
  14. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |
  15. +———-+—————————–+———————+——+———————-+
  16. 10 rows in set (3.84 sec)
  17. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 and id>=11535090 limit 10;
  18. +———-+—————————–+———————+——+———————-+
  19. | id | substr(mobile from 1 for 7) | time | cpid | linkid |
  20. +———-+—————————–+———————+——+———————-+
  21. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |
  22. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |
  23. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |
  24. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |
  25. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |
  26. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |
  27. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |
  28. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |
  29. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |
  30. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |
  31. +———-+—————————–+———————+——+———————-+
  32. 10 rows in set (0.00 sec)
  33. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 and time>=’2010-02-24 21:07:48′ limit 10;
  34. +———-+—————————–+———————+——+———————-+
  35. | id | substr(mobile from 1 for 7) | time | cpid | linkid |
  36. +———-+—————————–+———————+——+———————-+
  37. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |
  38. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |
  39. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |
  40. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |
  41. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |
  42. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |
  43. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |
  44. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |
  45. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |
  46. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |
  47. +———-+—————————–+———————+——+———————-+
  48. 10 rows in set (0.01 sec)

例中数据表id是主键,time也建了索引,表中总数据约为240w行,其中cpid为769的数据量大约为90w条.这里面的id和时间可能会是不连续的.故不能直接得获取id>m这样操作

所以可以显示 “1,2,3,4,5,末页” 或是 “首页,<<100,101,102,103 >>末页”这样,这样可以极大的减少m值!

MySQL里面的join顺便说一句就是,通常有点讲究的是用小表去驱动大表,而由于MySQL join实现的原理就是做循环比如left join就是对左边的数据进行循环去驱动右边的表,比如左边是可能会有m条记录匹配,右边有n条记录那么就是做m次循环,每次扫描n行数据,总扫面行数是 m*n行数据.左边返回的结果集的大小就决定了循环的次数,故单纯的用小表去驱动大表不一定的正确的。

小表的结果集可能也大于大表的结果集,所以写 join的时候尽可能的先估计两张表的可能结果集,用小结果集去驱动大结果集.值得注意的是在使用left/right join的时候,从表的条件应写在on之后,主表应写在where之后.否则MySQL数据库会当作普通的连表查询!

声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文档

MySQL数据库下limit与join的优化方案

MySQL数据库下limit与join的优化方案:以下的文章主要描述的是MySQL数据库下limit与join的实际优化方案,我们大家都知道其在实际中的应用比例还是占为多数的,如果你对这一技术,心存好奇的话,以下的文章将会揭开它的神秘面纱。 PHP中分页肯定会使用到MySQL的limit,大部分对类似select *
推荐度:
标签: 数据库 mysql 以下
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top