精华内容
下载资源
问答
  • 查看oracle指定的表哪些列使用索引

    千次阅读 2017-09-04 12:59:18
    select user_ind_columns.index_name,user_ind_columns.column_name, user_ind_columns.column_position,user_indexes.uniqueness from user_ind_columns,user_indexes ...where user_ind_columns.index_name

    select user_ind_columns.index_name,user_ind_columns.column_name,

    user_ind_columns.column_position,user_indexes.uniqueness

    from user_ind_columns,user_indexes

    where user_ind_columns.index_name = user_indexes.index_name

    and user_ind_columns.table_name = '你的表明';
    展开全文
  • 一、深入浅出理解索引结构  实际上,您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引: 聚集索引(clustered index,也称聚类索引、簇集索引)和 非聚集索引(nonclustered index,...

    一、深入浅出理解索引结构 

    实际上,您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引:

    聚集索引(clustered index,也称聚类索引、簇集索引)和

    非聚集索引(nonclustered index,也称非聚类索引、非簇集索引)。

    下面,我们举例来说明一下聚集索引和非聚集索引的区别: 
      其实,我们的汉语字典的正文本身就是一个聚集索引。比如,我们要查“安”字,就会很自然地翻开字典的前几页,

    为“安”的拼音是“an”,而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的,那么“安”字就自然地排在

    字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字,那么就说明您的字典中没有这个字;同样的,如

    查“张”字,那您也会将您的字典翻到最后部分,因为“张”的拼音是“zhang”。也就是说,字典的正文部分本身就是一

    个目录,您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录

    称为“聚集索引”。也就是说该索引中的键值的逻辑决定了表中相应行的物理顺序。

      如果您认识某个字,您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字,不知道它的发音,这时候

    ,您就不能按照刚才的方法找到您要查的字,而需要去根据“偏旁部首”查到您要找的字,然后根据这个字后的页码直接翻

    到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法,比如您查“张

    ”字,我们可以看到在查部首之后的检字表中“张”的页码是672页,检字表中“张”的上面是“驰”字,但页码却是63页,“张”

    的下面是“弩”字,页面是390页。很显然,这些字并不是真正的分别位于“张”字的上下方,现在您看到的连续的“驰、张、

    ”三字实际上就是他们在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所

    需要的字,但它需要两个过程,先找到目录中的结果,然后再翻到您所需要的页码。我们把这种目录纯粹是目录,正文纯粹是

    正文的排序方式称为“非聚集索引”。该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。 

      通过以上例子,我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下,我们可以很容易的理解:每个表

    只能有一个聚集索引,因为目录只能按照一种方法进行排序。 

       如果用一种通俗的描述就是:索引是通过二叉树的数据结构来描述的。聚簇索引:叶子节点就是数据节点;非聚簇索引:叶

    子节点仍然是索引点,

    只不过有一个指针指向对应数据块。

    簇聚索引图:


    非簇聚索引图:



    下面的表格阐述了什么时候应该用非簇聚索引,什么时候用簇聚索引:

    动作描述 使用聚集索引 使用非聚集索引
    列经常被分组排序
    返回某范围内的数据 不应
    一个或极少不同值 不应 不应
    小数目的不同值 不应
    大数目的不同值 不应
    频繁更新的列 不应
    外键列
    主键列
    频繁修改索引列 不应

      三、结合实际,谈索引使用的误区

    理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引,但在实践中以上规则却很容易被忽视或

    不能根据实际情况进行综合分析。

    下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区,以便于大家掌握索引建立的方法。
    1.主键就是聚集索引:

     这种想法笔者认为是极端错误的,是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。
          通常,我们会在每个表中都建立一个ID列,以区分每条数据,并且这个ID列是自动增大的,步长一般为1。

    我们的这个办公自动化的实例中的列Gid就是如此。此时,如果我们将这个列设为主键,SQL SERVER会将此列默认

    为聚集索引。这样做有好处,就是可以让您的数据在数据库中按照ID进行物理排序,但笔者认为这样做意义不大。

          显而易见,聚集索引的优势是很明显的,而每个表中只能有一个聚集索引的规则,这使得聚集索引变得更加珍贵。
          从我们前面谈到的聚集索引的定义我们可以看出,使用聚集索引的最大好处就是能够根据查询要求,迅速缩小查

    询范围,避免全表扫描。在实际应用中,因为 ID号是自动生成的,我们并不知道每条记录的ID号,所以我们很难在实践

    中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次,让每个ID号都不同的字段作为聚

    集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则;当然,这种情况只是针对用户经常修改记录内容,特别

    是索引项的时候会负作用,但对于查询速度并没有影响。

          在办公自动化系统中,无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数

    据查询都离不开字段的是“日期”还有用户本身的“用户名”。

          通常,办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚

    未签收的情况,但如果您的系统已建立了很长时间,并且数据量很大,那么,每次每个用户打开首页的时候都进行一次全表扫描,

    这样做意义是不大的,绝大多数的用户1个月前的文件都已经浏览过了,这样做只能徒增数据库的开销而已。事实上,我们完全可

    以让用户打开系统首页时,数据库仅仅查询这个用户近3个月来未阅览的文件,通过“日期”这个字段来限制表扫描,提高查询速度。

    如果您的办公自动化系统已经建立的2年,那么您的首页显示速度理论上将是原来速度8倍,甚至更快。

          在这里之所以提到“理论上”三字,是因为如果您的聚集索引还是盲目地建在ID这个主键上时,您的查询速度是没有这么高

    的,即使您在“日期”这个字段上建立的索引(非聚合索引)。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表

    现(3个月内的数据为25万条):

    [html] view plain copy
    1. (1)仅在主键上建立聚集索引,并且不划分时间段:  
    2.   
    3. Select gid,fariqi,neibuyonghu,title from tgongwen  
    4.   
    5. 用时:128470毫秒(即:128秒)  

    [html] view plain copy
    1. (2)在主键上建立聚集索引,在fariq上建立非聚集索引:  
    2.   
    3. select gid,fariqi,neibuyonghu,title from Tgongwen  
    4. where fariqi> dateadd(day,-90,getdate())  
    5.   
    6. 用时:53763毫秒(54秒)  

    [html] view plain copy
    1. (3)将聚合索引建立在日期列(fariqi)上:  
    2.   
    3.     select gid,fariqi,neibuyonghu,title from Tgongwen  
    4.     where fariqi> dateadd(day,-90,getdate())  
    5.   
    6.     用时:2423毫秒(2秒)  

     2、只要建立索引就能显著提高查询速度
          事实上,我们可以发现上面的例子中,第2、3条语句完全相同,且建立索引的字段也相同;不同的仅是前者在fariqi字段

    上建立的是非聚合索引,后者在此字段上建立的是聚合索引,但查询速度却有着天壤之别。所以,并非是在任何字段上简单地建立

    索引就能提高查询速度。
          从建表的语句中,我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再

    合适不过了。在现实中,我们每天都会发几个文件,这几个文件的发文日期就相同,这完全符合建立聚集索引要求的:“既不能绝大

    多数都相同,又不能只有极少数相同”的规则。由此看来,我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。


    3、把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度
          上面已经谈到:在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要,我

    们可以把他们合并起来,建立一个复合索引(compound index)。
          很多人认为只要把任何字段加进聚集索引,就能提高查询速度,也有人感到迷惑:如果把复合的聚集索引字段分开查询,那

    么查询速度会减慢吗?带着这个问题,我们来看一下以下的查询速度(结果集都是25万条数据):(日期列fariqi首先排在复合聚集

    索引的起始列,用户名neibuyonghu排在后列):

    [html] view plain copy
    1. (1)select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5''  
    2.   
    3.     查询速度:2513毫秒  
    [html] view plain copy
    1. (2)select gid,fariqi,neibuyonghu,title from Tgongwen  
    2.                 where fariqi>''2004-5-5'' and neibuyonghu=''办公室''  
    3.   
    4.     查询速度:2516毫秒  
    [html] view plain copy
    1. (3)select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=''办公室''  
    2.   
    3.     查询速度:60280毫秒  

    从以上试验中,我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的,甚至比用上全部的

    复合索引列还要略快(在查询结果集数目一样的情况下);而如果仅用复合聚集索引的非起始列作为查询条件的话,这个索引是不起

    任何作用的。

    然,语句1、2的查询速度一样是因为查询的条目数一样,如果复合索引的所有列都用上,而且查询结果少的话,这样就会形成“索引覆盖”,

    因而性能可以达到最优。同时,请记住:无论您是否经常使用聚合索引的其他列,但其前导列一定要是使用最频繁的列。


     四、其他书上没有的索引使用经验总结

       1、用聚合索引比用不是聚合索引的主键速度快
          下面是实例语句:(都是提取25万条数据)

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''

        使用时间:3326毫秒

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

        使用时间:4470毫秒

        这里,用聚合索引比用不是聚合索引的主键速度快了近1/4。

        2、用聚合索引比用一般的主键作order by时速度快,特别是在小数据量情况下

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

        用时:12936

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

        用时:18843

          这里,用聚合索引比用一般的主键作order by时,速度快了3/10。事实上,如果数据量很小的话,用聚集索引作为排序列

    要比使用非聚集索引速度快得明显的多;而数据量如果很大的话,如10万以上,则二者的速度差别不明显。

        3、使用聚合索引内的时间段,搜索时间会按数据占整个数据表的百分比成比例减少,而无论聚合索引使用了多少个:

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-1-1''

        用时:6343毫秒(提取100万条)

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-6-6''

        用时:3170毫秒(提取50万条)

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''

        用时:3326毫秒(和上句的结果一模一样。如果采集的数量一样,那么用大于号和等于号是一样的)

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen
                    where fariqi>''2004-1-1'' and fariqi<''2004-6-6''

        用时:3280毫秒

        4、日期列不会因为有分秒的输入而减慢查询速度
          下面的例子中,共有100万条数据,2004年1月1日以后的数据有50万条,但只有两个不同的日期,日期精确到日;之前有

    数据50万条,有5000个不同的日期,日期精确到秒。

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen
                  where fariqi>''2004-1-1'' order by fariqi

        用时:6390毫秒

        select gid,fariqi,neibuyonghu,reader,title from Tgongwen
                    where fariqi<''2004-1-1'' order by fariqi

        用时:6453毫秒

        五、其他注意事项

          “水可载舟,亦可覆舟”,索引也一样。索引有助于提高检索性能,但过多或不当的索引也会导致系统低效。因为用户在表中

    每加进一个索引,数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
          所以说,我们要建立一个“适当”的索引体系,特别是对聚合索引的创建,更应精益求精,以使您的数据库能得到高性能的发

    挥。
          当然,在实践中,作为一个尽职的数据库管理员,您还要多测试一些方案,找出哪种方案效率最高、最为有效。

    展开全文
  • 什么样的表和列需要建立索引

    千次阅读 2018-04-08 17:24:20
    添加多列索引的时候,对应的多条件查询可以触发该索引的同时,索引最左侧的列的单条件查询也可以触发。3)如果有些表注定只会进行查询所有,也就没必要添加索引,因为查询全部只能进行全量搜索即扫描全表。...

    数据量大的,经常进行查询操作的表要建立索引

    1)表与表连接用于多表联合查询的约束条件的字段应当建立索引;

    2)用于排序的字段可以添加索引,用于分组的字段应当视情况看是否需要添加索引。添加多列索引的时候,对应的多条件查询可以触发该索引的同时,索引最左侧的列的单条件查询也可以触发。

    3)如果有些表注定只会进行查询所有,也就没必要添加索引,因为查询全部只能进行全量搜索即扫描全表。

    展开全文
  • 外键上是否需要索引

    千次阅读 2018-07-05 21:07:45
    外键上是否需要索引 其实这个问题应该算是老生常谈了。这两天看concept看到这里,于是就在说说这个问题。 外键上缺少索引会带来两个问题,限制并发性、影响性能。而这两个问题中的任意一个都可能会造成严重...

    外键列上是否需要索引

    其实这个问题应该算是老生常谈了。这两天看concept看到这里,于是就在说说这个问题。

    外键列上缺少索引会带来两个问题,限制并发性、影响性能。而这两个问题中的任意一个都可能会造成严重性能问题。

    无论是Oracle的官方文档,还是在Tom的书中都说明了两种情况下可以忽略外键上的索引。其实我认为不需要那么麻烦,与增加一个索引所带来的性能开销和磁盘空间开销相比,确实索引可能引发的问题要严重得多。因此,我会选择在所有的外键列上添加索引,虽然可能导致创建了部分多余的索引,但是这样相除了外键约束由于确实索引所带来的性能问题和并发性问题。

    如果外键列上缺少索引,从主表(即被外键引用的那个表)关联子表(即建立外键所在的那个表)的查询就只能对子表选择全表扫描的查询,这是显而易见的问题:

    SQL> CREATE TABLE T_P (ID NUMBER, NAME VARCHAR2(30));

    表已创建。

    SQL> ALTER TABLE T_P ADD PRIMARY KEY (ID);

    表已更改。

    SQL> CREATE TABLE T_C (ID NUMBER, FID NUMBER, NAME VARCHAR2(30));

    表已创建。

    SQL> ALTER TABLE T_C ADD CONSTRAINT FK_T_C
    2 FOREIGN KEY (FID)
    3 REFERENCES T_P (ID);

    表已更改。

    SQL> INSERT INTO T_P SELECT ROWNUM, TABLE_NAME FROM ALL_TABLES;

    已创建884行。

    SQL> INSERT INTO T_C SELECT ROWNUM, MOD(ROWNUM, 884) + 1, OBJECT_NAME
    2 FROM ALL_OBJECTS;

    已创建30339行。

    SQL> COMMIT;

    提交完成。

    SQL> SELECT A.ID, A.NAME, B.NAME
    2 FROM T_P A, T_C B
    3 WHERE A.ID = B.FID
    4 AND A.ID = 880;

        ID NAME                           NAME
    

       880 T_COMPRESS                     /eb2b6b5_Options1
       880 T_COMPRESS                     DATE
       880 T_COMPRESS                     DEF$_SCHEDULE
       880 T_COMPRESS                     GV_$SESSION_EVENT
    

    .
    .
    .
    880 T_COMPRESS sun/io/ByteToCharCp1251
    880 T_COMPRESS /5ba3839f_DirStateFactoryResul
    880 T_COMPRESS USER_INDEXTYPES

    已选择34行。

    执行计划

    0 SELECT STATEMENT ptimizer=CHOOSE
    1 0 MERGE JOIN
    2 1 TABLE ACCESS (BY INDEX ROWID) OF ‘T_P’
    3 2 INDEX (UNIQUE SCAN) OF ‘SYS_C002964’ (UNIQUE)
    4 1 FILTER
    5 4 TABLE ACCESS (FULL) OF ‘T_C’

    统计信息

          0  recursive calls
          0  db block gets
        190  consistent gets
          0  physical reads
          0  redo size
       1829  bytes sent via SQL*Net to client
        394  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         34  rows processed
    

    由于缺少索引,上面的这个关联查询只能采用MERGE JOIN,而如果联立了外键列上的索引:

    SQL> CREATE INDEX IND_T_C_FID ON T_C (FID);

    索引已创建。

    SQL> SELECT A.ID, A.NAME, B.NAME
    2 FROM T_P A, T_C B
    3 WHERE A.ID = B.FID
    4 AND A.ID = 880;

        ID NAME                           NAME
    

       880 T_COMPRESS                     /e1538703_EntryInfoImpl
       880 T_COMPRESS                     /7b832daf_ObjectStreamClassCom
       880 T_COMPRESS                     java/awt/peer/ScrollbarPeer
       880 T_COMPRESS                     /1982bd95_PermissionsEnumerato
    

    .
    .
    .
    880 T_COMPRESS /9ebda46b_GetInterface
    880 T_COMPRESS /c71f85e7_DefaultPopupFactory
    880 T_COMPRESS /7b549d81_DataFormatException

    已选择34行。

    执行计划

    0 SELECT STATEMENT ptimizer=CHOOSE
    1 0 NESTED LOOPS
    2 1 TABLE ACCESS (BY INDEX ROWID) OF ‘T_P’
    3 2 INDEX (UNIQUE SCAN) OF ‘SYS_C002964’ (UNIQUE)
    4 1 TABLE ACCESS (BY INDEX ROWID) OF ‘T_C’
    5 4 INDEX (RANGE SCAN) OF ‘IND_T_C_FID’ (NON-UNIQUE)

    统计信息

          0  recursive calls
          0  db block gets
         42  consistent gets
          1  physical reads
          0  redo size
       1829  bytes sent via SQL*Net to client
        394  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         34  rows processed
    

    上面是影响性能的例子,下面看看外键列索引对并发性的影响:

    SQL> SET AUTOT OFF
    SQL> SELECT * FROM T_P WHERE ID < 5;

        ID NAME
    

         1 SEG$
         2 CLU$
         3 OBJ$
         4 FILE$
    

    SQL> SELECT * FROM T_C WHERE ID < 5;

        ID        FID NAME
    

         1          2 /1005bd30_LnkdConstant
         2          3 /10076b23_OraCustomDatumClosur
         3          4 /10297c91_SAXAttrList
         4          5 /103a2e73_DefaultEditorKitEndP
    

    下面在另一个会话中删除子表的一条记录:

    SQL> SET SQLP ‘SQL2> ’
    SQL2> DELETE T_C WHERE ID = 2;

    已删除 1 行。

    删除了一条为2的子表级联,其对应的主表记录ID为3,下面尝试在第一个会话新增一条ID为1000的记录,然后删除这条记录:

    SQL> INSERT INTO T_P VALUES (1000, ‘A’);

    已创建 1 行。

    SQL> DELETE T_P WHERE ID = 1000;

    已删除 1 行。

    SQL> ROLLBACK;

    回退已完成。

    可以看到,并没有发生锁表的情况,这是因为子表外键列上有索引,删除主表的记录时,只会锁定子表参考主表的对应记录。

    会话二回滚:

    SQL2> ROLLBACK;

    回退已完成。

    下面删除外键索引:

    SQL> DROP INDEX IND_T_C_FID;

    索引已删除。

    重复刚才的操作,在另一个会话执行删除操作:

    SQL2> DELETE T_C WHERE ID = 2;

    已删除 1 行。

    在会话一重复插入和删除操作:

    SQL> INSERT INTO T_P VALUES (1000, ‘A’);

    已创建 1 行。

    SQL> DELETE T_P WHERE ID = 1000;

    这时会话被锁住,因为缺少了外键索引后,主表删除或更新记录会导致子表整个表被锁,而这会导致严重的系统并发问题。

    SQL2> ROLLBACK;

    回退已完成。

    会话2回滚后,会话1的删除操作才可以继续执行:

    已删除 1 行。

    SQL>

    可能有些人会认为,系统中不存在删除而不会导致这个问题,其实不仅是删除,主键列的更新同样可以导致这个问题。

    而且这种更新可能是工具帮你自动完成的,因为很多工具会自动生成SQL语句,而在这种生成的SQL语句中,UPDATE的列是表中的所有列,所以即使主键的值没有发生变化,但是仍然是被更新了:

    SQL2> DELETE T_C WHERE ID = 2;

    已删除 1 行。

    还是删除这条ID为2的子表记录,下面在主表执行一个更新操作:

    SQL> UPDATE T_P SET ID = 500 WHERE ID = 500;

    可以看到,不管值是否发生了变化,只要主键列被更新,就会导致操作被锁定。

    显而易见,不加索引的外键列会造成严重的性能问题,所以除非你有十分的把握,否则还是在外键列上添加索引吧。

    参考:

    外键约束 索引 百度

    外键必须是另一个表的主键吗

    展开全文
  • MongoDB 单键()索引

    千次阅读 2016-12-09 17:16:01
    基于业务的需要,可以基于一些重要的查询和操作来创建一些额外的索引。这些索引可以是单列,也可是多(复合索引),多键索引,地理空间索引,文本索引以及哈希索引等。 本文主要描述在基于文档上的单列来创建索引
  • 查看索引 show index from 数据库表名 alter table 数据库add index 索引名称(数据库字段名称) PRIMARY KEY(主键索引) ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) UNIQUE(唯一索引) ...
  • 联合索引(多列索引

    万次阅读 多人点赞 2018-08-07 15:37:09
    联合索引是指对表上的多个进行索引,联合索引也是一棵B+树,不同的是联合索引的键值数量不是1,而是大于等于2. 最左匹配原则 假定上图联合索引的为(a,b)。联合索引也是一棵B+树,不同的是B+树在对索引a排序...
  • mysql 给增加索引

    千次阅读 2019-07-26 17:38:52
    优点: ...缺点:创建了索引,当然就需要我们去维护索引了,维护是需要时间,随着索引的增加而增加。索引还会占用物理空间,我们数据库的数据表是占用物理空间,索引也是要占用一定的空间,而且...
  • 一般来说,不应该创建索引的的这些具有下列特点: 1,对于那些在查询中很少使用或者参考的不应该创建索引。这是因为,既然这些很少使用到,因此有索引或者无索引,并不能提高查询速度。相反,由于增加了索引,...
  • SQL Server 2016 存储索引功能增强

    千次阅读 2016-06-16 15:21:56
    存储索引(columnstore index)在SQL Server 2012中已经引入,其带来性能提升的同时也有很多限制,比如对带有存储索引的表进行INSERT, UPDATE和DELETE时,会遇到如下错误提示: 由于这种限制,索引列存储索引...
  •   一、 MySQL: 索引以B树格式保存 Memory存储引擎可以选择Hash... 1、普通索引:create index 索引名 Tablename(的列表)  alter table TableName add index (的列表)  create table TableName([...], ...
  • MySQL单列索引和多列索引

    千次阅读 2018-09-21 16:12:09
    在设计MySql表索引的时候,可能有个问题,就是多个单列索引好,还是设计为多列索引好;下面从不同角度分析下这个问题;1.多个单列索引: 定义:即是在表中在需要索引的字段上为每个字段设计一个索引; 特点:简单,...
  • 正确理解Mysql的列索引和多列索引

    千次阅读 2016-09-19 14:18:35
    Mysql数据库提供两种类型的索引,如果没正确设置,索引的利用效率会大打折扣并且完全不知问题所在。 [c-sharp] view plain copy CREATE TABLE test (   id INT NOT NULL,   ...
  • 单列索引和多列索引

    千次阅读 2013-02-26 20:48:02
    在性能优化过程中,选择在哪些列上创建索引是最重要的步骤之一。可以考虑使用索引的主要有两种类型的:在Where子句中出现的,在join子句中出现的。请看下面这个查询:  Select age ## 不使用索引  FROM ...
  • demo.py(index索引,修改索引,将DataFrame某设为索引): # coding=utf-8 import numpy as np import pandas as pd df = pd.DataFrame(np.arange(12, 24).reshape((3, 4)), index=["a", "b&...
  • select *与select 无索引列以及select 有索引列的比较
  • 算出每行或列的最大值所在的列索引或行索引: 默认为0,返回一列最大值所在行的行索引df.idxmax() 设置为1,则为一行最大值所在列的列索引df.idxmax(1) (取最小值为df.idxmin())
  • 该数据集有行和索引的概念。 我们在数据操作中常常需要进行的对数据集进行分组统计之类。这时就很涉及到数据集改变之后数据索引也可能随之改变。 1.查看数据索引列 col_name = bin_df.index.name print(‘col_...
  • SQL联合索引 与 单一索引

    万次阅读 2012-06-12 13:46:59
      背景:目前WEB的普及太快,很多网站都会因为大流量的数据而发生服务器习惯性死机,一个查询语句...1):查询条件中出现联合索引第一,或者全部,则能利用联合索引. 2):条件中只要条件相连在一起,以本文例子来说就是:
  • 创建单列索引,多列索引

    千次阅读 2018-11-14 19:17:48
    单列索引: CREATE TABLE t_user ( id INT, username VARCHAR(20), PASSWORD VARCHAR(20), ...多列索引: CREATE TABLE t_user1 ( id INT, username VARCHAR(20), PASSWORD VARCHAR(20), INDEX index...
  • Oracle外键上是否需要索引

    万次阅读 2009-02-23 20:47:00
    其实我认为不需要那么麻烦,与增加一个索引所带来的性能开销和磁盘空间开销相比,确实索引可能引发的问题要严重得多。因此,我会选择在所有的外键上添加索引,虽然可能导致创建了部分多余的索引,但是这样相除
  • 以下的文章主要介绍的是MySQL数据库索引,即单列索引与多列索引的介绍,以及对多列索引的SQL命令的示例,以下就是这些内容的介绍,望你在浏览之后会对MySQL数据库索引的相关内容有更深入的了解。 为了提高搜索效率...
  • 我们常常需要将DataFrame对象中的某或某几列作为索引,或者将索引转化为对象的。pandas提供了set_index()/reset_index() 来供我们使用。 一、转化为索引 df1=pd.DataFrame({'X':range(5),'Y':rang...
  • 一、如何选择合适的建立索引 1、在where从句,group by从句,order by从句,on从句中的添加索引 2、索引字段越小越好(因为数据库数据存储单位是以“页”为单位的,数据存储的越多,IO也会越大) 3、离散度大的...
  • 通过把多个(单列)索引合并成一个(多索引后,测试得出Delete ,update ,insert操作时需要花费的时间大大缩短。 由于多个(单列)索引合并成一个(多索引,可能会对之前单列索引字段的查询性能有影响,...
  • 一、什么是索引?  索引用来快速地寻找那些具有特定值的记录...如果作为搜索条件的上已经创建了索引,MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录,通过索引查找记录至少要比顺序扫描

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 669,362
精华内容 267,744
关键字:

哪些列需要索引