SQL语言艺术 (2010 年度畅销榜NO.5465 )

本书分为12章，每一章包含许多原则或准则，并通过举例的方式对原则进行解释说明。这些例子大多来自于实际案例，对九种SQL经典查询场景以及其性能影响讨论，非常便于实践，为你的实际工作提出了具体建议。本书适合SQL数据库开发者、软件架构师，也适合DBA，尤其是数据库应用维护人员阅读。

Contents
前言 I
1 制定计划：为性能而设计 1
数据的关系视图 2
规范化的重要性 4
有值、无值、空值 11
限用Boolean型字段 14
理解子类型（Subtype） 15
约束应明确声明 17
过于灵活的危险性 18
历史数据的难题 19
设计与性能 21
处理流程 22
数据集中化（Centralizing） 23
系统复杂性 24
小结 25
2 发动战争：高效访问数据库 27
查询的识别 28
保持数据库连接稳定 29
战略优先于战术 31
先定义问题，再解决问题 32
保持数据库Schema稳定 33
直接操作实际数据 34
用SQL处理集合 34
动作丰富的SQL语句 35
充分利用每次数据库访问 36
接近DBMS核心 37
只做必须做的 41

SQL语句反映业务逻辑 42
把逻辑放到查询中 42
一次完成多个更新 43
慎用自定义函数 44
简洁的SQL 46
SQL的进攻式编程 48
精明地使用异常（Exceptions） 50
3 战术部署：建立索引 55
找到“切入点” 56
索引与目录 59
让索引发挥作用 60
函数和类型转换对索引的影响 62
索引与外键 67
同一字段，多个索引 69
系统生成键 70
索引访问的不同特点 72
4 机动灵活：思考SQL语句 75
SQL的本质 76
掌握SQL艺术的五大要素 84
过滤 89
5 了如指掌：理解物理实现 105
物理结构的类型 106
冲突的目标 108
把索引当成数据仓库 109
记录强制排序 113
数据自动分组（Grouping） 115
分区是双刃剑 119
分区与数据分布 120
数据分区的最佳方法 121
预连接表 123
神圣的简单性 124


6 锦囊妙计：认识经典SQL模式 127
小结果集，直接条件 129
小结果集，间接条件 137
多个宽泛条件的交集 138
多个间接宽泛条件的交集 140
大结果集 146
基于一个表的自连接 147
通过聚合获得结果集 150
基于日期的简单搜索或范围搜索 156
结果集和别的数据存在与否有关 161
7 变换战术：处理层次结构 167
小结果集，直接条件 129
小结果集，间接条件 137
多个宽泛条件的交集 138
多个间接宽泛条件的交集 140
大结果集 146
基于一个表的自连接 147
通过聚合获得结果集 150
基于日期的简单搜索或范围搜索 156
结果集和别的数据存在与否有关 161
8 孰优孰劣：认识困难，处理困难 199
看似高效的查询条件 200
抽象层 202
分布式系统 205
动态定义的搜索条件 208
9 多条战线：处理并发 225
数据库引擎作为服务提供者 226
并发修改数据 231
10 集中兵力：应付大数据量 247
增长的数据量 248
数据仓库 264


11 精于计谋：挽救响应时间 279
数据的行列转换 280
基于变量列表的查询 294
基于范围的聚合 297
一般规则，最后使用 299
查询与列表中多个项目相符的记录 301
最佳匹配查询 304
优化器指令 305
12 明察秋毫：监控性能 307
数据库速度缓慢 308
服务器负载因素 310
何谓“性能优良” 311
从业务任务角度思考 317
执行计划 319
合理运用执行计划 328
总结：影响性能的重要因素 330
Photo Credits 333
索引 335

过去，“信息技术（IT）”的名字还不如今天这般耀眼，被称为“电子数据处理”。其实，尽管当今新潮技术层出不穷，数据处理依然处于我们系统的核心地位，而且需管理的数据量的增长速度似乎比处理器的增长速度还快。今天，最重要的集团数据都被保存在数据库中，通过SQL语言来访问。SQL语言虽有缺点，但非常流行，它从1980年代早期开始被广泛接受，随后就所向无敌了。 如今，年轻开发者在接受面试时，没有谁不宣称自己能熟练应用SQL的。SQL作为数据库访问语言，已成为任何基础IT课程的必备部分。开发者宣传自己熟练掌握SQL，其实前提是“熟练掌握”的定义是“能够获得功能上正确的结果”。然而，全世界的企业如今都面临数据量的爆炸式增长，所以仅做到“功能正确”是不够的，还必须足够快，所以数据库性能成了许多公司头疼的问题。有趣的是，尽管每个人都认可性能问题源自代码，但普遍接受的事实则是开发者的首要关注点应该是功能正确。人们认为：为了便于维护，代码中的数据库访问部分应该尽量简单；“拙劣的SQL”应该交给资深的DBA去摆弄，他们还会调整几个“有魔力”的数据库参数，于是速度就快了——如果数据库还不够快，似乎就该升级硬件了。 往往就是这样，那些所谓的“常识”和“可靠方法”最终却是极端有害的。先写低效的代码、后由专家调优，这种做法实际上是自找麻烦。本书认为，首先要关注性能的就是开发者，而且SQL问题绝不仅仅只包含正确编写几个查询这么简单。开发者角度看到的性能问题和DBA从调优角度看到的大相径庭。对DBA而言，他尽量从现有的硬件（如处理器和存储子系统）和特定版本的DBMS获得最高性能，他可能有些SQL技能并能调优一个性能极差的SQL语句。但对开发者而言，他编写的代码可能要运行5到10年，这些代码将经历一代代的硬件，以及DBMS各种重要版本升级（例如支持互联网访问、支持网格，不一而足）。所以，代码必须从一开始就快速、健全。很多开发者仅仅是“知道”SQL而已，他们没有深刻理解SQL及关系理论，实在令人遗憾。

无封面