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

以下的文章主要描述的是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.  
  18. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 and id>=11535090 limit 10;  
  19. +———-+—————————–+———————+——+———————-+  
  20. | id | substr(mobile from 1 for 7) | time | cpid | linkid |  
  21. +———-+—————————–+———————+——+———————-+  
  22. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |  
  23. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |  
  24. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |  
  25. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |  
  26. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |  
  27. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |  
  28. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |  
  29. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |  
  30. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |  
  31. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |  
  32. +———-+—————————–+———————+——+———————-+  
  33. 10 rows in set (0.00 sec)  
  34.  
  35. 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;  
  36. +———-+—————————–+———————+——+———————-+  
  37. | id | substr(mobile from 1 for 7) | time | cpid | linkid |  
  38. +———-+—————————–+———————+——+———————-+  
  39. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |  
  40. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |  
  41. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |  
  42. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |  
  43. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |  
  44. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |  
  45. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |  
  46. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |  
  47. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |  
  48. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |  
  49. +———-+—————————–+———————+——+———————-+  
  50. 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数据库会当作普通的连表查询!

【编辑推荐】

  1. 从MySQL数据库表中来检索数据并不难
  2. MySQL数据库访问妙招在Linux之下
  3. MySQL 修改密码的6个好用方案
  4. 配置MySQL与卸载MySQL实操
  5. 备份MySQL数据库脚本的实际应用

文章来源网络,作者:运维,如若转载,请注明出处:https://shuyeidc.com/wp/290934.html<

(0)
运维的头像运维
上一篇2025-05-19 11:08
下一篇 2025-05-19 11:09

相关推荐

  • 个人主题怎么制作?

    制作个人主题是一个将个人风格、兴趣或专业领域转化为视觉化或结构化内容的过程,无论是用于个人博客、作品集、社交媒体账号还是品牌形象,核心都是围绕“个人特色”展开,以下从定位、内容规划、视觉设计、技术实现四个维度,详细拆解制作个人主题的完整流程,明确主题定位:找到个人特色的核心主题定位是所有工作的起点,需要先回答……

    2025-11-20
    0
  • 社群营销管理关键是什么?

    社群营销的核心在于通过建立有温度、有价值、有归属感的社群,实现用户留存、转化和品牌传播,其管理需贯穿“目标定位-内容运营-用户互动-数据驱动-风险控制”全流程,以下从五个维度展开详细说明:明确社群定位与目标社群管理的首要任务是精准定位,需明确社群的核心价值(如行业交流、产品使用指导、兴趣分享等)、目标用户画像……

    2025-11-20
    0
  • 香港公司网站备案需要什么材料?

    香港公司进行网站备案是一个涉及多部门协调、流程相对严谨的过程,尤其需兼顾中国内地与香港两地的监管要求,由于香港公司注册地与中国内地不同,其网站若主要服务内地用户或使用内地服务器,需根据服务器位置、网站内容性质等,选择对应的备案路径(如工信部ICP备案或公安备案),以下从备案主体资格、流程步骤、材料准备、注意事项……

    2025-11-20
    0
  • 如何企业上云推广

    企业上云已成为数字化转型的核心战略,但推广过程中需结合行业特性、企业痛点与市场需求,构建系统性、多维度的推广体系,以下从市场定位、策略设计、执行落地及效果优化四个维度,详细拆解企业上云推广的实践路径,精准定位:明确目标企业与核心价值企业上云并非“一刀切”的方案,需先锁定目标客户群体,提炼差异化价值主张,客户分层……

    2025-11-20
    0
  • PS设计搜索框的实用技巧有哪些?

    在PS中设计一个美观且功能性的搜索框需要结合创意构思、视觉设计和用户体验考量,以下从设计思路、制作步骤、细节优化及交互预览等方面详细说明,帮助打造符合需求的搜索框,设计前的规划明确使用场景:根据网站或APP的整体风格确定搜索框的调性,例如极简风适合细线条和纯色,科技感适合渐变和发光效果,电商类则可能需要突出搜索……

    2025-11-20
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注