IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

一条SQL引发的对order by的思考

五四陈科学院-坚信科学,分享技术 2010-07-06 23:26:30 累计浏览 3,248 次
本机暂存

    在实际工作中遇到下面一个问题:

    有一个表,存有2000万数据。

    主键为ID bigint(20) NOT NULL auto_increment

    另有一字段time timestamp NOT NULL default CURRENT_TIMESTAMP

    故事从这两个字段说起:

    sql1需要从这个表中检索出来时间为2010-05-26 11:55:00之前并且id号大于20000的前10条数据

    sql2需要从这个表中检索出来时间为2010-05-26 11:55:00之后并且id号大于20000的前10条数据

    两条sql写出来大概是这样子的:

    sql1:select * from table where time 20000 order by id limit 10;

    sql2:select * from table where time >’2010-05-26 11:55:00′ and id>20000 order by id limit 10;

    并且已经知道表中的数据,在上面所示时间之前的数据要远远多于所示时间之后的数据。如图1所示:

    54chen

    图1 数据在时间线上的示意图

    实测发现,sql1执行时间0.03s,sql2执行时间33s。

    为何大于小于运行的速度相比如何巨大?下面来解答。

    第一,用explain来观察两条sql的区别

    结论:没什么区别

    第二,研究order by

    将sql2的order by id修改为order by id desc(排序方向颠倒)后,发现速度马上提到了0.03s的水平。

    同样修改sql1的时候,速度马上降到了30s的水平。

    进行多次测试,排除mysql本身的缓存干扰。

    结论:

    sql1的运行示意图如图2所示:

    54chen

    图2 第一条SQL语句快慢解释图

    sql2的运行示意图如图3所示:

    54chen

    图2 第二条SQL语句快慢解释图

    综合上面两个图,mySQL在where查询的时候,也许按照where的条件,按照主键的顺序,最后满足条件的,最后进到内存中去,再进行后面的order by时,asc如果在内存中比不在内存中的就要快得多。

    未研究真正实现的代码,仅凭感觉验证。

    一句话概括是:按照使用的索引,最后满足条件的数据将留在内存里供进一步排序。

同分类推荐文章

  1. 使用deepseek进行Oracle恢复,引起重大故障 (2026-06-22 10:56:00)
  2. 接手一个只差临门一脚的数据库恢复 (2026-06-18 00:13:09)
  3. 我做了一个 AI 版的 StarRocks 升级风险扫描工具,直接帮我定位到一个风险 (2026-06-15 01:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. MySQL数据库在实际应用一些方面的介绍 (累计阅读 36,399)
  2. 由浅入深探究mysql索引结构原理、性能分析与优化 (累计阅读 16,523)
  3. 如何查找消耗资源较大的SQL (累计阅读 15,211)
  4. 浅谈MySQL索引背后的数据结构及算法 (累计阅读 11,907)
  5. 浅谈TCP优化 (累计阅读 11,082)
  6. 其实,文件也可以truncate (累计阅读 8,574)
  7. MariaDB常见问题FAQ (累计阅读 8,345)
  8. 搜索引擎的特殊用法 (累计阅读 8,122)
  9. SQL vs NoSQL:数据库并发写入性能比拼 (累计阅读 8,003)
  10. Mysql的随机读取 (累计阅读 7,864)