SQL

在前面一篇文章，介绍了索引的结构，并解释了慢索引的原因。 下面会介绍如何发现并避免这些问题，先从 where 语句开始。 where 语句定义了 SQL 的搜索条件，因此它属于索引的核心功能范畴：快速寻找数据。 即使 where 语句对性能有很大影响，但它常常被随意使用，导致数据库不得不扫描索引的大部分内容。 结果导致：一个编写不当的 where 子句是导致查询缓慢的首要因素。 本章解释不同运算符如何影响索引的使用，以及如何确保索引能适用于尽可能多的查询。 The Equality Operator 等号是 SQL 中最简单也最常用的符号。 影响性能的索引错误仍然非常普遍，尤其是结合多个条件的 where 子句中，这种错误尤为常见。 本章展示如何验证索引的使用，并解释如何通过连接索引 combined conditions 来优化组合条件。 Primary Keys 下面从最简单的 where 子句开始：主键查询。 这里使用 EMPLOYEES 表做示例： CREATE TABLE employees ( employee_id NUMBER NOT NULL, first_name VARCHAR(1000) NOT NULL, last_name VARCHAR(1000) NOT NULL, date_of_birth DATE NOT NULL, phone_number VARCHAR(1000) NOT NULL, CONSTRAINT employess_pk PRIMARY KEY (employee_id) ); 数据库会自动为主键创建索引，这意味着 employee_id 列会有一个索引，即使没有 create index 语句。 ...

Index 索引是数据库中一个独特的结构，通过使用 create index 语句来构建。 这意味着一个索引是冗余的，创建索引不会改变表数据。 它会创建一个新的数据结构，并指向该表。 总而言之，索引有自己的空间，且高度冗余 redundant，并指向存储在不同位置的实际信息。 Clustered Indexes SQL Server 和 Mysql (InnoDB) 对索引是什么有更加广泛的视角。 它们将完全由索引结构构成的表，称为聚集索引 clustered indexes。 这些表在 Oracle 叫 Index Organized Tables (IOT)。 搜索数据库索引就像查找电话目录一样，核心思想是所有实例都是按顺序排列的。 查找有序的数据快速且简单，因为顺序决定了条目位置。 数据库索引比电话目录更加复杂一些，因为它会不断变化。 每次变化都去修改目录是不可行的，因为实体之间没有额外空间。 目录修改一般会等到累计到足够的变化后再处理，而数据库等不了那么久， 它必须处理 insert 插入，delete 删除和 update 更新。 数据库结合了两种数据结构来应对挑战： 双向链表 double linked list 和搜索树 search tree，这两种结构解释了数据库的大部分性能特征。 The Index Leaf Nodes 索引的首要目标是提供索引数据的排序表示。 然而，由于插入语句 insert statement 需要为新的数据移动后续条目。 移动大量数据是十分耗时的，这样会导致 insert 插入语句很慢。 解决方案是建立一个独立于内存物理顺序的逻辑顺序。 逻辑顺序通过双向链表建立，每个头都有指向两侧邻居的指针。 新 node 插入的时候，修改两侧的指针指向。 node 的物理地址不重要，因为双向链表维护的是逻辑顺序。 数据库使用双向链表来连接所谓是索引叶节点 leaf nodes。 每个叶节点存储在一个数据库块 database block 或叶 page 中，即数据库的最小存储单元。 每块都是一样的大小，通常几千字节 kilobytes。 数据库会尽可能利用每个块的空间，并在每个块中存储尽可能多的索引条目。 这意味着索引顺序在两个层面维护：每个叶节点内的索引条目，以及叶节点之间通过双向链表连接。 ...