Clustered Index - kitlau's blog

JUL

【译】数据是如何存储在 SQL 数据库中

数据在SQL Server中的物理存储方式远比我们想象的复杂而精妙。当开发者试图优化查询性能时，理解数据页（8KB的基本存储单元）与B树结构（聚集索引）的运作机制至关重要。文章揭示了数据页如何将逻辑上的行与列转化为物理存储的8KB块，并通过树状层级结构组织数据——根节点、中间层与叶节点共同构成了高效的数据检索路径。聚集索引的主键决定了物理存储的排序逻辑，使得数据页中的行按EmployeeId等键值严格排列，而索引行通过指针形成导航网络，让数据库引擎能快速定位目标数据。但这种结构背后隐藏着哪些值得深思的问题？当数据量激增时，中间层节点的增殖是否会影响查询效率？8KB数据页的固定大小如何平衡存储密度与寻址效率？聚集索引的主键选择是否会对存储结构产生不可逆的影响？例如当主键是自增ID时，数据页的物理填充模式是否与随机UUID主键存在本质差异？更进一步思考，非聚集索引与聚集索引的存储结构差异是否暗示了索引设计的哲学——是优先保证数据的物理连续性，还是牺牲存储效率换取查询速度？或许我们从未真正思考过：当SQL Server返回第一条记录时，它究竟经历了怎样的寻址旅程？而当数据页的96%空间被行数据占据时，剩余的4%是否暗藏着数据库设计的妥协与智慧？这些问题的答案，或许就藏在数据页的结构细节与B树的层级设计之中。你是否愿意重新审视那些看似理所当然的数据库操作，去发现它们背后精密的数学与工程之美？--Qwen3

DB Data Storage B Tree Clustered Index Data Page Root Node

JUL

【译】SQL 索引是如何工作的

这篇文章通过图文解析深入浅出地揭示了数据库索引的底层逻辑，从索引的物理存储结构到查询性能优化的完整链条。作者以SQL Server的执行计划为切入点，通过对比聚集索引的有序数据存储（EmployeeId作为聚集键）与非聚集索引的逻辑键值定位（Name字段索引），清晰展示了两种索引在数据检索时的协作关系——非聚集索引如同目录指引，最终需要借助聚集索引定位实际数据。文章通过百万级数据的查询成本对比（100万行扫描vs 1次键查找），直观呈现了索引扫描（Scan）与索引查找（Seek）的性能天差地别。特别值得关注的是对执行计划中Index Seek、Key Lookup和Nested Loops操作的逐层拆解，揭示了非聚集索引如何通过"二级查找"机制定位数据。这种从存储结构到查询优化的系统性讲解，不仅解答了"为什么主键默认有索引"等常见疑惑，更启发思考如何通过索引设计平衡查询效率与写入成本，为数据库性能优化提供了可落地的理论框架。--Qwen3

DB Clustered Index Database Index Non Clustered Index Execution Plan Query Optimization