您现在的位置：首页 --> 查看专题： 索引
新上线的系统很多数字类型的字段都是使用varchar2类型存放，要转换成number类型时，和开发人员对number类型的字段在查询时加上单引号走不走索引的问题产生了分歧，大家都知道，如果使用char类型存放数字，在查询时如果不加单引号是不会走索引的，测试信息如下，数据库版本11.2.0.4.0。
在MySQL里，主键索引和辅助索引分别是什么意思，有什么区别？
在MySQL里，聚集索引和非聚集索引分别是什么意思，有什么区别？
索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？
TokuMX的一大创新在于，它打破了一条长久存在的关于数据库的规则：要保证好的写入性能，索引的工作集应当能够放在内存里。标准答案是这样的：如果索引的工作集比内存要大，写入就需要执行I/O，I/O就会成为限制因素，性能就会下降。所以，要么让索引小到能全部放进内存，要么提供一种索引写入模式，避免工作集过大，比如MongoDB所采用的，内存中只为最近插入的数据保存索引。
最近做一个mysql专题学习。在了解到mysql变量时myisam_stats_method引导出MyISAM索引统计集合。然后了解InnODB和MyISAM索引统计集合，以下是对官网的翻译以及自己附加些少理解。
有同学问到InnoDB的索引长度问题，简单说几个tips。 大家经常碰到InnoDB单列索引长度不能超过767bytes，实际上联合索引还有一个限制是3072。
索引扫描不同于表扫描，表扫描只有一种类型就是全表扫描(full table scans),而索引扫描根据具体情况不同可以分为如下几类：索引唯一扫描(index unique scan).这种扫描发生在主键或者唯一索引上，根据键值可以唯一确定要访问的记录，这种扫描方式因为返回的记录数少，能够快速定位记录，扫描效率较高索引范围扫描(index range scan).这种撒么一般发生在返回多个值的时候，如where条件中>and <或者非唯一索引中的=时，范围扫描要求返回的结果集不能太多，否则不能从索引扫描上获取益处，因为从索引只能获得rowid与索引列的值，，有可能还需要根据rowid回表一条条的去找行的其他数据，除非不需要回表便能从索引上获得必需的数据。
索引扫描不同于表扫描，表扫描只有一种类型就是全表扫描(full table scans),而索引扫描根据具体情况不同可以分为如下几类：索引唯一扫描(index unique scan).这种扫描发生在主键或者唯一索引上，根据键值可以唯一确定要访问的记录，这种扫描方式因为返回的记录数少，能够快速定位记录，扫描效率较高索引范围扫描(index range scan).这种撒么一般发生在返回多个值的时候，如where条件中>and <或者非唯一索引中的=时，范围扫描要求返回的结果集不能太多，否则不能从索引扫描上获取益处，因为从索引只能获得rowid与索引列的值，，有可能还需要根据rowid回表一条条的去找行的其他数据，除非不需要回表便能从索引上获得必需的数据。
今天遇到一个奇怪的问题，明明已经建立了索引，select语句的explain也表明会利用这个索引，可是结果偏偏没有用索引，最后扫描了全表。 两个结构完全一样的sql语句： sql1: select * from table where col_a = 123 and col_b in (‘foo’,\'bar’) order by id desc; sql2: select * from table where col_a = 456 and col_b in (‘foo’,\'bar’) order by id desc; 结果sql1选择利用了col_a的索引，速度很快，sql2利用了主键ID的索引，扫描了全表(40w行)。 仔细分析，发现数据库中，col_a=456的记录数有近1万条，而col_a=123的记录数
教科书上的B+Tree是一个简化了的，方便于研究和教学的B+Tree。然而在数据库实现时，为了 更好的性能或者降低实现的难度，都会在细节上进行一定的变化。下面以InnoDB为例，来说说。
大家都知道索引对于数据访问的性能有非常关键的作用，都知道索引可以提高数据访问效率。为什么索引能提高数据访问性能？他会不会有“副作用”？是不是索引创建越多，性能就越好？到底该如何设计索引，才能最大限度的发挥其效能？这篇文章主要是带着上面这几个问题来做一个简要的分析，同时排除了业务...
本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。
写在前面的话 在编程领域有一句人尽皆知的法则“程序 = 数据结构 + 算法”，我个人是不太赞同这句话(因为我觉得程序不仅仅是数据结构加算法)，但是在日常的学习和工作中我确认深深感受到数据结构和算法的重要性，很多东西，如果你愿意稍稍往深处挖一点，那么扑面而来的一定是各种数据结构和算法知识。例如几乎每个程序员都要打交道的数据库，如果仅仅是用来存个数据、建建表、建建索引、做做增删改查，那么也许觉得数据结构和这东...
框计算垂直搜索的索引的设计考虑因素与相应构建流程
二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所...
[ 共35篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
近3天十大热文
-
[607] Go Reflect 性能 -
[24] 正态分布的前世今生(一)
-
[14] rsync同步的艺术
-
[14] 什么是DNS劫持和DNS污染？
-
[13] Linux Used内存到底哪里去了？
-
[13] Mac下.apk的反编译
-
[13] 怎样用core文件调试你的linux程序？
-
[13] 深入浅出选择类排序算法(简单选择排序,堆排序
-
[13] Cuckoo Filter：设计与实现
-
[11] jQuery性能优化指南
赞助商广告
