【有奖话题讨论】CPU核越多:数据库就跑得越快吗？（已公布获奖名单）

pipihappy8888

谈到OLTP数据库，大家不会觉得陌生，比如飞机订票、网上交易、银行系统都会用到OLTP数据库。OLTP数据库的最大优点在于支持即时处理输入的数据，衡量OLTP数据库好坏的一个重要的性能指标是实时响应时间，因此有人把高性能OLTP数据库是数据库界的珠穆朗玛。只是CPU核越多，数据库就一定跑得越快吗？与主流商业数据库相比，国产数据库、开源数据库差距明显。过去的一年里，神舟通用成功地将同步技术应用于神通数据库的多个关键设计中，并在OLTP高性能领域取得了长足的进步。

本期话题:

1.对于SQL开发人员来将，有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种，即OLTP与OLAP，请谈谈OLTP数据库与OLAP数据库的区别。

2.通过对神通数据库的上一版本经过测试，测试基准表明（参见附件图），当处理器从1路4核调整为2路6核时，神通数据库的交易响应速度提高了100%；当处理器从2路6核提高到4路8核时，神通数据库的交易响应速度提高了25%；而当处理器从4路8核增加到8路10核时，神通数据库的交易响应速度反而降低了60%；这到底是为什么？是并发协议出了问题？还是同步原语出了问题？或者其它原因？

3.从实战的角度来讲，要想提高数据库的高性能并发响应速度，有专家建议优化设计的关键点是锁和日志，您是否赞同，为什么？请分析下锁与日志的优缺点。

4.通过将同步技术应用于神通数据库的多个关键设计后，神通数据库新版本的测试基准表明（参见附件图），当处理器从1路4核不断增加到8路10核时，数据库的交易响应速度也在直线上线，这是否意味着处理器的核越多，神通数据库跑得越快？是一劳永逸还是可能会出现新的拐点？

活动时间：6月17-7月1日

活动奖励：欢迎大家针对以上任意问题回帖，我们将根据大家的表现，选取特等奖一名，赠送精美神舟探月模型1个，选取积极回帖活跃会员10名，赠送50元京东购物礼品卡。

获奖名单：恭喜以下会员获奖，请获奖会员及时以短消息联系我，以便发送奖品。

50元京东购物礼品卡10名

gzmt

imybsd

zcl32

foreverlove2011

songmingliang

wmxcn2000

陌路巨额投入

pure_lotus

T-McGrady1

logo111

特等奖1名

leonarding

logo111

CPU肯定对数据库性能有着巨大的影响。还是要一分为二的看问题。
1.系统的瓶颈确实是在CPU上吗？I/O,memory,网络都有可能成为瓶颈。
2.在OLTP的情况下，对于大并发，每秒事务数极高的情况下，CPU是很容易出现瓶颈的。比如Oracle,只有一个LGWR进程，大并发的情况下，所有事务都需要提交，都要写日志。这种情况，CPU极易成为瓶颈，会看到大量的log file sync等待。还有就是逻辑读，latch的获取，都是消耗CPU的操作。

结论：对于大并发情况下的OLTP系统，CPU很容易成为系统瓶颈，这种情况下，增加CPU的核数能提高数据库的性能。

gzmt

这次的话题确实不怎么好回答呀，感觉问题很广，我来回答第2个问题吧。

是并发协议出了问题？

    并发协议是整个并行系统的基础，测试中使用的三个厂商的数据库均支持MVCC。通过使用MVCC（多版本并发控制）算法，能够维持一个数据的多个版本使读写操作没有冲突，它优化了数据库并发系统，使系统在有大量并发用户时得到最高的性能，并且可以不用关闭服务器就直接进行热备份。像MVCC这样读写并行的优秀的并发协议，对高性能的OLTP数据库是至关重要的，但是有好的协议并不等于数据库就会有好的实现。所以问题不是处在并发协议之上。

同步原语出了问题？
    同步原语实现的目标，在于减少了同步本身的开销，在临界区执行路径较短时，可以发挥很大作用，如类Latch的实现，Atomic原子操作，Lock-Free结构，Memory Barriers，RCU等等。以数据库为代表的复杂并行系统，真正决定并发性能的，往往是一些逻辑复杂、执行路径较长的临界区，优化同步本身对性能的帮助有限。所以，问题也不是出在同步原语上。

问题出在哪?
    数据库中主要的热点临界区有日志、锁、事物、SGA、字典缓存……。从现象描述来看，是因为关键临界区争用剧烈，部分临界区出现“越并发性能越差”的问题。解决问题的关键在于优化同步设计，减少临界区争用。因此同步设计将是神通数据库的主攻方向。

gzmt

拐点主要会出现在数据库设计和CPU设计这两方面。

数据库设计方面主要涉及对CPU高速缓存以及内存的使用算法，但是我对神通数据库不怎么熟悉，就不多说了；

CPU设计方面，每个CPU内核共享使用高速缓存以及内存总线，这其中需要CPU厂商设计合理的算法。即便算法合理，当内核越多时，所有的内核都在通过相同的管道向存储器发出请求，这就像1个、2个、4个或8个人在同时说“我等着要这个东西”，一直等着回复。

T-McGrady1

1.OLTP通常是时间短,数据量小的事务处理,OLAP通常是大量数据的处理,汇总分析,时间长,数据量大.
2.处理器核数越多,数据库的处理能力越高,当达到一定核数后,数据库的瓶颈已经不在CPU的处理能力上了,所以更多的CPU反而在性能上得不到提升.
3.赞同优化锁和日志提升性能,锁和日志是保证数据库安全稳定可靠的核心.所有的数据库处理都必须经过这一环节,缺点就是过多的竞争和等待造成性能下降
4.神通应用同步技术,具体的我们不了解,能分享下更多的同步技术原理是如何提高性能并且保证数据可靠性的吗?

pure_lotus

1OLTP是要实时处理交易数据，OLAP则是在后台进行数据仓库应用，提供决策支持所需要的分析数据。
2.神通数据库的交易响应速度与处理器核数非线性相关，甚至从4路8核增加到8路10核时交易响应速度反而降低了60%；与并发协议有关系不大，由于处理核数增加是会影响多线程并发处理的同步问题。

3.从实战的角度来讲，要想提高数据库的高性能并发响应速度，有专家建议优化设计的关键点是锁和日志，您是否赞同，为什么？请分析下锁与日志的优缺点。
设计优化不完全依赖锁和日志两个关键点，要看速度瓶颈，甚至优化一下SQL表达式、更新一下索引也可能见效大。锁确保数据一致性，能够按事务进行处理。日志优化则有利于事务回滚速度，避免不谓的磁盘IO。
4.通过将同步技术应用于神通数据库的多个关键设计后，神通数据库新版本的测试基准表明当处理器从1路4核不断增加到8路10核时，数据库的交易响应速度也在直线上线，这是否意味着处理器的核越多，神通数据库跑得越快？是一劳永逸还是可能会出现新的拐点？当然不会，当处理器资源相对需求过剰后，会出现新的拐点。

陌路巨额投入

首先来说说CPU核越多，数据库就一定跑得越快吗？

     我们都知道多核技术可以通过划分任务，线程应用能够充分利用多个执行内核，并可在特定的时间内执行更多任务。操作系统会利用所有相关的资源，将它的每个执行内核作为分立的逻辑处理器。通过在两个执行内核之间划分任务，多核处理器可在特定的时钟周期内执行更多任务。 多核架构能够使用的软件更出色地运行，并创建一个促进未来的软件编写更趋完善的架构。操作系统专为充分利用多个处理器而设计，且无需修改就可运行。为了充分利用多核技术，应用开发人员需要在程序设计中融入更多思路，但设计流程与对称多处理 (SMP) 系统的设计流程相同，并且单线程应用也继续运行。 得益于线程技术的应用在多核处理器上运行时将显示出卓越的性能可扩充性。但是在cup与数据库速度方面，并不是呈正比的。。
个人感觉CUP内核的增加，数据库并行处理能力确实能够大大增加。就拿英特尔上一代至强7400相比，与先推行的至强7500采用8核(据官方数据，处理器在数据方面的计算性能是上一代的2.5倍，而其中最显著的功效来源于4条QPI直连总线带来的超快通讯速度(可到6.4GT/s，远非以往FSB总线所能企及)、超大的L3缓存(多达24MB)和9倍于前的内存带宽(四通道DDR3)。。。但是还是觉得对于CUP内核数量来说，还是要考虑价格成本还有需要处理的数据总量来选择合适的CUP内核数吧。。

　　
1.对于SQL开发人员来将，有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种，即OLTP与OLAP，请谈谈OLTP数据库与OLAP数据库的区别。
     
   OLTP一般注重高并发，各个内存的命中率，譬如SHARED POOL， BUFFER CACHE的命中率。在设计上也会注重这些方面。OLTP的数据可能会有个时间窗口，因此有时候设计上也会考虑归档的方便。由于数据量相对比较小，因此OLTP大部分都是集中式的。OLAP的并发量比较小，大部分查询可能运行一次可能很久不会在运行，因此SQL的重用意义也就不大，很多命中率指标对于OLAP意义不是很大了，对于数据量比较大，分区，并行操作，压缩，物化视图，全文索引等技术可能都会在OLAP中体现。
OLAP的数据量可能比较大，上TB的OLAP都算大库了，有的都几百TB，甚至PB，因此很多OLAP库可能都分成了N个库，以便于分布式处理。此外OLAP一般都是采用星星模式或者雪花模式的。
主要区别总结：
    1.sga,pga的设置不同
    2.统计信息收集,有些oltp可以用oracle提供的自动job去收集,olap一般都自己写
    3.olap很少绑定变量
    4.oltp一个sql跑超过10秒就觉得很慢了,olap一个sql跑10分钟都很正常
    5.olap有用到star transform和bitmap index
    6.执行计划中,oltp常见nl,olap基本只有hj
    7.业务上来说,oltp的dml很多,olap基本就只有select
    8.优化来说olap基本上就只有从sql入手,oltp很多其他因素
     

2.通过对神通数据库的上一版本经过测试，测试基准表明（参见附件图），当处理器从1路4核调整为2路6核时，神通数据库的交易响应速度提高了100%；当处理器从2路6核提高到4路8核时，神通数据库的交易响应速度提高了25%；而当处理器从4路8核增加到8路10核时，神通数据库的交易响应速度反而降低了60%；这到底是为什么？是并发协议出了问题？还是同步原语出了问题？或者其它原因？
  
    当处理器从1路4核调整为2路6核时，神通数据库的交易响应速度提高了100%；当处理器从2路6核提高到4路8核时，神通数据库的交易响应速度提高了25%这些数据就可以说明并发协议没有出问题，这些可能说明一味的提升CPU的路数和核数不一定能够达到加快数据库的处理响应速度，CPU与数据库响应速度有一个最佳的适配数，超过了反而会浪费CPU资源而且响应速度也不会得到提升。。
   

   
   

3.从实战的角度来讲，要想提高数据库的高性能并发响应速度，有专家建议优化设计的关键点是锁和日志，您是否赞同，为什么？请分析下锁与日志的优缺点。

     个人还是比较赞同这个的。。因为提高数据库的高性能并发响应速度确实是有软件方法，也有硬件方法，可以通过提高CUP内核的数量来提升，不过通过这个会增加许多不必要的成本还有浪费很多硬件资源。。多并发处理快了，高性能并发响应速度也提上去了。。但是这不是最优的方法。。锁与日志这个软件维护的方法只是占用内存的一点点资源，就可以完美解决我们的问题。。。
  关于锁与日志的优缺点：
     事务日志和锁具有以下特点:事务日志是一个单元的工作，要么全做，要么全不做，保证操作的一致性和可恢复性，在多服务器环境中，使用用户定义的分布式事务，保证操作的一致性 。
锁是保证并发控制的手段 可以锁定的资源包括行、页、簇、表和数据库，锁的类型主要包括共享锁和排它锁，特殊类型的锁包括意图锁、修改锁和模式锁 。共享锁允许其他事务继续，使用锁定的资源， 排它锁只允许一个事务访问数据 ，系统本身可以处理死锁 用户可以根据实际情况定制锁的一些特征
总的来说：日志的作用是记录所有对数据库数据的修改，主要是保护数据库以防止故障发生后，对数据库进行恢复；锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。

4.通过将同步技术应用于神通数据库的多个关键设计后，神通数据库新版本的测试基准表明（参见附件图），当处理器从1路4核不断增加到8路10核时，数据库的交易响应速度也在直线上线，这是否意味着处理器的核越多，神通数据库跑得越快？是一劳永逸还是可能会出现新的拐点？

   这个问题还是参照上面说的那些吧。。CUP内核的增加，数据库并行处理能力确实能够大大增加。就拿英特尔上一代至强7400相比，与先推行的至强7500采用8核(据官方数据，处理器在数据方面的计算性能是上一代的2.5倍，而其中最显著的功效来源于4条QPI直连总线带来的超快通讯速度(可到6.4GT/s，远非以往FSB总线所能企及)、超大的L3缓存(多达24MB)和9倍于前的内存带宽(四通道DDR3)。。。但是还是觉得对于CUP内核数量来说，还是要考虑价格成本还有需要处理的数据总量来选择合适的CUP内核数吧。。个人觉得不管什么事情都不会一劳永逸，这个可能会出现新的拐点吧。。

songmingliang

3.从实战的角度来讲，要想提高数据库的高性能并发响应速度，有专家建议优化设计的关键点是锁和日志，您是否赞同，为什么？请分析下锁与日志的优缺点。

     赞同。因为提高数据库的高性能并发响应速度确实是有软件方法，也有硬件方法，可以通过提高CUP内核的数量来提升，不过通过这个会增加许多不必要的成本还有浪费很多硬件资源。。多并发处理快了，高性能并发响应速度也提上去了。。但是这不是最优的方法。。锁与日志这个软件维护的方法只是占用内存的一点点资源，就可以完美解决我们的问题。。。
  关于锁与日志的优缺点：
     事务日志和锁具有以下特点:事务日志是一个单元的工作，要么全做，要么全不做，保证操作的一致性和可恢复性，在多服务器环境中，使用用户定义的分布式事务，保证操作的一致性 。
锁是保证并发控制的手段 可以锁定的资源包括行、页、簇、表和数据库，锁的类型主要包括共享锁和排它锁，特殊类型的锁包括意图锁、修改锁和模式锁 。共享锁允许其他事务继续，使用锁定的资源， 排它锁只允许一个事务访问数据 ，系统本身可以处理死锁 用户可以根据实际情况定制锁的一些特征
总的来说：日志的作用是记录所有对数据库数据的修改，主要是保护数据库以防止故障发生后，对数据库进行恢复；锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。

wmxcn2000

增加 CPU 在某些场合，就大大提高数据库的速度，但是到了一个某个特定值，就算再加 100 倍的 CPU 上来，也是白白的浪费。

倒底这个“某个特定值”是什么意思，我举一个例子：
我们每个人在公司都有办公位，大家都可能会觉得办公位比较小（CPU），桌上放几本书，放个水杯，放些花（个人对CPU的需求），再不断的添置新东西，这时根据个人的申请，公司又给了一个同样大小的桌子，可以把书搬过去，原来的桌子（CPU），就会显的空闲了许多（压力变小了），但是你还是觉得不够用，又申请一张桌子（增加第三个CPU）,你一看好了，东西摆放的正好，所有的物品都离自己很近，使用方便（硬件设备已经满足，也就是上面提到的值）。这个时候再给你增加 1 张桌子（CPU）就已经是浪费了，就不要说再增加 100 张桌子（CPU）。

椰风海韵158

借用这话：
CPU肯定对数据库性能有着巨大的影响。还是要一分为二的看问题。
1.系统的瓶颈确实是在CPU上吗？I/O,memory,网络都有可能成为瓶颈。
2.在OLTP的情况下，对于大并发，每秒事务数极高的情况下，CPU是很容易出现瓶颈的。比如Oracle,只有一个LGWR进程，大并发的情况下，所有事务都需要提交，都要写日志。这种情况，CPU极易成为瓶颈，会看到大量的log file sync等待。还有就是逻辑读，latch的获取，都是消耗CPU的操作。

zcl32

1.对于SQL开发人员来将，有必要了解开发的数据库应用属于哪种类型。而主流的数据库应用类型有两种，即OLTP与OLAP，请谈谈OLTP数据库与OLAP数据库的区别。
OLTP数据库面向事务型，特点是并发用户多，sql语句简单，事务短，响应时间快，写操作相对来说比较多，数据库的设计一般采用第三范式；
OLAP则是分析型的数据库系统，特点是并发用户数量少，SQL语句比较复杂，通常是多个表的连接，响应时间可能比较长，基本上是读操作为主，写操作主要用于数据的批量装入，数据库的设计上基本采用星型模型和雪花型模型。

2.通过对神通数据库的上一版本经过测试，测试基准表明（参见附件图），当处理器从1路4核调整为2路6核时，神通数据库的交易响应速度提高了100%；当处理器从2路6核提高到4路8核时，神通数据库的交易响应速度提高了25%；而当处理器从4路8核增加到8路10核时，神通数据库的交易响应速度反而降低了60%；这到底是为什么？是并发协议出了问题？还是同步原语出了问题？或者其它原因？
这个原因应该不是底层的同步原语出问题，而应该属于系统再向上层的一些同步处理出现问题，比如数据库的数据和索引页面访问方面时候的latch，进行锁操作，日志缓存读写的自旋锁等，以及查找SQL执行SQL时候的内部锁等实现上，可能需要考虑一些多个内存节点的分区操作，利用NUMA非一致性内存访问等技术。
其实这个方面也是系统最难以调优的部分，只有数据库系统实现的时候提供了大量的运行时统计参数后才能真正分析了解系统的瓶颈，这也是目前主流的商业数据库其中的一个核心优势，像mysql等开源数据库在这个方面就有差距了。

3.从实战的角度来讲，要想提高数据库的高性能并发响应速度，有专家建议优化设计的关键点是锁和日志，您是否赞同，为什么？请分析下锁与日志的优缺点。
对于数据库系统自身来讲，可能优化设计的还不止基本的事务锁和日志，包括前面提到的latch, 自旋锁等内部并发机制。

4.通过将同步技术应用于神通数据库的多个关键设计后，神通数据库新版本的测试基准表明（参见附件图），当处理器从1路4核不断增加到8路10核时，数据库的交易响应速度也在直线上线，这是否意味着处理器的核越多，神通数据库跑得越快？是一劳永逸还是可能会出现新的拐点？
出现拐点是必然的，即使数据库本身设计得好，能处理很多的并发，操作系统在某些处理上也会跟不上，比如进程调度，内存管理等；当然在这之前，存储设备还需要能跟上IO的请求速度，单机上的HBA卡的性能毕竟是受限的。
即使不算硬盘IO的限制，从测试的图上可以看出来，虽然神通数据库的扩展性很好，但是还是不如oracle。oracle在256个核的系统上表现都有点吃力，神通可能更早出现问题。

leonarding

1.开发工程师是需要了解所开发的系统是哪种类型和上面所跑的业务流程以及预测正式使用后工作负载情况
根据上述经验，不同类似可采用的调优方式与优化技巧是不同的，绑定变量、变量窥视、缓存结果集、压缩技术、并发技术、baseline、缓存执行计划、直接加载大对象等等技术是用在不同场景下的。
2.当今硬件水平下CPU已经不是性能提高的瓶颈了，CPU的多只是可以提高聚合运算的时间和并发处理时间，数据库里面都会有一个叫并发协调器工具，它来分配并行进程的运行情况，CPU多分配的子任务也多，在最后的整合汇总结果集的过程中反而性能下降，因为需要更多的资源去协调各个子任务相互关系。当我们的业务逻辑是一种线性的处理过程时，在多的CPU都是爱莫能助的。

3.提高OLTP类型的数据库应该重点考虑内存的容量和内存总线频率参数，让更多的数据缓存在内存中，减少硬盘访问次数，运用分隔技术尽量把热数据长期加载到内存中提高数据命中率。4.提高数据库高性能并发响应速度，数据库中要充分应用好lock和latch，lock解决的是资源争用问题，为了保证事物一致性必须要在某个时刻只允许某个session独占资源，latch解决的是并发资源的争用问题，优先获得latch的session才有资格去处理数据。

4.大并发下极易造成log file sync等待事件，但是这种争用最大的瓶颈在于IO资源，在异步IO情况下要比同步IO情况下效果要好些。神通数据库在实现并发特性上同步技术，当下很多数据库产品都使用同步技术，但不代表使用同步技术就可以实现大规模的并发场景，并发性能的好坏要从若干个层面上来分析，例如 底层存储的读写同步   内存同步   latch等资源同步   catch同步   CPU结果集聚合同步 等都是一个系统模式，需要的是整体的同步协议来调整好每一层的衔接，这样才能达到更好的并发效果

foreverlove2011

通过对神通数据库的上一版本经过测试，测试基准表明（参见附件图），当处理器从1路4核调整为2路6核时，神通数据库的交易响应速度提高了100%；当处理器从2路6核提高到4路8核时，神通数据库的交易响应速度提高了25%；而当处理器从4路8核增加到8路10核时，神通数据库的交易响应速度反而降低了60%；这到底是为什么？是并发协议出了问题？还是同步原语出了问题？或者其它原因？

并发协议是整个并行系统的基础，优秀的并发协议（如MVCC读写并行）对高性能OLTP数据库至关重要。但这并不意味着好的协议支持好的实现。而且从基准测试的结果来看，这三款数据库均支持MVCC并发协议，所以不是并发协议出的问题。
同步原语实现的目标，在于减少同步本身的开销，在临界区执行路径较短时，可以发挥很大作用。以数据库为代表的复杂并行系统，真正决定并发性能的，往往是一些逻辑复杂、执行路径较长的临界区，优化同步本身对性能的帮助有限。

关键临界区比如日志、锁、事务、SGA、字典缓存等争用 Top Wait: BMSQL tpcc 30分钟统计采样剧烈，部分临界区出现“越并发性能越差”问题，因此解决问题的关键在于优化同步设计，减少临界区争用。因此同步设计将是优化的关键。

imybsd

单从CPU来说，除非一个SQL语句使用并行处理，才能同时用上多个CPU内核，这样的一半是进行大数据量分析的OLAP；对于OLTP这样的高并发，少量数据检索，并行处理对于单个的的SQL语句并不会带来多少益处。在OLTP环境，CPU内核的增加带来的一个益处是整个负载能里的提高，能承载更多的并发用户，但并不能提高单个SQL请求的反应速度。另一点楼主文中没有提到CPU变为8路10核，CPU的频率是否也提高了？一般情况下，为了保证功耗控制在一定范围，内核增加，主频应该下降了。主频下降，单个SQL语句的执行速度会减慢，也就是说整体反应速度下降，但并发用户的负载量增加。如果涉及到内存大小，IO，网络，就更复杂了。

从刚才的那个的测试基准图上看，神通数据库（老版本）在4路8核有一个拐点，整机负载能力突然下降了。这点感觉不太正常。说明数据库引擎不能很好的应对更多的CPU带来的硬件计算能力提升。那个O*是暗指ORACLE么？以前做过ORACLE和MySQL的压力测试对比，同一个硬件平台，同样的数据量，一个产品对于不同数据库的版本。结果ORACLE10明显胜出，MySQL5.0落败。很多人可能不理解，ORACLE那么庞大，MySQL那么小巧。我觉得主要原因就是SQL共享机制的问题。ORACLE在share sql 上做的非常好，所以减少了很多的硬解析。而mysql没有一个好的SQL共享机制，造成比较高的CPU占用率。神通数据库中数据库引擎，SQL解析，SQL优化器上做的怎么样呢？

lianv123

占楼~学习

〇〇

神通数据库，其他数据库呢？

云天英雄

数据库不是取决在cpu，相同配置cpu越高，是会提升数据库的运算能力。只能说是同等配置情况下。否则就不能这么说。

lastwinner

具体问题太泛
反而是标题还好说一些：
1、核多了，如果协调处理能力不足，那就无法将各个核的作用发挥到最大
2、核的对称性如果不好，即与内存等的对称性不匹配，那么效用也无法发挥到最大
3、回到问题上，数据库的瓶颈如果不在CPU上，那么加那么多核除了花掉剩余的预算外，还有什么用呢？

yql911

不单单是cpu,内存。在于，SQL语句合理性，磁盘IO，很多关系。。

gzmt

OLTP主要是以业务处理为主，为用户的应用系统提供实时响应。OLAP是专门为支持复杂的分析操作而设计的，可以为管理者提供决策支持。
OLTP系统管理的数据通常很琐碎，难以用于决策，通常采用面向应用的数据库设计。OLAP系统将大量历史数据进行汇总和聚集，用于决策分析，通常采用面向主题的数据库设计。

interstellar

OLTP和OLAP，后者有个A，自然分析和数据挖掘是主要任务吧；前者自然跟末端用户直接交互，要快，准，狠；

CPU多，应该是增加并发处理，同时在线用户多自然CPU多多益善；

神通数据库是啥……查查