order by 列加索引

最新推荐文章于 2024-11-11 21:29:49 发布
原创 最新推荐文章于 2024-11-11 21:29:49 发布 · 954 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文通过一个具体的SQL查询案例，展示了如何通过创建索引来显著提高查询效率。对比了使用全表扫描与索引范围扫描的不同执行计划及性能差异。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >


create table t_order_tb 
as
select * from dba_objects ; 
select * from t_order_tb t where t.object_id > 2 ;
select * from t_order_tb t where t.object_id > 2 order by t.object_id;
create index ind_order_object_id on t_order_tb(object_id) ;
select * from t_order_tb t where t.object_id > 2 order by t.object_id;
select t.object_id from t_order_tb t where t.object_id > 2 order by t.object_id;



SQL> set autotrace traceonly;
SQL> select * from t_order_tb t where t.object_id > 2 ;

已选择50628行。

已用时间:  00: 00: 02.25

执行计划
----------------------------------------------------------
Plan hash value: 2653850918

--------------------------------------------------------------------------------
| Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |            | 41858 |  7235K|   162   (3)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| T_ORDER_TB | 41858 |  7235K|   162   (3)| 00:00:02 |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."OBJECT_ID">2)

Note
-----
   - dynamic sampling used for this statement


统计信息
----------------------------------------------------------
          4  recursive calls
          0  db block gets
       4080  consistent gets
        399  physical reads
          0  redo size
    2453530  bytes sent via SQL*Net to client
      37510  bytes received via SQL*Net from client
       3377  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      50628  rows processed

SQL>
SQL> select * from t_order_tb t where t.object_id > 2 order by t.object_id;

已选择50628行。

已用时间:  00: 00: 01.50

执行计划
----------------------------------------------------------
Plan hash value: 3469110092

-----------------------------------------------------------------------------------------
| Id  | Operation          | Name       | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |            | 41858 |  7235K|       |  1793   (1)| 00:00:22 |
|   1 |  SORT ORDER BY     |            | 41858 |  7235K|    16M|  1793   (1)| 00:00:22 |
|*  2 |   TABLE ACCESS FULL| T_ORDER_TB | 41858 |  7235K|       |   162   (3)| 00:00:02 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("T"."OBJECT_ID">2)

Note
-----
   - dynamic sampling used for this statement


统计信息
----------------------------------------------------------
          4  recursive calls
          0  db block gets
        758  consistent gets
          0  physical reads
          0  redo size
    2447912  bytes sent via SQL*Net to client
      37510  bytes received via SQL*Net from client
       3377  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      50628  rows processed

SQL> select * from t_order_tb t where t.object_id > 2 order by t.object_id;

已选择50628行。

已用时间:  00: 00: 01.68

执行计划
----------------------------------------------------------
Plan hash value: 780952064

---------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                     | 41858 |  7235K|   876   (1)| 00:00:11 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T_ORDER_TB          | 41858 |  7235K|   876   (1)| 00:00:11 |
|*  2 |   INDEX RANGE SCAN          | IND_ORDER_OBJECT_ID | 41858 |       |   126   (2)| 00:00:02 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T"."OBJECT_ID">2)
       filter("T"."OBJECT_ID">2)

Note
-----
   - dynamic sampling used for this statement


统计信息
----------------------------------------------------------
          9  recursive calls
          0  db block gets
       7609  consistent gets
        112  physical reads
          0  redo size
    5439440  bytes sent via SQL*Net to client
      37510  bytes received via SQL*Net from client
       3377  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      50628  rows processed

SQL>
SQL> select t.object_id from t_order_tb t where t.object_id > 2 order by t.object_id;

已选择50628行。

已用时间:  00: 00: 00.48

执行计划
----------------------------------------------------------
Plan hash value: 957369183

----------------------------------------------------------------------------------------
| Id  | Operation        | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                     | 41858 |   531K|   126   (2)| 00:00:02 |
|*  1 |  INDEX RANGE SCAN| IND_ORDER_OBJECT_ID | 41858 |   531K|   126   (2)| 00:00:02 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T"."OBJECT_ID">2)
       filter("T"."OBJECT_ID">2)

Note
-----
   - dynamic sampling used for this statement


统计信息
----------------------------------------------------------
          7  recursive calls
          0  db block gets
       3546  consistent gets
          0  physical reads
          0  redo size
     732819  bytes sent via SQL*Net to client
      37510  bytes received via SQL*Net from client
       3377  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      50628  rows processed

mysql怎么添加索引
计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。
11-17 614
mysql 添加索引 mysql 如何创建索引,添加primary key(主键索引) alter table 表名 add primary key(列名);.mysql怎么添加索引sql语句 工具：mysql数据库创建一个user的表里边的字段 1.普通索引添加INDEX ALTERTABLE`table_name`ADD...
PG -模糊查询-json字段索引
shine
09-02 2007
pg有json字段的索引，可以用Gin做类似全文索引 查询sql: SELECT * FROM test WHERE "content" @> '{"domain":"www.sina1.com"}' ORDER BY "content" DESC LIMIT 1; 以上由于内部机制不加排序会不触发gin索引，所以要加排序； 原先不加Limit，不走索引: 首先表里面有99w行记录...
Mysql ORDER BY是否走索引？
Gemini1995的博客
07-10 1370
在 MySQL 中，`ORDER BY` 子句是否使用索引取决于多种因素，包括查询的具体情况、索引的类型和结构、查询中的其他条件等。
order by与索引
水墨江南
07-20 220
ORDER BY 通常会有两种实现方法，一个是利用有序索引自动实现，也就是说利用有序索引的有序性就不再另做排序操作了。另一个是把结果选好之后再排序。 用有序索引这种，当然是最快的，不过有一些限制条件，来看下面的测试。   测试数据：student表有两个字段id ,sid ,id是主键。一共有20W条记录，id从1到200000,sid也是从1到200000的数据。   第...
Order by与索引
满脑子灵感的专栏
02-20 1438
可是，由于上面的表的数据是有序的，所以排序花费的时间较少。另外排序操作一般都是在内存里进行的，对于数据库来说是一种CPU的消耗，由于现在CPU的性能增强，对 于普通的几十条或上百条记录排序对系统的影响也不会很大。当执行处理数据（order by）时，数据库会先查看第一步的执行计划，看order by 的字段是否在执行计划中利用了索引。当order by 中的字段出现在where条件中时，才会利用索引而不排序，更准确的说，order by 中的字段在执行计划中利用了索引时，不用排序操作。
添加索引列_Order by之索引优化
weixin_30952319的博客
01-16 1592
▼更多精彩推荐，请关注我们▼ 通常我们会选择在合适的谓词条件列添加索引，以达到加速查询的效果。今天给大家介绍下以orderby列创建索引加速查询的例子，话不多说，往下看。 首先我们利用dba_objects创建一个测试表如下：create table test as select * from dba_objects;--执行多次插入，让数据量达到千万级别insert into...
MySQL之索引(3)（索引基本语法、SQL执行计划、常见索引失效原因与解决方法）
岁岁岁平安的博客
11-11 1446
本篇博客主要内容是关于MySQL中索引的创建、查找、删除的基本语法，MySQL中的SQL执行计划的概念与作用（关键字：explain）以及MySQL中的常见索引失效原因与解决方法......
MySQL索引是如何提高查询效率的呢？
Happy Simon
03-25 2922
About MySQL MySQL（读作/maɪ ˈsiːkwəl/“My Sequel”）是一个开放源码的关系数据库管理系统，原开发者为瑞典的MySQL AB公司，目前为Oracle旗下产品。 被甲骨文公司收购后，自由软件社群们对于Oracle是否还会持续支持MySQL社群版（MySQL之中唯一的免费版本）有所隐忧，因此MySQL的创始人麦克尔·维德纽斯以MySQL为基础，成立分支计划Maria...
大批量数据查询优化--建立索引
青涩记忆
08-13 1497
查询操作在数据库的操作中所占的比重非常大，所以查询优化技术非常重要。 要不要建索引,首先要看你的数据量如何,如果数据量不大,就没有必要建立索引了,因为作用不大,还增加了索引的维护工作。 另外所谓根据select语句建立索引，就是对你经常查询的列来建立索引，如果你建立了一个索引，可是在你的select语句中很少用到这个索引，那就没有必要了。 具体方法是看你的select语句中的whe
一个容易被忽略的SQL调优技巧 --- order by字段到底要不要加入索引
热门推荐
1
06-16 1万+
对于SQL调优，要调就调到极致，小编并不是处女座，而是因为在一个并发量很大的业务系统中，对于频繁执行的单条SQL性能的提升，可能对整体数据库的性能提升都有很大的意义。 但是遇到order by字段后面的字段，特别是当这个字段不在过滤条件中时，小编就会心里打鼓，是加到索引里面呢，还是不加到索引里面呢，加进去会不会没有起到提升性能的作用，反而让索引变得更加复杂，给系统带来不必要的额外负担，“偷鸡不成蚀把米”，开个玩笑。但是如果直接忽略掉这个问题，很可能这个提升系统性能的机会就被错过了。 所以今天小编就和大家探讨
MySQL--索引Order By优化、Group By优化
吴声子夜歌的博客
11-26 1018
索引Order By优化 建表及准备数据： CREATE TABLE tblA( id INT PRIMARY KEY AUTO_INCREMENT, age INT, birth TIMESTAMP NOT NULL ); INSERT INTO tblA(age,birth) VALUES(22,NOW()); INSERT INTO tblA(age,birth) VALUES(23,NO...
关于ORDER BY字段是否增加索引
tzzt01的博客
07-14 5661
在MySQL中，支持两种排序方式：FileSort和Index排序。Index排序的效率更高。 Index排序：索引可以保证数据的有序性，因此不需要再进行排序。 FileSort排序：一般在内存中进行排序，占用CPU较多。如果待排结果较大，会产生临时文件I/O到磁盘进行排序，效率较低。 所以使用ORDER BY子句时，应该尽量使用Index排序，避免使用FileSort排序。 当然具体优化器是否采用索引进行排序，你可以使用 explain 来进行执行计划的查看。 优化建议： SQL中，可以在WHERE子句
mysql order by索引分析
乐乐的博客
10-09 2585
这里主要讨论一下InnoDB B-Tree索引的使用，不提设计，只管使用。B-Tree索引主要作用于WHERE和ORDER BY子句。这里讨论的均在MySQL-Server-5.7.23测试 CREATE TABLE `friends` ( `ID` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `uid`bigint(20) UNSIGNED NOT NU...
基于包含order by 排序列的sql构建索引index一点小测试--part1
04-26 180
1,某客户数据库系统发现如下SQL select M.BEGIN_DATE, M.SERV_ID, M.EXPIRE...
order by怎么使用索引
qq_39338079的博客
07-26 4784
Order by 字段加在索引何处
生活是一种态度
03-02 2151
Order by字段有时看到SQL SERVER给出的索引中会加在索引的Include里面，我则比较喜欢加在条件字段的尾部，今日测试对比了一下。              有一个查询语句如下：              SELECT TOP 5 id,name,BizOfferTypeId,TradingServiceType FROM [table]  WITH (NOLOCK)
mysql时间列加索引效率
最新发布
01-03
### MySQL 中对时间列添加索引的影响 对于 `time` 列或其他日期时间类型的字段，在 MySQL 数据库中创建索引可以显著提高涉及这些列的查询性能。当表中的记录数量较大时，未加索引的时间列可能导致全表扫描操作，这会消耗大量资源并降低读取速度。 通过为时间戳或日期类型的数据建立 B-Tree 索引，MySQL 能够更高效地处理基于范围的选择条件以及精确匹配的情况。例如，如果经常执行类似于 `SELECT * FROM table WHERE date_column BETWEEN 'start_date' AND 'end_date';` 的语句，则应该考虑在此类列上构建索引以加快响应时间[^1]。 然而需要注意的是，并不是所有的场景下都适合给时间列加上索引： - 如果该列为频繁更新的对象（如每次插入新行都会更改当前时间），那么维护额外的索引结构可能会带来写入开销； - 对于非常小规模的数据集来说，增加索引可能不会明显改善性能反而增加了存储成本； 为了验证具体应用环境中索引的效果，可以通过对比有无索引状态下相同 SQL 查询所花费的时间来进行评估。下面是一个简单的测试脚本用于测量带索引与不带索引两种情况下 SELECT 语句的速度差异: ```sql -- 创建测试用临时表, 并填充一些随机数据 CREATE TEMPORARY TABLE test_time_index ( id INT AUTO_INCREMENT PRIMARY KEY, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO test_time_index (created_at) VALUES ('2023-01'),...,('2024-01-01'); -- 插入多条记录... -- 测量没有索引时查询耗时 SET @noindex_start=NOW(); SELECT COUNT(*) FROM test_time_index WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY); SET @noindex_end=NOW(); -- 给 created_at 字段添加索引 ALTER TABLE test_time_index ADD INDEX idx_created_at(created_at); -- 再次测量带有索引后的查询耗时 SET @withindex_start=NOW(); SELECT COUNT(*) FROM test_time_index WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY); SET @withindex_end=NOW(); -- 输出结果比较两者之间的区别 SELECT TIMESTAMPDIFF(MICROSECOND,@noindex_start ,@noindex_end ) AS noIndexTime , TIMESTAMPDIFF(MICROSECOND,@withindex_start ,@withindex_end )AS withIndexTime; ``` 上述代码片段展示了如何在一个小型实验里模拟不同条件下同一查询的表现变化情况。实际生产环境下的影响因素更多样化，因此建议依据具体的业务逻辑来决定是否有必要实施此类优化措施[^2].
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值