安科网

Oracle不使用索引的几种情况列举

tangjin

tangjin

2017-01-21

关注 关注

本文介绍了几种不使用索引的情况，本文实验的Oracle数据库版本均为11.2.0.4
情况1：

我们在使用一个B*树索引，而且谓词中没有使用索引的最前列。
如果这种情况，可以假设有一个表T，在T(x,y)上有一个索引。要做以下查询：select * from t where y=5。此时，优化器就不打算使用T(x,y)上的索引，因为谓词中不涉及X列。在这种情况下，倘若使用索引，可能就必须查看每个索引条目，而优化器通常更倾向于对T表做一个全表扫描。

zx@ORCL>create table t as select rownum x,rownum+1 y,rownum+2 z from dual connect by level < 100000;
 
Table created.
 
zx@ORCL>select count(*) from t;
 
  COUNT(*)
----------
    99999
 
zx@ORCL>create index idx_t on t(x,y);
 
Index created.
 
zx@ORCL>exec dbms_stats.gather_table_stats(user,'T',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>set autotrace traceonly explain
--where条件使用y=5
zx@ORCL>select * from t where y=5;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
 
--------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |    1 |    15 |    80  (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |    1 |    15 |    80  (2)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  1 - filter("Y"=5)
--where条件使用x=5
zx@ORCL>select * from t where x=5;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1594971208
 
-------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT            |      |    1 |    15 |    3  (0)| 00:00:01 |
|  1 |  TABLE ACCESS BY INDEX ROWID| T    |    1 |    15 |    3  (0)| 00:00:01 |
|*  2 |  INDEX RANGE SCAN          | IDX_T |    1 |      |    2  (0)| 00:00:01 |
-------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - access("X"=5)

但这并不完全排除使用索引。如果查询是select x,y from t where y=5，优化器就会注意到，它不必全面扫描表来得到X或Y(x和y都在索引中)，对索引本身做一个民快速的全面扫描会更合适，因为这个索引一般比底层表小得多。还要注意，仅CBO能使用这个访问路径。
zx@ORCL>select x,y from t where y=5;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2497555198
 
------------------------------------------------------------------------------
| Id  | Operation            | Name  | Rows  | Bytes | Cost (%CPU)| Time    |
------------------------------------------------------------------------------
|  0 | SELECT STATEMENT    |      |    1 |    10 |    81  (2)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| IDX_T |    1 |    10 |    81  (2)| 00:00:01 |
------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  1 - filter("Y"=5)

另一种情况下CBO也会使用T(x,y)上的索引，这就是索引跳跃式扫描。当且仅当索引的最前列(在上面的例子中最前列是x)只有很少的几个不同值，而且优化器了解这一点，跳跃式扫描(skip scan)就能很好地发挥作用。例如，考虑(GEMDER,EMPNO)上的一个索引，其中GENDER可取值有M和F，而且EMPNO是唯一的。对于以下查询:
select * from t where empno=5;
可以考虑使用T上的那个索引采用跳跃式扫描方法来满足这个查询，这说明从概念上讲这个查询会如下处理：
select * from t where GENDER='M' and empno=5
union all
select * from t where GENDER='F' and empno=5
它会跳跃式地扫描索引，以为这是两个索引：一个对应值M，另一个对应值F。
zx@ORCL>create table t1 as select decode(mod(rownum,2),0,'M','F') gender,all_objects.* from all_objects;
 
Table created.
 
zx@ORCL>create index idx_t1 on t1(gender,object_id);
 
Index created.
 
zx@ORCL>exec dbms_stats.gather_table_stats(user,'T1',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>set autotrace traceonly explain
zx@ORCL>select * from t1 where object_id=42;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4072187533
 
-------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT            |      |    1 |  100 |    4  (0)| 00:00:01 |
|  1 |  TABLE ACCESS BY INDEX ROWID| T1    |    1 |  100 |    4  (0)| 00:00:01 |
|*  2 |  INDEX SKIP SCAN          | IDX_T1 |    1 |      |    3  (0)| 00:00:01 |
-------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - access("OBJECT_ID"=42)
      filter("OBJECT_ID"=42)

INDEX SKIP SCAN 步骤告诉Oralce要跳跃式扫描这个索引，查询GENDER值有改变的地方，并从那里开始向下读树，然后在所考虑的各个虚拟索引中查询OBJECT_id=42。如果大幅增加GENDER的可取值，如下：
zx@ORCL>alter table t1 modify GENDER varchar2(2);
 
Table altered.
 
zx@ORCL>update t1 set gender=(chr(mod(rownum,1024)));
 
84656 rows updated.
 
zx@ORCL>commit;
 
Commit complete.
 
zx@ORCL>exec dbms_stats.gather_table_stats(user,'T1',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>set autotrace traceonly explain
zx@ORCL>select * from t1 where object_id=42;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
 
--------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |    1 |  101 |  344  (1)| 00:00:05 |
|*  1 |  TABLE ACCESS FULL| T1  |    1 |  101 |  344  (1)| 00:00:05 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  1 - filter("OBJECT_ID"=42)

情况2：

在使用select count(*) from t查询(或类似的查询)，而且在表T上有一个B*树索引。不过，优化器并不是统计索引条目，而是在全面扫描这个表(尽管索引比表要小)。在这种情况下，索引可能建立在一个允许有NULL值的列上。由于对于索引键完全为null的行不会建立相应的索引条目，所以索引中的行数可能并不是表中的行数。这里优化器的选择是对的，如若不然，倘若它使用索引来统计行数，则可能会得到一个错误的答案。

zx@ORCL>desc t;
 Name                                                                                                  Null?    Type
 ----------------------------------------------------------------------------------------------------- -------- --------------------------------------------------------------------
 X                                                                                                              NUMBER
 Y                                                                                                              NUMBER
 Z                                                                                                              CHAR(23)
zx@ORCL>select count(*) from t;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
 
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time    |
-------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |    1 |  153  (1)| 00:00:02 |
|  1 |  SORT AGGREGATE    |      |    1 |            |          |
|  2 |  TABLE ACCESS FULL| T    | 99999 |  153  (1)| 00:00:02 |
-------------------------------------------------------------------
 
zx@ORCL>alter table t modify y not null;
 
Table altered.
 
zx@ORCL>desc t
 Name                                                                                                  Null?    Type
 ----------------------------------------------------------------------------------------------------- -------- --------------------------------------------------------------------
 X                                                                                                              NUMBER
 Y                                                                                                    NOT NULL NUMBER
 Z                                                                                                              CHAR(23)
 
zx@ORCL>select count(*) from t;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2371838348
 
-----------------------------------------------------------------------
| Id  | Operation            | Name  | Rows  | Cost (%CPU)| Time    |
-----------------------------------------------------------------------
|  0 | SELECT STATEMENT      |      |    1 |    80  (0)| 00:00:01 |
|  1 |  SORT AGGREGATE      |      |    1 |            |          |
|  2 |  INDEX FAST FULL SCAN| IDX_T | 99999 |    80  (0)| 00:00:01 |
-----------------------------------------------------------------------

情况3：
对于一个有索引的列，做以下查询：
select * from t where function(indexed_column)=value;
却发现没有使用indexed_colum上的索引。原因是这个列上使用了函数。如果是对indexed_column的值建立了索引，而不是对function(indexed_column)的值建索引。在此不能使用这个索引。如果愿意，可以另外对函数建立索引。
zx@ORCL>select * from t where mod(x,999)=1;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
 
--------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |  1000 | 34000 |  153  (1)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| T    |  1000 | 34000 |  153  (1)| 00:00:02 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  1 - filter(MOD("X",999)=1)
 
zx@ORCL>create index idx_t_f on t(mod(x,999));
 
Index created.
 
zx@ORCL>exec dbms_stats.gather_table_stats(USER,'T',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>select * from t where mod(x,999)=1;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4125918735
 
---------------------------------------------------------------------------------------
| Id  | Operation                  | Name    | Rows  | Bytes | Cost (%CPU)| Time    |
---------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT            |        |  100 |  3800 |  102  (0)| 00:00:02 |
|  1 |  TABLE ACCESS BY INDEX ROWID| T      |  100 |  3800 |  102  (0)| 00:00:02 |
|*  2 |  INDEX RANGE SCAN          | IDX_T_F |  100 |      |    1  (0)| 00:00:01 |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - access(MOD("X",999)=1)

情况4：
考虑以下情况，已经对一个字符钱建立了索引。这个列只包含数据数据。如果使用以下语法来查询：
select * from t where indexed_colum=5;
注意查询中的数字5是常数5(而不是一个字符串)，此时就没有使用INDEXED_COLUMN上的索引。这是因为，前面的查询等价于以下查询：
select * from t where to_number(indexed_column)=5;
我们对这个列隐式地应用了一个函数，如情况3所述，这就会禁止使用这个索引。
zx@ORCL>create table t2 (x char(1) constraint t2_pk primary key ,y date);
 
Table created.
 
zx@ORCL>insert into t2 values('5',sysdate);
 
1 row created.
 
zx@ORCL>commit;
 
Commit complete.
 
zx@ORCL>exec dbms_stats.gather_table_stats(USER,'T2',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>explain plan for select * from t2 where x=5;
 
Explained.
 
zx@ORCL>select * from table(dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1513984157
 
--------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |    1 |    12 |    3  (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T2  |    1 |    12 |    3  (0)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  1 - filter(TO_NUMBER("X")=5)
 
Note
-----
  - dynamic sampling used for this statement (level=2)

可以看到，它会全面扫描表；另外即使我们对查询给出了以下提示：
zx@ORCL>explain plan for select /*+ index(t2 t2_pk) */ * from t2 where x=5;
 
Explained.
 
zx@ORCL>select * from table(dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3365102699
 
-------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT            |      |    1 |    10 |    2  (0)| 00:00:01 |
|  1 |  TABLE ACCESS BY INDEX ROWID| T2    |    1 |    10 |    2  (0)| 00:00:01 |
|*  2 |  INDEX FULL SCAN          | T2_PK |    1 |      |    1  (0)| 00:00:01 |
-------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - filter(TO_NUMBER("X")=5)

在此使用了索引，但是并不像我们想像中那样对索引完成唯一扫描(UNIQUE SCAN)，而是完成了全面扫描(FULL SCAN)。原因从最后一行输出可以看出:filter(TO_NUMBER("X")=5)。这里对这个数据库列应用了一个隐式函数。X中存储的字符串必须转换为一个数字，之后才能与值5进行比较。在此无法把5转换为一个串，因为我们的NLS(国家语言支持)设置会控制5转换成串时的具体形式(而这是不确定的，不同的NLS设置会有不同的控制)，所以应当把串转为数据。而这样一样(由于应用也函数)，就无法使用索引来快速地查找这一行了。如果只是执行串与串的比较：
zx@ORCL>explain plan for select * from t2 where x='5';
 
Explained.
 
zx@ORCL>select * from table(dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3897349516
 
-------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT            |      |    1 |    12 |    1  (0)| 00:00:01 |
|  1 |  TABLE ACCESS BY INDEX ROWID| T2    |    1 |    12 |    1  (0)| 00:00:01 |
|*  2 |  INDEX UNIQUE SCAN        | T2_PK |    1 |      |    1  (0)| 00:00:01 |
-------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - access("X"='5')
 
14 rows selected.

不出所料，这会得到我们期望的INDEX UNIQUE SCAN,而且可以看到这里没有应用函数。一定要尽可能地避免隐式转换。
还经常出现一个关于日期的问题，如果做以下查询：
select * from t where trunc(date_col)=trunc(sysdate);
而且发现这个查询没有使用DATE_COL上的索引，为了解决这个问题，可以对trunc(date_col)建立索引，或者使用区间比较运算符来查询(也许这是更容易的做法)。下面来看对日期使用大于或小于运算符的一个例子。可以认识到以下条件：
trunc(date_col)=trunc(sysdate)
与下面的条件是一样的：
date_col>= trunc(sysdate) and date_col<trunc(sysdate+1)
如果可能的话，倘若谓词中有函数，尽量不要对数据库列应用这些函数。这样做不仅可以使用更多的索引，还能减少处理数据库所需的工作。使用转换的条件查询时只会计算一次TRUNC值，然后就能使用索引来查找满足条件的值。使用trunc(date_col)=trunc(sysdate)时，trunc(date_col)则必须对整个表(而不是索引)中的每一行计算一次。
情况5：
另一种情况，如果使用了索引，实际上反而会更慢。Oracle(对于CBO而言)只会在合理地时候才使用索引。
zx@ORCL>create table t3 (x,y null,primary key (x) ) as select rownum x,object_name y from all_objects;
 
Table created.
 
zx@ORCL>exec dbms_stats.gather_table_stats(USER,'T3',cascade=>true);
 
PL/SQL procedure successfully completed.
 
zx@ORCL>set autotrace traceonly explain 
--运行一个查询查询相对较少的数据
zx@ORCL>select count(y) from t3 where x<50;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1961899233
 
----------------------------------------------------------------------------------
| Id  | Operation        | Name        | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |              |    1 |    5 |    2  (0)| 00:00:01 |
|  1 |  SORT AGGREGATE  |              |    1 |    5 |            |          |
|*  2 |  INDEX RANGE SCAN| SYS_C0017451 |    49 |  245 |    2  (0)| 00:00:01 |
----------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - access("X"<50)
--运行一个查询查询相对较多的数据
zx@ORCL>select count(y) from t3 where x<50000;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 463314188
 
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time    |
---------------------------------------------------------------------------
|  0 | SELECT STATEMENT  |      |    1 |    30 |  117  (1)| 00:00:02 |
|  1 |  SORT AGGREGATE    |      |    1 |    30 |            |          |
|*  2 |  TABLE ACCESS FULL| T3  | 50000 |  1464K|  117  (1)| 00:00:02 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  2 - filter("X"<50000)

这个例子显示出优化器不一定会使用索引，而且实际上，它会做出正确的选择。对查询调优时，如果发现你认为本该使用的某个索引实际上并没有用到，就不要冒然强制使用这个索引，而应该先做个测试，并证明使用这个索引后确实会加快速度(通过耗用时间和I/O次数来评判)，然后再考虑让CBO就范(强制它使用这个索引)。总得先给出个理由吧。
情况6：
有一段时间没有分析表了。这些表起先很小，但等到查看时，它们已经增长得非常大。现在索引就有很有意义(尽管原先并非如此)。如果此时分析这个表，就会使用索引。
如果没有正确的统计信息，CBO将无法做出正确的决定。
以上介绍了6种不使用索引的情况，归根结底原因通常就是“不能使用索引，使用索引会返回不正确的结果”，或者“不应该使用，如果使用了索引，性能会变得很糟糕”。


参考:
MOS文档：Diagnosing Why a Query is Not Using an Index (文档 ID 67522.1)

索引 select oracle oracle数据库 oracle索引

tangjin

tangjin

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

mysql 14 覆盖索引+回表

MySQL可以利用索引返回select列表中的字段值。而不必根据主键再次读取聚簇索引数据文件查到数据，也就是平时所说的不需要回表操作。覆盖索引其实是索引覆盖的意思，索引字段就已经囊括select查询的字段，即索引字段覆盖了需查询的字段。t; 即id是聚集索

Accpcjg 2020-08-02

sql优化的几种方式

= 或 <> 操作符不会使用索引，而对于 < 、 <= 、 = 、 > 、 >= 、 BETWEEN AND，数据库才会使用索引。因此对于上面的查询，正确写法应该是：select name from table wher

明月清风精进不止 2020-07-05

SQL语句优化的理解

然后是某一条SQL 语句一直执行的很慢，可能的原因有没有用到索引，例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引，或者是数据库选错了索引。这种情况是我们要关心的，需要进行SQL语句的优化，简单来说就是该用索引就要用索引，避免全表扫描。

URML 2020-07-04

oracle数据库关于索引建立及使用的详细介绍

索引是与表相关的一个可选结构，在逻辑上和物理上都独立于表的数据，索引能优化查询，不能优化DML操作，Oracle自动维护索引，频繁的DML操作反而会引起大量的索引维护。如果该语句同时还要访问除索引列之外的列，那么，数据库会使用rowid来查找表中的行。通常

罗罗 2020-08-16

疑问？ Oracle普通的B树索引是升序还是降序？

Oracle普通的B树索引是升序还是降序？SQL> create table a as select * from dba_objects;SQL> select object_name from a where object_id in or

talkingDB 2020-07-05

索引分裂：90-10分裂

数据库的索引基于B-树的结构，通过将数据插入到对应的叶子节点中实现数据新增的功能。更新值的操作是通过"删除"原有的值并在对应的叶子节点上添加修改后的值来实现的。举个例子，假设现在有一个索引键，并且假设一个数据块只能容纳该索引的4个索引值

oraclemch 2020-07-30

MySQL数据类型优化原则

MySQL支持的数据类型很多，选择正确的数据类型对于高性能至关重要。下面几个简单的原则都有助于做出更好的选择。应该尽量使用可以正确储存数据的最小数据类型。如果无法确定哪个数据类型时最好的，就选择你认为不会超过范围的最小类型。比如用MySQ内建的类型而不是使

ribavnu 2020-11-16

MySql索引使用策略分析

(建立索引会占用磁盘空间的索引文件。2.很少数据的列也不应该建立索引,比如 一个性别字段 0或者1,在查询中,结果集的数据占了表中数据行的比例比较大,mysql需要扫描的行数很多,增加索引,并不能提高效率

moyekongling 2020-11-13

python如何获得list或numpy数组中最大元素对应的索引

#表示最大值在第二行第二列

sizhixht 2020-11-16

Python实现列表索引批量删除的5种方法

开头，如果不仔细看好像没什么问题。但是结果却是错误的。将 listObj.remove() 改为listObj.pop结果也是相同的。Java用同样的编程思想，得到的结果也有相似性。这种错误，主要是初学者对于数据存储原理没有理解清楚，或者，没有意识到内存存

坚持是一种品质 2020-11-16

MyISAM与InnoDB索引实现对比详解

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。这里设表一共有三列，假设我们以Col1为主键，则上图是一个MyISAM表的主索引示意。虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然

chenjiazhu 2020-09-29

万能Python的秘诀：操纵数据的内置工具

本文转载自公众号“读芯术”。Python可谓是如今最流行的编程语言，甚至孩子们也可以从它开始学习趣味编程。Python类似英语的简单语法使它成为一种通用语言，已在全世界各个领域被广泛使用。Python的万能之处正在于其内置的数据结构，它使编码变得简单，不受

kikaylee 2020-10-31

Uber为什么放弃Postgres选择迁移到MySQL？

Uber 的早期架构包含了一个用 Python 开发的单体后端应用程序，这个应用程序使用 Postgres 作为数据存储。从那个时候开始，Uber 的架构已经发生了巨大变化，变成了微服务，并采用新的数据平台模型。具体地说，之前使用 Postgres 的地方

Ida 2020-09-16

导致MySQL索引失效的一些常见写法总结

最近一直忙着处理原来老项目遗留的一些SQL优化问题，由于当初表的设计以及字段设计的问题，随着业务的增长，出现了大量的慢SQL，导致MySQL的CPU资源飙升，基于此，给大家简单分享下这些比较使用的易于学习和使用的经验。这次的话简单说下如何防止你的索引失效。

liuweiq 2020-09-09

MySQL索引的各种类型

索引是数据库存储引擎用于快速查找到指定数据的一种数据结构。可以用新华字典做类比：如果新华字典中对每个字的详细解释是数据库中表的记录，那么按部首或拼音等排序的目录就是索引，使用它可以让我们快速查找的某一个字详细解释的位置。在MySQL中，存储引擎也是用了类似

silencehgt 2020-09-07

MySQL 数据库如何解决高并发问题

我们都知道初创公司一开始都是以单体应用为首要架构，一般都是单体单库的形式。但是版本以及版本的迭代，数据库需要承受更多的高并发已经成了 架构设计 需要考虑的点。高并发的情况下，可以将多个请求的查询合在一次进行，以减少对数据库的访问速度。我们都知道，只要数据库

sunnyxuebuhui 2020-09-07

MySQL 千万级数据量如何快速分页

后端开发中为了防止一次性加载太多数据导致内存、磁盘IO都开销过大，经常需要分页展示，这个时候就需要用到MySQL的LIMIT关键字。但你以为LIMIT分页就万事大吉了么，Too young,too simple啊，LIMIT在数据量大的时候极可能造成的一个

西瓜皮儿的皮儿 2020-09-07

MongoDB通配符索引的用法实例

MongoDB在4.2 版本推出了Wildcard Indexes，究竟什么是Wildcard Indexes以及Wildcard Indexes适合哪些场景本文结合官方文档以及实际测试进行简单概述。因为MongoDB是dynamic schemas，所以

LuckyLXG 2020-09-08

django 对接elasticsearch实现全文检索

# python manage.py rebuild_index #数据库有多少条数据，全部会被同步到es中。object = BookSerializer # 只读,不可以进行反序列化。fields = # text 由索引类进行返回, object

明瞳 2020-08-19

msyql索引篇

官方介绍索引是帮助MySQL高效获取数据的数据结构。更通俗的说，数据库索引好比是一本书前面的目录，能加快数据库的查询速度。我们通常所说的索引，包括聚集索引、覆盖索引、组合索引、前缀索引、唯一索引等，没有特别说明，默认都是使用B+树结构组织的索引。可以提高数

MissFuTT 2020-08-18
tangjin

tangjin

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号