数据库性能优化的误区

常见的数据库系统优化中的一些观点： 

“系统性能出现问题进行优化，必定要深刻了解数据库内部参数、等待事件、Latch、缓冲池、trace文件、查询/优化引擎等底层细节。” 
这种观点每每出自数据库“高手”，这部分人以了解数据库底层实现细节而感到很是骄傲。可是从优化角度讲数据库的等待事件、Latch等指标高等等都只是问题的表象，懂得底层细节和内幕当然是好。可是解决问题的关键每每是在应用层进行优化。

“只要系统参数调整了，性能就能提升。系统优化应该调整那些参数…” 
这种观点每每出自于一些偏运维和应用层的DBA，迷恋参数配置来调优。 
调整系统参数是很是重要的，但不必定能解决性能问题，不然就不会有去IOE了，问题可能性最大的仍是应用设计和开发问题。

同理，不少运维人员和系统架构师比较迷恋“Linux系统调优”。认为的对“文件句柄数、CPU/内存/磁盘子系统…”各类参数作了优化，觉得这就能提高整个应用系统的性能。其实否则。有些场景下，针对业务特色和应用类型作操做系统调优是能取到立竿见影的效果，可是大多数时候每每提高并不明显。因此最关键的仍是找出瓶颈所在，对症下药。

“系统性能问题须要从架构上解决，与应用开发关系不大。” 
系统性能与各个层面都有关，总体架构很重要，但应用开发也是很是重要的一环。

“大家必需要作读写分离，必需要弄分库分表。”

这种一般是“吹水”的人常在外面忽悠的，这些技术手段都被说烂了。

反问一句，了解数据量吗？知道实际压力和瓶颈吗？了解读写好比何吗？怎么拆？拆了以后怎么玩？ 

上述那些观点，都是比较片面的，仍是须要结合实际状况辩证分析。

 

常见影响数据库性能的因素

1.业务需求和技术选型 

2.应用系统的开发及架构 

3.数据库自身 

3.1表结构的设计 

3.2查询语句 

3.3索引设计 

3.4Mysql服务（安装、配置等） 

3.5操做系统调优 

3.6硬件升级（SSD、更强的CPU、更大的内存） 

4.数据架构（读写分离、分库分表等）

 

性能调优的基本方法论

 

 

理想的数据库优化顺序

 

 

在不少状况下，数据库多是互联网应用系统的最大瓶颈。可是单纯从数据库角度去作优化，可能未必能达到理想的效果。