聚集索引

面试的时候，发现数据库方面，忘得一塌糊涂，抽时间整理了一些数据库方面的题。 事务四大特性（ACID）原子性、一致性、隔离性、持久性？ 事务的并发？事务隔离级别，每个级别会引发什么问题，MySQL 默认是哪个级别？ MySQL 常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别？ MySQL 的 MyISAM 与 InnoDB 两种存储引擎在，事务、锁级别，各自的适用场景？ 查询语句不同元素（where、jion、limit、group by、having 等等）执行先后顺序？ 什么是临时表，临时表什么时候删除? MySQL B+Tree 索引和 Hash 索引的区别？ 聚集索引和非聚集索引区别？ 有哪些锁（乐观锁悲观锁），select 时怎么加排它锁？ 非关系型数据库和关系型数据库区别，优势比较？ 数据库三范式，根据某个场景设计数据表？ 数据库的读写分离、主从复制，主从复制分析的 7 个问题？ 使用 explain 优化 sql 和索引？ MySQL 慢查询怎么解决？ 什么是 内连接、外连接、交叉连接、笛卡尔积等？ mysql 都有什么锁，死锁判定原理和具体场景，死锁怎么解决？ varchar 和 char 的使用场景？ mysql 高并发环境解决方案？ 数据库崩溃时事务的恢复机制（REDO 日志和 UNDO 日志）？ 事务四大特性（ACID）原子性、一致性

其实对于非专业的数据库操作人员来讲，例如软件开发人员，在很大程度上都搞不清楚数据库索引的一些基本知识，有些是知其一不知其二，或者是知其然不知其所以然。造成这种情况的主要原因我觉的是行业原因，有很多公司都有自己的DBA团队，他们会帮助你优化SQL，开发人员即使不懂优化问题也不大，所以开发人员对这方面也就不会下太多功夫去了解SQL优化，但如果公司没有这样的DBA呢，就只能靠程序员自己了。 最近突然想起前一阵和一朋友的聊天，当时他问我的问题是一个非常普通的问题：说说SQL聚集索引和非聚集索引的区别。 大家可能认为这个问题难度不大，认为太熟悉了，也许不会感兴趣，但你真能说清楚吗？其实要想说明白这两者的差别也不是三两句就说的清的，那天我也是觉的这问题太泛了，就随便说了其中的两个区别： 聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个，这个跟没问题没差别，一般人都知道。 聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续，这个大家也都知道。 上面的两点从大的方面讲都是讲的通的，后面我们继续探讨，举一个实际点的例子，一个学生表student，里面是学生号id,学生姓名，学生所在城市ID，学生成绩(总分)。 问：如果想按姓名查询，如何做优化？ 答：在姓名字段上建立索引。 问：建立什么类型的索引？ 答：建立非聚集索引。 问：为什么？ 答：一般有范围查询的需求

实验案例一：验证索引的作用 1、首先创建一个数据量大的表，名称为“学生表”，分别有三列，学号，姓名和班级，如下图所示，学号为自动编号，班级为默认值“一班”。 2、向表中插入大量数据，数据越多，验证索引的效果越好。 使用语句完成：While 1>0 Insert into 学生表(姓名) values(‘于美丽’) 上面语句是一个死循环，除非强制结束，如果1大于0就会一直向表中插入姓名 如下图所示： 等待5分钟左右，打开表的属性，查看表的行数，当前为1032363，如下图所示： 3、 使用语句查询第900000行的数据，Select * from 学生表 Where 学号=900000 4、打开“sql server profiler ”工具进行跟踪，如下图所示： 打开“sql server profiler ”工具查看跟踪的信息，发现查询时间很长，cpu工作了265毫秒，reads：读了8649次，writes：写了10次，duration：总计花费2336毫秒完成查询。 为了下面分析文件更准确，多执行几次Select* from 学生表 Where 学号=900000 然后把跟踪的结果保存在桌面上： 5、打开“数据库引擎优化顾问”，添加跟踪文件，进行分析，发现索引建议，需要建立索引。 注意选择benet数据库中的学生表，然后点击“开始分析” 索引类型为clusterd（聚集索引）

摘自 http://www.cnblogs.com/ATree/archive/2011/02/13/sql_optimize_1.html 1、 首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么？ (2) 查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、 统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 select*from dual select*From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、 不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的

索引结构（Index Structure） 所有的SQL Server 索引都是 B-Trees 。在这种树的顶端有一个 根页（root page） ，通过root page来访问N个 中级（intermediate level）页 ，直到树的底部、或 叶级（leaf level） 。可以通过树中每个节点的指针从上向下扫描整个索引树。另外，每个索引级（index leves）（可能是intermediate leve or leaf level）都有一个页链（page chain）。在一个索引中有许多intermediate level。索引树的级数（树的高度）与索引码的宽度、索引类型、记录行数和表中的页数有关，并且索引树的级数是影响索引性能的一个重要参数。 非聚集索引（Nonclustered Indexs） 一个非聚集索引 与一本书的索引相似。数据存储在一个地方，索引存储在另外一个地方 ，可以通过索引中的指针来访问存储的数据。索引中的条目是按照索引码的值按序存储，但是表中的信息可以按照不同的顺序存储（如可以按照聚集索引存储）。如果表中没有创建聚集索引，那么表中的记录就不能保证按照某种特定的顺序。 与你用一本书的索引方式一样，SQL Server2000也是先通过非聚集索引检索到查找数据在表的位置，然后通过该位置来检索数据。 这使得非聚集索引非常适合精确匹配查询（This

索引基础 索引介绍 定义 索引是满足某种特定查找算法的数据结构。这些数据结构会以某种方式指向数据，从而实现高效查找。 优势 提高了查询速度 劣势 降低更新表的速度，因为更新表时，MySQL不仅要保存数据，还要保存索引文件。 建立索引会占用磁盘空间的索引文件。 索引分类 主键索引 根据主键pk_column（length）建立索引， 不允许重复，不允许空值 。 ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col'); 唯一索引UNIQUE 用来建立索引的列的值必须是 唯一的，允许空值 。 ALTER TABLE 'table_name' ADD UNIQUE INDEX index_name('col'); 普通索引 用 普通列 构建的索引，没有任何限制。 ALTER TABLE 'table_name' ADD INDEX index_name('col'); 组合索引 用多个列组合构建的索引，这多个列中的值不允许有空值。 ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3'); 遵循“最左前缀”原则，把最常用作为检索或排序的列放在最左，依次递减，组合索引 相当于建立了col1，[col1,col2]，[col1,col2,col3]三个索引

1. InnoDB存储引擎体系架构 innoDB的存储引擎主要体系结构如上图所示 首先是工作线程：默认7个后台线程，分别是4个io thread(insert buffer、log、read、write),1个master thread(优先级最高),1个锁(lock)监控线程，1个错误监控线程。可以通过show engine innodb status来查看。新版本已对默认的read thread和write thread分别增大到4个，可通过show variables like 'innodb_io_thread%'查看。 每个线程操作的同一个块大内存池：该内存池中会被分为多个区域，分别是缓冲池(buffer pool)、重做日志缓冲池(redo log buffer)以及额外的内存池(additional memory pool)。内存池所负责也就是维护线程需要访问的数据结构、缓存磁盘文件的数据，方便快速读取，同时在对磁盘文件的数据修改之前在这里缓存，以及重做日志缓存等。具体配置可由 show variables like 'innodb_buffer_pool_size' 、 show variables like 'innodb_log_buffer_size' 、 show variables like 'innodb_additional_mem_pool_size

文章目录 概念 有什么用？ 分类 物理存储顺序 逻辑存储 数据类型 b+ tree 索引列 存储引擎支持 Innodb Myisam 使用技巧 建索引 用索引 优化分析 常见面试题 参考文章 概念 mysql index官方文档 索引是数据库管理系统中一种数据结构，用以协助快速查询数据库表中数据，典型的索引结构如B+ tree。 有什么用？ MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。 打个比方，如果合理的设计且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。 拿汉语字典的目录页（索引）打比方，我们可以按拼音、笔画、偏旁部首等排序的目录（索引）快速查找到需要的字。 分类 物理存储顺序 MySQL的 Innodb 存储引擎的索引分为聚集索引和非聚集索引(二级索引)。 聚集索引是Innodb引擎才有的概念。 为什么说是按照物理存储顺序分类呢？因为聚集索引的逻辑顺序就是数据记录的物理顺序，而非聚集索引却不是如此。 举个例子，聚集索引就像是汉语字典中的拼音索引，字典中的字就是按照这个顺序存的。非聚集索引就像是部首索引，相同偏旁的字在索引页上是相邻的，但是真实的位置却不一定是相邻的。类似的例子还有电话簿，大家自行想象一下。 聚集索引怎么选定呢？ 第一个唯一且不能为NULL的列就会被选为聚集索引

1.什么是B-Tree 和 B+Tree，他们是做什么用的？ B-Tree是为了磁盘或其它存储设备而设计的一种 多叉平衡查找树 ，B-Tree 和 B+Tree 广泛应用于文件存储系统以及 数据库 系统中。 在大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，树的高度就会增大，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于 树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下 （为什么会出现这种情况？这跟外部存储器-磁盘的存储方式有关）。那么该如何减少树的高度呢？一个基本的想法就是：采用 多叉树 结构（每个节点存放多个元素，每个节点有多个子节点，这样树的高度就降低了）。根据平衡二叉树的启发，自然就想到平衡多路查找树结构。B-Tree的各种操作能使B-Tree保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率。 2.B-Tree 2.1定义 m阶B-Tree满足以下条件： 1、每个节点最多拥有m个子树 2、根节点至少有2个子树 3、分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点） 4、所有叶子节点都在同一层 5、每个节点最多可以有m-1个key 6、每个节点中的key以升序排列 7、节点中key元素左节点的所有值都小于或等于该元素

1.什么是B-Tree 和 B+Tree，他们是做什么用的？ B-Tree是为了磁盘或其它存储设备而设计的一种 多叉平衡查找树 ，B-Tree 和 B+Tree 广泛应用于文件存储系统以及数据库系统中。 在大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，树的高度就会增大，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于 树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下 （为什么会出现这种情况？这跟外部存储器-磁盘的存储方式有关）。那么该如何减少树的高度呢？一个基本的想法就是：采用 多叉树 结构（每个节点存放多个元素，每个节点有多个子节点，这样树的高度就降低了）。根据平衡二叉树的启发，自然就想到平衡多路查找树结构。B-Tree的各种操作能使B-Tree保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率。 2.B-Tree 2.1定义 m阶B-Tree满足以下条件： 1、每个节点最多拥有m个子树 2、根节点至少有2个子树 3、分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点） 4、所有叶子节点都在同一层 5、每个节点最多可以有m-1个key 6、每个节点中的key以升序排列 7、节点中key元素左节点的所有值都小于或等于该元素