kitlau
kitlau

kitlau's blog

DB 数据库

18
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
18
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
20
MAR

金鱼也能看懂的 Postgres 和 MySQL 选择指南

在这篇关于PostgreSQL与MySQL的对比指南中，作者用通俗比喻与技术解析双线交织的方式，揭示了两种数据库系统的本质差异与适用场景。通过"水族馆"的隐喻，将技术特性转化为可感知的生态特征——PostgreSQL如同具备多重生态位适应能力的深海生物，其多版本并发控制、复杂查询优化和扩展性设计，使其在数据完整性要求高、查询逻辑复杂的场景中展现出独特优势；而MySQL则像擅长短距离冲刺的洄游鱼类，凭借轻量级架构和快速响应能力，在高并发读写场景中独树一帜。文章不仅对比了两者在JSON支持、事务处理、安全性等技术维度的差异，更深入探讨了选择数据库时需要考量的深层因素：当开发者面对"功能扩展性"与"部署便捷性"的二元选择时，是应该像珊瑚礁生态一样追求多样性，还是像单细胞生物一样专注效率？当业务规模从小型鱼缸扩展到海洋生态时，数据库架构的可进化能力是否与系统复杂度呈正相关？这些引发思考的设问，引导读者重新审视数据库选择与业务发展的动态关系。最终，文章指出没有绝对优劣的数据库，只有适配特定需求的解决方案，这种开放性的结论既符合技术实践的现实，也为读者在真实场景中做出决策提供了思维框架。--Qwen3

DB PostgreSQL MySQL ACID Compliance OLTP Advanced Features
  • 1