第一份工作的时候在银行业，有些表每天的新增数据就有2.3亿条记录（拜大集中所赐），这还只是半个中国的数据。因此从一开始，对大规模数据的处理就是我工作的基本要求。前辈们总结处很多编程与操作的规定，以满足性能上的需要。这里的性能，更多的指在规定要求的时间内完成规定的事情。在这段时间，没有人会提“千万级数据”，因为它太少了。

后来进了DB2的老家IBM, 做起了DB2的技术支持，那些DB2的开发设计大牛来讲DB2的架构，各部分的实现原则与部分细节，终于从更深层次了解了数据库是如何操作数据的，如何计算，如何join, 优化器如何改写SQL并决定访问路径(Access Path － 话说这中文翻译还真是别扭).这背后其实是cost-based estimator, 一切皆以statistics统计数据作为输入，进过DB2优化器的数学模型，得到对结果集大小、CPU时间、I/O时间等等的预测，最后得到一个时间估计，选取估计值最小的方案。

每个人都希望自己的查询(query)有快又好，但这是要跟多种因素相关联的。除了优化器选择access path以外，跟DB系统参数，Bufferpool大小，Sortpool大小，CPU,IO性能都有关系。

当然，大部分个人用户不会考率为了数据库的性能而更换或者扩展CPU数量，换用高性能的企业级存储这样的要钱的方式，因此就省下压榨database系统了。因此在互联网建站和小型企业数据库上，才更多的提到“千万级”的概念 －－世上本没这个词，提的人多了也就成了个概念吧。

网上一个不算新但是很详细和典型的帖子：http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm

一个典型的场景就是系统突然出现了一个状况（CPU high或者响应慢到不能忍受），于是要分步排除问题，首先系统IO方面时候遇到瓶颈－－打开文件数量到上限了？cache出了问题？这个部分没问题了，再看看DB系统的配置参数如何？是不是bufferpool或者sortpool大小不合适所以导致了过多的page-in,page-out?

如果上两点都没有问题，初步可以排除环境方面的因素，接下来就可以关注在具体SQL query的性能了。

那么关注哪些SQL呢？常用的关系型数据库系统(DB2, Oracle也包括MySQL等等)，都有工具或者命令抓到耗时最长的SQL query. 例如MySQL下你可以用show processlist;

找到了最慢的sql,有两个方向可以选择：A 从SQL Query涉及的object(table,view)出发分析结构上的欠缺如缺少必要的index等等；另一个方向是用explain得到slow SQL的access path, 看看是不是table scan了，发生在什么环节然后去做修改。

上面是最最通用的数据库调优(Performance tuning)的策略，基本宗旨还是我们创造条件去帮助优化器(DB optimizer)以得到最优解。相信大部分DBA都熟悉。接下来说一下一个极端情况，就是无论你怎么做，优化器认为的最优解在你的特例中实际上却是最糟糕的。我们不能神话优化器，没有一种算法是能够在所有情况下都是最好的，因此极少数的SQL在特定的data特性下，我们需要去“误导”甚至是“欺骗”优化器来的到我们想要的最优解－－即便这个方案在优化器看来是很糟糕的。这就是access path hint, 名字可能略有差异但是DB2,Oracle等主流数据库系统都是支持的。我们可以用自己的大脑代替优化器来决定少数特殊query的access path.

啰嗦了这么多，其实是想说，被常常使用的“千万级数据（库）”的概念，其实跟技术没多大关系，只是一个模糊的对DB甚至是整个IT系统的性能要求，有时候可以理解为性能调优技术的要求。以后见到这个概念，知道背后是怎么一回事就行了－－尤其是对HR和猎头这类技术盲来说。

P.S. 数据库还有另一个scaling方面的技术来提高性能，这个是架构方向，互联网企业用的比较多。以后有空再写一写。其实网上这样的文章很不少了。