什么是索引 拿汉语字典的目录页（索引）打比方：正如汉语字典中的汉字按页存放一样，SQL Server中的数据记录也是按页存放的，每页容量一般为4K 。为了加快查找的速度，汉语字（词）典一般都有按拼音、笔画、偏旁部首等排序的目录（索引），我们可以选择按拼音或笔画查找方式，快速查找到需要的字（词）。 同理，SQL Server允许用户在表中创建索引，指定按某列预先排序，从而大大提高查询速度。 • SQL Server中的数据也是按页（ 4KB ）存放 • 索引：是SQL Se
SQL索引在数据库优化中占有一个非常大的比例， 一个好的索引的设计，可以让你的效率提高几十甚至几百倍，在这里将带你一步步揭开他的神秘面纱。 1.1 什么是索引？ SQL索引有两种，聚集索引和非聚集索引，索引主要目的是提高了SQL Server系统的性能，加快数据的查询速度与减少系统的响应时间 下面举两个简单的例子： 图书馆的例子：一个图书馆那么多书，怎么管理呢？建立一个字母开头的目录，例如：a开头的书，在第一排，b开头的在第二排，这样在找什么书就好说了，这个就是一个聚集索引，可是很多人借书找某某作
SQL索引在数据库优化中占有一个非常大的比例， 一个好的索引的设计，可以让你的效率提高几十甚至几百倍，在这里将带你一步步揭开他的神秘面纱。
如果性能问题是出在程序上，那么就要根据业务对程序中的函数进行调整，可能是函数中的写法有问题，算法有问题，这种调整如果不能解决问题的话，那么就要从架构上进行考虑，我们是不是应该使用这种技术，有没有替代的方案来实现同样的业务功能？举个简单的例子，假设经过跟踪发现，一个负责生成图表的函数存在性能问题，尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI+在Web服务器上根据数据进行复杂的绘图，然后将绘出的图片保存在磁盘上，然后在HTML中添加Img标签来引用图片的地址。现在使用GDI+会消耗大量内存和CPU，而算法上也没有太大的问题，那么这种情况下我们就需要考虑修改架构，不使用GDI+ 绘图的方式，或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源，那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用SilverLight技术，在用户打开网页是只是下载了一个SilverLight文件，该文件负责调用Web服务器的Web服务，将绘图所需的数据获取下来，然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口，不需要做绘图操作。
假设数据库中现在有2万条记录，现在要执行这样一个查询：SELECT * FROM table where num=10000。如果没有索引，必须遍历整个表，直到num等于10000的这一行被找到为止；如果在num列上创建索引，SQL Server不需要任何扫描，直接在索引里面找10000，就可以得知这一行的位置，所以索引的建立可以加快数据库的查询速度。
原文 http://blog.csdn.net/dinglang_2009/article/details/5951428
聚集索引VS非聚集索引 SQL Server 2014 发布日期： 2016年12月 索引是与表或视图关联的磁盘上结构，可以加快从表或视图中检索行的速度。 索引包含由表或视图中的一列或多列生成的键。 这些键存储在一个结构（B 树）中，使 SQL Server 可以快速有效地查找与键值关联的行。 表或视图可以包含以下类型的索引： 群集 聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。 索引定义中包含聚集索引列。 每个表只能有一个聚集索引，因为数据行本身只能按一个顺序排序。 只有当表包含
【数据库】MySQL进阶二、索引简易教程 Mysql索引简易教程 基本概念 索引是指把你设置为索引的字段A的内容储存在一个独立区间S里，里面只有这个字段的内容。在找查这个与这个字段A的内容时会直接从这个独立区间里查找，而不是去到数据表里查找。找到的这些符合条件的字段后再读取字段A所指向真实的数据记录的物理地址，再把对应的数据内容输出。如果你查找的不是索引的字段那么他会从数据表里面查找。因为数据表有很多不相关的字段，数据库程序是不会省略不查找。要判断那些不相关的字段以及多次在记录中跳转是花费
全文引擎使用全文索引中的信息来编译可快速搜索表中的特定词或词组的全文查询。全文索引将有关重要的词及其位置的信息存储在数据库表的一列或多列中。全文索引是一种特殊类型的基于标记的功能性索引，它是由 SQL Server 全文引擎生成和维护的。生成全文索引的过程不同于生成其他类型的索引。全文引擎并非基于特定行中存储的值来构造 B 树结构，而是基于要编制索引的文本中的各个标记来生成倒排、堆积且压缩的索引结构。在 SQL Server 2008 中，全文索引大小仅受运行 SQL Server 实例的计算机的可用内存资
概述 全文引擎使用全文索引中的信息来编译可快速搜索表中的特定词或词组的全文查询。全文索引将有关重要的词及其位置的信息存储在数据库表的一列或多列中。全文索引是一种特殊类型的基于标记的功能性索引，它是由 SQL Server 全文引擎生成和维护的。生成全文索引的过程不同于生成其他类型的索引。全文引擎并非基于特定行中存储的值来构造 B 树结构，而是基于要编制索引的文本中的各个标记来生成倒排、堆积且压缩的索引结构。在 SQL Server 2008 中，全文索引大小仅受运行 SQL Server 实例的计算机的可
听到大牛们说执行计划，总是很惶恐，是对知识的缺乏的惶恐，所以必须得学习执行计划，以减少对这一块知识的惶恐，下面是对执行计划的第一讲-理解执行计划。 本系列【T-SQL】主要是针对T-SQL的总结。 一
mysql 是我们最常用的数据存储的的程序，它是关系数据库的代表，可以直接服务于我们的常规业务，是我们不能离开的数据存储器，对于关系操作复杂的业务，具有很强的优势。
一个学生管理系统，数据库是sql server，有一个Web API用于创建student。student对象的表结构如下：
听到大牛们说执行计划，总是很惶恐，是对知识的缺乏的惶恐，所以必须得学习执行计划，以减少对这一块知识的惶恐，下面是对执行计划的第一讲-理解执行计划。 一、为什么需要执行计划？ （1）帮助分析 当我们想要
本系列文章将会讲解SQL server 中 查询优化与事务处理，了解使用索引工具，使用视图，存储过程，触发器等操作。
当查询优化器生成查询计划时，它将分析什么是用于特定筛选条件的最佳索引。 如果不存在最佳索引，查询优化器仍会使用成本最低的可用访问方法生成查询计划，但也会存储有关这些索引的信息。 使用缺失索引功能，你可以访问有关最佳索引的信息以决定是否实现它们。
http://www.cnblogs.com/wuxiaoqian726/articles/2016095.html
为什么翻译这篇文章，因为本人对于这两种数据库是在熟悉不过了，一个是有10多年的经验，一个也有5-6年的经验，而且这两种数据库在很多部分很相似，所以翻译了此篇。另外前两天有一个同学告知，他们单位SQL SERVER 被替换成 MYSQL ，OMG 这篇文字更的写，明明有 SQL SERVER 表兄弟 POSTGRESQL ，非要找 SQL SERVER 他二舅大伯三姨的儿媳妇 MYSQL 做替换的数据库，做这样决定的人，应该被开除。
在数据库中，我们除了存储数据外，还存储了大量的元数据。它们主要的作用就是描述数据库怎么建立、配置、以及各种对象的属性等。本篇简单介绍如何使用和查询元数据，如何更有效的管理SQLServer 数据库。
索引是跨多个数据存储区的常见概念。 尽管它们在数据存储中的实现可能会有所不同，但也可用于基于列（或一组列）更高效地进行查找。
在一次和技术大佬的聊天中被问到，平时我是怎么做Mysql的优化的？在这个问题上我只回答出了几点，感觉回答的不够完美，所以我打算整理一次SQL的优化问题。
sys.objects、sys.columns、sys.indexes这三个都是系统视图，主要映射了表、列、索引等信息。 与MySQL数据库的information_schema库类似。
事务(进程 ID 89)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。
聚集索引 概述 关于索引和表体系结构的概念一直都是讨论比较多的话题，其中表的各种存储形式是讨论的重点，在各个网站上面也有很多关于这方面写的不错的文章，我写这篇文章的目的也是为了将所有的知识点尽可能的组织起来结合自己对这方面的了解些一篇关于的详细文章出来，同时也会列出一些我自己有疑惑的地方拿出来探讨，介于表达能力有限，有些地方可能无法表达的很明了，还望大家包涵；对于文章中有不对的地方也希望大家能提出，写文章的目的就是为了共享资源；对于这个系列会写5篇文章，在接下来的几天里逐一发布，分别是“聚集索引体系结构
最近在看数据库相关知识，感觉唯一约束和唯一索引好像有点类似，于是研究了一番，于是就有了这篇文章。
缓存 show variables可以查看我们mysql的许多配置，我们查一些需要的参数可以使用类似于模糊匹配的方式如下：
概述 非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点： 基础表的数据行不按非聚集键的顺序排序和存储。 非聚集索引的叶层是由索引页而不是由数据页组成。 既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。 非聚集索引行中的行定位器或是指向行的指针，或是行的聚集索引键，如下所述： 如果表是堆（意味着该表没有聚集索引），则行定位器是指向行的指针。该指针由文件标
1. 概述 很多人都知道索引在数据库上的是有利有弊的。像其他主流商业数据库一样SQL Server允许在一个列上重复创建索引。因为SQL Server没有限制创建重复索引的数量，只是限制数据库的一个表上最多可以创建999重复索引，所以这就增加了数据库中存在重复索引的可能性。表的列上存在重复索引的话，可能会明显的损害数据库性能，因为SQL Server必须分别维护每一个重复索引。此外，SQL Server优化查询语句时，查询优化器也会考虑这个问题，这就导致一系列性能问题。要理解什么事实重复索引、怎么样找到它们
大家好，又见面了，我是你们的朋友全栈君。创建索引视图 视图也称为虚拟表，这是因为由视图返回的结果集其一般格式与由列和行组成的表相似，并且，在 SQL 语句中引用视图的方式也与引用表的方式相同。标准视图的结果集不是永久地存储在数据库中。查询每次引用视图时，Microsoft® SQL Server™ 2000 会动态地将生成视图结果集所需的逻辑合并到从基表数据生成完整查询结果集所需的逻辑中。生成视图结果的过程称为视图具体化。有关更多信息，请参见视图解析。 对于标准视图而言，为每个引用视图的查询动态生成结果集的开销很大，特别是对于那些涉及对大量行进行复杂处理（如聚合大量数据或联接许多行）的视图更为可观。若经常在查询中引用这类视图，可通过在视图上创建唯一聚集索引来提高性能。在视图上创建唯一聚集索引时将执行该视图，并且结果集在数据库中的存储方式与带聚集索引的表的存储方式相同。有关用于存储聚集索引的结构的更多信息，请参见聚集索引。 说明 只有安装了 Microsoft SQL Server 2000 企业版或 Microsoft SQL Server 2000 开发版，才可以创建索引视图。 在视图上创建索引的另一个好处是：查询优化器开始在查询中使用视图索引，而不是直接在 FROM 子句中命名视图。这样一来，可从索引视图检索数据而无需重新编码，由此带来的高效率也使现有查询获益。有关更多信息，请参见在视图上使用索引。 在视图上创建聚集索引可存储创建索引时存在的数据。索引视图还自动反映自创建索引后对基表数据所做的更改，这一点与在基表上创建的索引相同。当对基表中的数据进行更改时，索引视图中存储的数据也反映数据更改。视图的聚集索引必须唯一，从而提高了 SQL Server 在索引中查找受任何数据更改影响的行的效率。 与基表上的索引相比，对索引视图的维护可能更复杂。只有当视图的结果检索速度的效益超过了修改所需的开销时，才应在视图上创建索引。这样的视图通常包括映射到相对静态的数据上、处理多行以及由许多查询引用的视图。 视图的要求 在视图上创建聚集索引之前，该视图必须满足下列要求： 当执行 CREATE VIEW 语句时，ANSI_NULLS 和 QUOTED_IDENTIFIER 选项必须设置为 ON。OBJECTPROPERTY 函数通过 ExecIsAnsiNullsOn 或 ExecIsQuotedIdentOn 属性为视图报告此信息。 为执行所有 CREATE TABLE 语句以创建视图引用的表，ANSI_NULLS 选项必须设置为 ON。 视图不能引用任何其它视图，只能引用基表。 视图引用的所有基表必须与视图位于同一个数据库中，并且所有者也与视图相同。 必须使用 SCHEMABINDING 选项创建视图。SCHEMABINDING 将视图绑定到基础基表的架构。 必须已使用 SCHEMABINDING 选项创建了视图中引用的用户定义的函数。 表和用户定义的函数必须由 2 部分的名称引用。不允许使用 1 部分、3 部分和 4 部分的名称。 视图中的表达式所引用的所有函数必须是确定性的。OBJECTPROPERTY 函数的 IsDeterministic 属性报告用户定义的函数是否是确定性的。有关更多信息，请参见确定性函数和非确定性函数。 视图中的 SELECT 语句不能包含下列 Transact-SQL 语法元素： 选择列表不能使用 * 或 table_name.* 语法指定列。必须显式给出列名。 不能在多个视图列中指定用作简单表达式的表的列名。如果对列的所有（或只有一个例外）引用是复杂表达式的一部分或是函数的一个参数，则可多次引用该列。例如，下列选择列表是非法的： SELECT ColumnA, ColumnB, ColumnA 下列选择列表是合法的： SELECT ColumnA, AVG(ColumnA), ColumnA + Column B AS AddColAColB SELECT SUM(ColumnA), ColumnA % ColumnB AS ModuloColAColB 派生表。 行集函数。 UNION 运算符
概念简介 我们平时所说的查询在SQLServer 中主要有两部分来实现： 编译查询，主要包括了五个环节（缓存查找、分析、代数化、优化、缓存新计划） 流程描述： 首先，在计划缓存中查找是
一条SQL，在数据库中是如何执行的呢？相信很多人都会对这个问题比较感兴趣。当然，要完整描述一条SQL在数据库中的生命周期，这是一个非常巨大的问题，涵盖了SQL的词法解析、语法解析、权限检查、查询优化、SQL执行等一系列的步骤，简短的篇幅是绝对无能为力的。因此，本文挑选了其中的部分内容，也是我一直都想写的一个内容，做重点介绍：
数据库到底有多重要？作为数据分析人员需要懂点数据库，作为开发者需要懂点数据库，作为行业从业者，或者一个专业从事运维的DBA，更是要对数据库了如指掌。 这次我尝试着写了9道常见的MySQL面试题，内容主要从面试角度出发，会涉及比较多很重要的基础知识，对于这类知识，不仅仅要知道，还要能够讲清楚，不够熟悉的小白可以查缺补漏，足够资深的大牛也可以看看对这些知识有没有烂熟于心。如果不知道嘛……出门别说自己是DBA…… 1 关系型数据库和非关系型数据库区别 非关系型数据库（感觉翻译不是很准确）称为 NoSQL，也
实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别：
由于是个人凭着自己理解总结的，因此可能不一定精确，但是毋庸置疑的是，在当代，各大公司机构部门的数据都是维护在数据库当中的。数据库作为数据存储介质发展的最新产物，必然是具有许多优点的，其中一个很大的优点就是存储在数据库中的数据访问速度非常快。数据库访问速度快的一个很重要的原因就在于索引index的作用。也就是这篇文章的主要想介绍的内容，为什么索引可以让数据库查询变快？
如果这条sql是写操作(insert、update、delete)，那么大致的过程如下，其中引擎层是属于 InnoDB 存储引擎的，因为InnoDB 是默认的存储引擎，也是主流的，所以这里只说明 InnoDB 的引擎层过程。由于写操作较查询操作更为复杂，所以先看一下写操作的执行图。方便后面解析。
从字面意思理解，首先数据库是一个存放东西的库，里面存的东西是数据。以下解释来自百度百科：
1、普通索引：经过设计的数据结构； 2、唯一索引：唯一约束； 3、主键索引（唯一索引的一种）：唯一约束+非空约束； 4、全文索引：创建的时候要制定索引长度。
MySQL 一直是本人很薄弱的部分，后面会多输出 MySQL 的文章贡献给大家，毕竟 MySQL 涉及到数据存储、锁、磁盘寻道、分页等操作系统概念，而且互联网对 MySQL 的注重程度是不言而喻的，后面要加紧对 MySQL 的研究。写的如果不好，还请大家见谅。
背景 数据库中有一张叫后宫佳丽的表,每天都有几百万新的小姐姐插到表中,光阴荏苒,夜以继日,日久生情,时间长了,表中就有了几十亿的小姐姐数据,看到几十亿的小姐姐,每到晚上,我可愁死了,这么多小姐姐,我翻
Join的实现算法有三种，分别是Nested Loops Join, Merge Join, Hash Join。 DB2、SQL Server和Oracle都是使用这三种方式，不过Oracle选择使用nested loop的条件跟SQL Server有点差别，内存管理机制跟SQL Server不一样，因此查看执行计划，Oracle中nested loops运用非常多，而merge和hash方式相对较少，SQL Server中，merge跟hash方式则是非常普遍。 一.Nested Loopsb Join
一、深入浅出理解索引结构 实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别： 其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。 二、何时使用聚集索引或非聚集索引 下面的表总结了何时使用聚集索引或非聚集索引(很重要)。 动作描述使用聚集索引 使用非聚集索引 外键列 应 应 主键列 应 应 列经常被分组排序(order by) 应 应 返回某范围内的数据 应 不应 小数目的不同值 应 不应 大数目的不同值 不应 应 频繁更新的列不应 应 频繁修改索引列 不应 应 一个或极少不同值 不应 不应
| 作者 沈启超，19年硕士毕业于东南大学，目前在腾讯CSIG企业产品部担任后台开发，同时也参与公司内部存储开源组件MySync的开发。 ---- 前言：MySQL架构体系 首先分享实验前的基础知识，MySQL主要分为Server层与存储引擎层。 Server层主要包含连接器、检索内存、分析器、优化器、执行器等，所有跨存储引擎的功能均于这一层构建，例如存储过程、触发器、视图，函数等，有一个标准化的binglog日志模块。 存储引擎负责数据的存储与存取，使用可更换的插件式架构，拥有InnoDB、MyISA
三歪最近发现我一直在写MySQL的文章，然后就跟我说他有sql用到like的时候就没办法用到索引了，问我怎么办。
学习 SQL 的时候，大家肯定第一个先学到的就是 select 查询语句了，比如下面这句查询语句：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
