表连接
INNER JOIN：如果表中有至少一个匹配，则返回行
LEFT JOIN：即使右表中没有匹配，也从左表返回所有的行
RIGHT JOIN：即使左表中没有匹配，也从右表返回所有的行
FULL JOIN：只要其中一个表中存在匹配，则返回行
索引
一般来说，应该在这些列上创建索引：
- 主键列，强制该列的唯一性和组织表中数据的排列结构；
- 外键列，可以加快连接的速度；
- 经常需要搜索的列，可加快搜索速度；
- 经常需要排序的列，利用索引的排序，加快排序查询时间；
- 经常需要根据范围进行搜索的列，索引已经排序，其指定的范围是连续的；（聚集）
- 经常使用在WHERE子句中的列，加快条件的判断速度。
- 经常出现在order by、group by、distinct后面的字段，建立索引。如果建立的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，否则索引不会被使用。
- 经常更新的列（非聚集索引）
- 小数目的不同值（建议聚集索引）
- 大数目的不同值（建议非聚集索引）
一般来说，不应该在这些列上创建索引：
- 在查询中很少使用列。有索引并不能提高查询速度，反而降低了系统的维护速度和增大了空间需求。
- 只有很少数据值的列。由于这些列的取值很少，在查询的结果中，需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
- 定义为text, image和bit数据类型的列。这些列的数据量要么相当大，要么取值很少。
- 当修改性能远远大于检索性能时，不应该创建索引。修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。
- 重复值比较多的列不要建立索引
- 经常存取的列避免建立索引
根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。
尽管唯一索引有助于定位信息，但为获得最佳性能结果，建议改用主键或唯一约束。
唯一索引 UNIQUE
唯一索引是不允许其中任何两行具有相同索引值的索引。
既可以采用聚集索引结构，也可以采用非聚集索引的结构，如果不指明采用的索引结构，则SQL Server系统默认为采用非聚集索引结构
当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。
主键索引
数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。
在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。
聚集索引CLUSTERED、NONCLUSTERED
在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。
非聚集索引，表中行的物理顺序与键值的逻辑顺序不匹配，相比之下，聚集索引通常提供更快的数据访问速度。
语法
CREATE [UNIQUE][CLUSTERED | NONCLUSTERED] INDEX index_name
ON {table_name | view_name} [WITH [index_property [,....n]]
DROP INDEX table_name.index_name[,table_name.index_name]
总结
限制表上的索引数目。存在大量更新操作的表，所建索引的数目一般不超过3个，最多5个。索引虽说提高了访问速度，但太多索引会影响数据的更新操作。
in、or子句常会使用工作表，使索引失效
如果不产生大量重复值，可以考虑把子句拆开
拆开的子句中应该包含索引
任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
用B-Tree作为索引结构效率是非常高的，应该花时间学习B-树和B+树数据结构
为什么使用B+树？
1.文件很大，不可能全部存储在内存中，故要存储到磁盘上
2.索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数（为什么使用B-/+Tree，还跟磁盘存取原理有关，具体看下边分析）
3. 局部性原理与磁盘预读，预读的长度一般为页（page）的整倍数，（在许多操作系统中，页得大小通常为4k）
4. 数据库系统巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样 每个节点只需要一次I/O 就可以完全载入，(由于节点中有两个数组，所以地址连续)。而红黑树这种结构， h 明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性