第0章　引言

笔者早年间从事了多年开发工作，后因个人兴趣转做数据库。在长期的工作实践中，看到了数据库工作（特别是SQL优化）面临的种种问题，同时也发现人们在对数据库优化的认识上存在一些误区。

1.面临的问题

·没有专职人员：很多公司或者说绝大多数公司没有独立的数据库团队，往往由开发人员完成部分DBA的职责，包括结构设计、SQL优化甚至部分运维工作，受限于自身的精力，开发人员很难做到专业化。

·“赶工期”现象：在项目驱动的公司，经常出现赶工期的现象，而且往往牺牲的就是数据库的设计、评测、优化时间。常常只是开发完毕后就匆忙上线，直到在线上运行出现问题后才会回头进行处理，但这时往往已经造成了很大的损失。

·话语权不大：数据库团队在公司中或者在项目中往往话语权不高。在很多产品、项目决策过程中，常常会忽略DBA的声音。

·需求不明：很多项目在设计初期往往对业务描述很详尽，但对数据库却只字未提。相关数据库的存储量、访问特征、高峰时间的TPS及QPS等往往只有到上线后才有比较清晰的认识。其后果就是需要大量优化工作，甚至导致需要对底层架构进行修改，这样最终会导致成本大大提高，有时增加的成本甚至是不可接受的。

·重运维、不重架构设计：有些公司认识到数据库的重要性，但往往只重视运维而忽视了前期的架构设计、开发优化等问题。系统上线暴露出问题后，只能采取事后补救措施，但这往往会带来高昂的成本。

·盲目优化：有些公司确实很重视SQL优化工作，但又缺乏必要的技术投入。经常见到这样的开发规范——所有WHERE条件字段都必须加上索引。其结果就是数据库被“过分”优化，适得其反。

2.常见误区

·关系型数据库已死：近些年来，随着NoSQL的蓬勃发展，有一种观点也逐渐盛行——关系型数据库必将死亡，NoSQL将取而代之！随之而来的就是SQL优化没有必要，不必在其上再花费很大力气。NoSQL作为一种新兴的技术，的确有其鲜明的特点，也适用于一些场合。但我们要看到，很多需要ACID的场景，传统数据库仍然是不二选择，不可取代。

·“SQL优化”很简单：有些人认为，SQL优化很简单，甚至碰到过这种观点——SQL优化不就是加几个索引嘛，有啥难的！其带来的直接后果就是，不重视这部分工作。笔者也确实在某业务系统（OLTP）中观察到单表存在30多个索引的情况，也遇到过因为索引过多导致执行性能出现问题的情况。这种情况，往往只有在出事故后才能引起领导的重视。

·硬件技术发展很快，不用再计较SQL优化：硬件技术近些年来发展迅速，特别是以多核CPU为代表的并行处理技术和以SSD为代表的存储技术的使用，使得服务器的处理能力有了极大的提升。但我们清醒地看到，SQL优化才是问题的根本解决之道。后面可以看到，一条SQL语句可以轻易跑死一个数据库。这不是简单地通过硬件升级就可以解决的问题。

·SQL优化只是DBA的事情：在很多设计、开发、测试人员的眼中，SQL优化只是DBA的事情，他们不需要去关心。落实到具体工作中，相关人员就缺乏相应的优化意识，只注重自身功能的实现而忽略了相应的执行成本。最终的结果往往就是代码质量不高，上线后问题多。

·数据仓库都使用Hadoop，不用传统关系型数据库了：Hadoop作为一种新兴技术，被越来越多地用在数据分析领域，很多国内外的大型公司都采用了这个解决方案。但我们清醒地看到，它的定位更倾向于是一种“离线数据分析平台”，而不是“分布式数据库”，其时效性、准确性等难以满足特定需求。现在有很多公司在Hadoop上面做了类似“SQL引擎”的东西，就是仿照关系型数据库的处理方式处理Hadoop中的数据，但要想达到发展了数十年的数据库水平，还有很长的路要走。笔者对这两者的认识是：各有所长，互为补充。