索引

Lucene简介 　　Lucene中，以document的形式作为搜索的主体。document由fieldName和fieldValue所组成，每个fieldValue又可以由一个或多个term元素来组成。基于不同的分词及索引规则，可用于搜索fieldValue的term少于组成fieldValue的term。Lucene的搜索基于反向索引，包含着可用于搜索document的field信息。通过Lucene，可以正向查找document，以便了解其包含哪些field信息；也可以通过反向索引，通过搜索字段的term，来查询包含该term的document。 [ 图1 ] Lucene总体架构 　　由图1所示，IndexSearcher实现了搜索的逻辑，IndexWriter实现了文档的插入与反向索引的建立，IndexReader由IndexSearcher调用以便读取索引的内容。IndexReader和IndexWriter都依赖于抽象类Directory，Directory提供操作索引数据及的API。 　　标准的Lucene是基于文件系统和基于内存的。 　　标准基于文件系统的后端的缺点在于，随着索引增加性能会下降，人们使用了各种不同的技术来解决这个问题，包括负载均衡和索引分片（index sharding，在多个Lucene实例之间切分索引）。尽管分片功能很强大

JavaScript：基础语法 注释 JavaScript的语法和Java语言类似，每个语句以 ; 结束，语句块用 {...} 。但是，JavaScript并不强制要求在每个语句的结尾加;浏览器中负责执行JavaScript代码的引擎会自动在每个语句的结尾补上;。JavaScript严格区分大小写，如果弄错了大小写，程序将报错或者运行不正常。 注释: // 这是一行注释 alert('love qinjiang'); // 这也是注释 /* 从这里开始是块注释 仍然是注释 仍然是注释 注释结束 */ 变量 变量的概念基本上和小学的方程变量是一致的，只是在计算机程序中，变量不仅可以是数字，还可以是任意数据类型。 变量在JavaScript中就是用一个变量名表示，变量名是大小写英文、数字、$和_的组合，且 不能用数字开头 。变量名也不能是 JavaScript的关键字 ，如if、while等。申明一个变量用var语句，比如： var a; // 申明了变量a，此时a的值为undefined var $b = 1; // 申明了变量$b，同时给$b赋值，此时$b的值为1 var s_007 = '007'; // s_007是一个字符串 var Answer = true; // Answer是一个布尔值true var t = null; // t的值是null

一、单表 创建索引之前：type=ALL全表扫描，Extra里面的Using filesort(文件内部排序) 根据where后面的条件创建 ： CREATE INDEX idx_article_ccv ON article(category_id,comments,views); 可以看出type由ALL变成了range,但是Extra里面的Using filesort(文件内部排序)未解决 此时删除索引 : DROP INDEX idx_article_ccv ON article; 重新建立 ： CREATE INDEX idx_article_ccv ON article(category_id,views); 此时完美解决！！ 二、双表 创建索引之前：type=ALL全表扫描 此时有两个表，里面都有字段card,但是现在不知道应该建左表class还是右表book,所以可以先建右表book，查看之后再进行优化 ALTER TABLE book ADD index Y('card'); 此时可以明显看到book表得到优化type=ref,但是class表未得到改变，于是删除索引 ： DROP INDEX Y ON book; 现在加左表class: ALTER TABLE class ADD INDEX Y ('card'); 此时看到class表的type=index

MongoDB 允许深入文档内部，对嵌套字段和数组建立索引； 嵌套对象和数组字段可以和复合索引中的顶级字段一起使用，多数情况下与“正常”索引字段的行为也是一致的。 考虑以下文档集合（user ）: db . user . insertMany ( [ { "address" : { "province" : "HeNan" , "city" : "ZhengZhou" , "pincode" : "123" }, "tags" : [ "music" , "cricket" , "blogs" ], "name" : "fly" }, { "address" : { "province" : "HeBei" , "city" : "HanDan" , "pincode" : "234" }, "tags" : [ "music" , "basket" , "blogs" ], "name" : "chen" }, { "address" : { "province" : "ChongQing" , "city" : "ChongQing" , "pincode" : "456" }, "tags" : [ "music" , "writing" , "running" ], "name" : "wang" } ] ) 以上文档包含了 address 子文档和 tags 数组。

1. 背景 自从大家对于MySQL数据库的稳定性有了更高的追求后，经常有小伙伴有这样的疑问，对于count(*)这样的操作，有没有正确的姿势，或者有没有可以优化的地方？ 但答案比较残酷，如果已经使用了正确的索引，那么基本上没有可以优化的地方。 一旦出现慢查询了，它就是慢查询了，要改，只能自己计数或者通过其他搜索平台来做。 今天，就一起来看看为什么会这样，并对大家日常会遇到的一些的困惑进行解答。 2. count(*)的实现方式 据说，MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高。 而我们的mysql一般都是用Innodb的引擎，Innodb是怎么实现count操作的呢？ InnoDB 引擎就比较麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。 所以，当我们的表里面的记录越来越多的时候，count(*)就会越来越慢。 当然，我们这里说的都是不带where条件的，如果带上where条件的话，MyISAM也是很慢的。 3.正确的打开方式 嗯，首先还是说，mysql上不太推荐用count(*)来做统计相关业务，尤其是表非常大的情况下。 那如果业务比较小，需要快速上马，那么，至少应该保证count(*)带上了科学的where条件，然后，这个表也已经建立了科学的索引。 如果count(

在 SQL Server 中，为了查询性能的优化，有时我们就需要对数据表通过建立索引的方式，目的主要是根据查询要求，迅速缩小查询范围，避免全表扫描。 索引有两种类型，分别是聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(nonclustered index，也称非聚类索引、非簇集索引)。 聚集索引在一个表中只能有一个，默认情况下在主键建立的时候创建，它是规定数据在表中的物理存储顺序，我们也可以取消主键的聚集索引，所以必须考虑 数据库 可能用到的查询类型以及使用的最为频繁的查询类型，对其最常用的一个字段或者多个字段建立聚集索引或者组合的聚集索引，它就是SQL Server会在物理上按升序(默认)或者降序重排数据列，这样就可以迅速的找到被查询的数据。 非聚集索主要是 数据存储 在 一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储。可以在一个表格中 使用高达249个非聚集的索引，在查询的过程中先对非聚集索引进行搜索，找到数据值在表中的位置，然后从该位置直接检索数据。这使非聚集索引成为精确匹配 查询的最佳方法，因为索引包含描述查询所搜索的数据值在表中的精确位置的条目。 所以我们在选择创建聚集索引的时候要注意以下几个方面： 1) 对表建立主键时，就会为主键自动添加了聚集索引

1、id 每个被独立执行的操作的标识，表示对象被操作的顺序；id值大，先被执行；如果相同，执行顺序从上到下。 若没有子查询和联合查询，id则都是1。Mysql会按照id从大到小的顺序执行query，在id相同的情况下，则从上到下执行。 2、select_type 查询中每个select子句的类型 （1）SIMPLE （2）PRIMARY/UNION （3）DEPENDENT UNION/UNIOIN RESULT （4）SUBQUERY/DEPENDENT SUBQUERY （5）DERIVED/MATERIALIZED （6）UNCACHEABLE SUBQUERY/UNCACHEABLE UNION 3、table 名字，被操作的对象名称，通常是表名，或者表的别名，或者一个为查询产生临时表的标示符（如派生表、子查询、集合）。 4、type 代表查询执行计划中表使用的连接方式。连接操作的类型。 （1）SYSTEM （2）CONST （3）EQ_REF （4）REF （5）REF_OR_NULL （6）RANGE （7）INDEX_SCAN （8）ALL （9）UNIQUE_SUBQUERY （10）INDEX_SUBQUERY （11）INDEX_MERGE （12）FT system > const > eq_ref > ref > fulltext > ref_or_null

索引 什么是索引？ 索引是一种磁盘上的数据结构，建立在表或视图的基础上。使用索引可以使数据的获取更快更高校，也会影响其他的一些性能，如插入或更新等。 索引主要分为两种类型：聚集索引和非聚集索引。 字典的目录就是一个索引，按照拼音查询想要的字就是聚集索引（物理连续，页码与目录一一对应），偏旁部首就是一个非聚集索引（逻辑连续，页码与目录不连续）。 聚集索引存储记录是物理上连续存在的，而非聚集索引是逻辑上的连续，物理存储并不连续。 聚集索引一个表中只能有一个，而非聚集索引一个表中可以有多个。 索引的利弊 使用索引是为了避免全表扫描，因为全表扫描是从磁盘上读取表的每一个数据页，如果有索引指向数据值，则只需要读少次数的磁盘就可以。 带索引的表在数据库中占用更多的空间，同样增、删、改数据的命令所需时间会更长。 索引的存储机制 书中的目录是一个字词以及所在的页码列表，数据库中的索引是表中的值以及各值存储位置的列表。 聚集索引是在数据库中新开辟一个物理空间，用来存放他排列的值，当有新数据插入时，他会重新排列整个物理存储空间。 非聚集索引只包含原表中的非聚集索引的列和指向实际物理表的一个指针。 数据表的基本结构 当一个新的数据表创建时，系统将在磁盘中分配一段以8k为单位的连续空间。当一个8k用完的时候，数据库指针会自动分配一个8k的空间，每个8k的空间称为一个数据页，并分配从0-7的页号

聚集索引 , 表中存储的数据按照索引的顺序存储,检索效率比普通索引高,但对数据新增/修改/删除的影响比较大 非聚集索引 ,不影响表中的数据存储顺序,检索效率比聚集索引低,对数据新增/修改/删除的影响很小 如何让你的SQL运行得更快 ---- 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略 了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库 环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践 中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的whe re子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个 方面分别进行总结： ---- 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均 表示为（< 1秒）。 ---- 测试环境-- ---- 主机：HP LH II ---- 主频：330MHZ ---- 内存：128兆 ---- 操作系统：Operserver5.0.4 ----数据库：Sybase11.0.3 一、不合理的索引设计 ----例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况： ---- 1.在date上建有一非个群集索引 select count(*) from record

sql Server 索引优化 聚集索引 , 表中存储的数据按照索引的顺序存储 , 检索效率比普通索引高 , 但对数据新增 / 修改 / 删除的影响比较大 非聚集索引 , 不影响表中的数据存储顺序 , 检索效率比聚集索引低 , 对数据新增 / 修改 / 删除的影响很小 如何让你的 SQL 运行得更快 ---- 人们在使用 SQL 时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略 了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库 环境中（如联机事务处理 OLTP 或决策支持系统 DSS ）中表现得尤为明显。笔者在工作实践 中发现，不良的 SQL 往往来自于不恰当的索引设计、不充份的连接条件和不可优化的 whe re 子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个 方面分别进行总结： ---- 为了更直观地说明问题，所有实例中的 SQL 运行时间均经过测试，不超过１秒的均 表示为（ < 1 秒）。 ---- 测试环境 -- ---- 主机： HP LH II ---- 主频： 330MHZ ---- 内存： 128 兆 ---- 操作系统： Operserver5.0.4 ---- 数据库： Sybase11.0.3 一、不合理的索引设计 ---- 例：表 record 有 620000 行，试看在不同的索引下，下面几个