索引

作者： 柯三 juejin.im/post/5e0443ae6fb9a0162277a2c3 送分题 面试官： 有操作过Linux吗? 我： 有的呀 面试官： 我想查看内存的使用情况该用什么命令 我： free 或者 top 面试官： 那你说一下用free命令都可以看到啥信息 我： 那，如下图所示 可以看到内存以及缓存的使用情况 total 总内存 used 已用内存 free 空闲内存 buff/cache 已使用的缓存 avaiable 可用内存 面试官： 那你知道怎么清理已使用的缓存吗(buff/cache) 我： em… 不知道 面试官： sync; echo 3 > /proc/sys/vm/drop_caches 就可以清理buff/cache了，你说说我在线上执行这条命令做好不好? 我： (送分题,内心大喜)好处大大的有，清理出缓存我们就有更多可用的内存空间, 就跟pc上面xx卫士的小火箭一样，点一下，就释放出好多的内存 面试官： em…., 回去等通知吧 再谈SQL Join 面试官： 换个话题，谈谈你对join的理解 我： 好的（再答错就彻底完了，把握住机会) 回顾 SQL中的join可以根据某些条件把指定的表给结合起来并将数据返回给客户端 join的方式有 inner join 内连接 left join 左连接 right join 右连接 full join

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

视图可以看作定义在SQL Server上的虚拟表.视图正如其名字的含义一样，是另一种查看数据的入口.常规视图本身并不存储实际的数据，而仅仅存储一个Select语句和所涉及表的metadata. 视图简单的理解如下: 通过视图，客户端不再需要知道底层table的表结构及其之间的关系。视图提供了一个统一访问数据的接口。 为什么要使用视图(View) 从而我们不难发现，使用视图将会得到如下好处: 视图隐藏了底层的表结构，简化了数据访问操作 因为隐藏了底层的表结构，所以大大加强了安全性，用户只能看到视图提供的数据 使用视图，方便了权限管理，让用户对视图有权限而不是对底层表有权限进一步加强了安全性 视图提供了一个用户访问的接口，当底层表改变后，改变视图的语句来进行适应，使已经建立在这个视图上客户端程序不受影响 视图(View)的分类 视图在SQL中可以分为三类 普通视图(Regular View) 索引视图(Indexed View) 分割视图(Partitioned View) 下面从这几种视图类型来谈视图 普通视图(Rugular View) 普通视图由一个Select语句所定义，视图仅仅包含其定义和被引用表的metadata.并不实际存储数据。MSDN中创建视图的模版如下: CREATE VIEW [ schema_name . ] view_name [ (column [ ,..

　　 Lucene的普及和成功的背后是因为它的简单。 　　因此，你不需要深入理解Lucene的信息索引和检索工作方面的知识就可以开始使用。 　　Lucene提供了简单但是强大的核心API去实现全文索引和检索，你只需要掌握少数的类就能将Lucene整合到应用中。 　　刚接触Lucene的人可能会误认为Lucene是一个文件搜索工具、网络爬虫、或者网页搜索引擎。实际上Lucene是一个软件库，而不是一个全功能的搜索应用程序。它涉及全文索引和搜索，而且做得非常好。Lucene可以让你的应用程序隐藏起复杂的索引和搜索背后的操作，而使用简单的API处理特定的问题领域和业务规则。你可以想象Lucene就是像一个层，你的应用就在层的上面。 　　Lucene允许你添加索引和搜索功能到应用程序中。Lucene不关心数据的来源，Lucene可以索引和搜索任何可以转换成文本格式的数据。这意味着你可以用Lucene索引和搜索数据：远程web服务器上的网页、存储在本地文件系统的文档、简单的文本文件、Microsoft Word文档、HTML或PDF文件，或者其他任何可以从中提取文本信息的格式文件。 　　所有搜索引擎的核心就是索引的概念：把原始数据处理成一个高效的交叉引用查找，以便快速检索。让我们看看快速高效的索引和搜索过程。 　 　1.索引是什么，为什么它这么重要？ 　 　假如你需要搜索大量的文件

列表： 列表是python中的基础数据类型之一，其他语言中也有类似于列表的数据类型，比如js中叫数组，他是以[]括起来，每个元素以逗号隔开，而且他里面可以存放各种数据类型比如： li = [‘hyg’,123,Ture,(1,2,3,’hum’),[1,2,3,’小明’,],{‘name’:’lyy’}] 列表相比于字符串，不仅可以储存不同的数据类型，而且可以储存大量数据，32位python的限制是 536870912 个元素,64位python的限制是 1152921504606846975 个元素。而且列表是有序的，有索引值，可切片，方便取值。 列表中通过 索引，切片，切片+步长 操作与字符串中一样 列表的增、删、改、查及其他方法 增 # append 追加 li = [1, 3, 'hyg', [2], 5] li.append(9) print(li) #显示:[1, 3, 'hyg', [2], 5, 9] #insert 按索引插入在钙索引前 li = [1, 3, 'hyg', [2], 5] li.insert(1, '宝元') print(li) #显示:[1, '宝元', 3, 'hyg', [2], 5] # extend 迭代着追加 li = [1, 3, 'hyg', [2], 5] li.extend('abc') print(li) #显示:[1, 3

select a.col1,a.col2 from temp1 a where not exists (select 'X' from temp2 b where b.col2 = a.col1); select 'X' 可以理解成存在(exists)不存在(not exists)的含义。 如上面 找到a表中 col1的字段值不与b表中col2字段值相等的数据 从效率来看： 1) select * from T1 where exists(select 1 from T2 where T1.a=T2.a) ; T1数据量小而T2数据量非常大时，T1<<T2 时，1) 的查询效率高。 2) select * from T1 where T1.a in (select T2.a from T2) ; T1数据量非常大而T2数据量小时，T1>>T2 时，2) 的查询效率高。 简而言之，一般式：外表大，用IN；内表大，用EXISTS。 执行方式： 通过使用EXISTS，Oracle会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。oracle在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。

从效率来看： 1) select * from T1 where exists(select 1 from T2 where T1.a=T2.a) ; T1数据量小而T2数据量非常大时，T1<<T2 时，1) 的查询效率高。 2) select * from T1 where T1.a in (select T2.a from T2) ; T1数据量非常大而T2数据量小时，T1>>T2 时，2) 的查询效率高。 简而言之，一般式：外表大，用IN；内表大，用EXISTS。 执行方式： 通过使用EXISTS，Oracle会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。Oracle在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。 in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询。 not exists:做NL，对子查询先查，有个虚表，有确定值，所以就算子查询有NULL最终也有值返回 not in:做hash，对子查询表建立内存数组，用外表匹配，那子查询要是有NULL那外表没的匹配最终无值返回。

Field 属性： 　　Field是文档中的域，包括Field名和Field值两部分，一个文档可以包括多个Field，Document只是Field的一个承载体，Field值即为要索引的内容，也是要搜索的内容。 　　　　是否分词 (tokenized) 　　　　　　是：作分词处理，即将Field值进行分词，分词的目的是为了索引。 　　　　　　　　比如：商品名称、商品描述等，这些内容用户要输入关键字搜索，由于搜索的内容格式大、内容多需要分词后将语汇单元建立索引 　　　　　　否：不作分词处理 　　　　　　　　比如：商品id、订单号、身份证号等 　　　　是否索引 (indexed) 　　　　　　是：进行索引。将Field分词后的词或整个Field值进行索引，存储到索引域，索引的目的是为了搜索。 　　　　　　　　比如：商品名称、商品描述分析后进行索引，订单号、身份证号不用分词但也要索引，这些将来都要作为查询条件。 　　　　　　否：不索引。 　　　　　　　　比如：图片路径、文件路径等，不用作为查询条件的不用索引。 　　　　是否存储 (stored) 　　　　　　是：将Field值存储在文档域中，存储在文档域中的Field才可以从Document中获取。 　　　　　　　　比如：商品名称、订单号，凡是将来要从Document中获取的Field都要存储。 　　　　　　否：不存储Field值 　　　

对于数据库，优化查询的方法 1.使用索引 　　使用索引时，应尽量避免全表扫描，首先应考虑在 where 及 order by ，group by 涉及的列上建立索引。 2.优化SQL语句 　 1）分析查询语句：通过对查询语句的分析，可以了解查询语句执行情况，找出查询语句执行的瓶颈，从而优化查询语句。 　　　通过explain（查询优化神器）用来查看SQL语句的执行结果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。 　　　例如：explain select * from news; 　2）任何地方都不要使用select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。 　3）不在索引列做运算或者使用函数。 　4）查询尽可能使用 limit 减少返回的行数，减少数据传输时间和带宽浪费。 3.优化数据库对象 　1）优化表的数据类型 　　使用 procedure analyse()函数对表进行分析，该函数可以对表中列的数据类型提出优化建议。表数据类型第一个原则是：使用能正确地表示和存储数据的最短类型。这样可以减少对磁盘空间、内存、CPU缓存的使用。 　　使用方法：select * from 表名 procedure analyse(); 　2）对表进行拆分 　　通过拆分表可以提高表的访问效率。有两种拆分方法： 　 　a.垂直拆分（按照功能模块） 　　

本文摘抄自美团的技术博客 MySQL索引原理及慢查询优化 索引的数据结构 前面讲了生活中索引的例子，索引的基本原理，数据库的复杂性，又讲了操作系统的相关知识，目的就是让大家了解，任何一种数据结构都不是凭空产生的，一定会有它的背景和使用场景，我们现在总结一下，我们需要这种数据结构能够做些什么，其实很简单，那就是：每次查找数据时把磁盘IO次数控制在一个很小的数量级，最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样，b+树应运而生。 详解b+树 如上图，是一颗b+树，关于b+树的定义可以参见 B+树 ，这里只说一些重点，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。 b+树的查找过程 如图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短