关于MySQL的优化全面分析

这篇文章主要为大家详细介绍了关于MySQL的优化全面分析，具有一定的参考价值，可以用来参考一下。

对此感兴趣的朋友，看看idc笔记做的技术笔记！

先说一下最常见基本的系统瓶颈：1、硬盘搜索。现代磁盘的平均时间通常小于10ms，因此理论上我们每秒能够大约搜索1000次，这样我们在这样一个磁盘上搜索一个数据，很难优化，一个办法就是将数据分布在多个磁盘。2、IO读写。就磁盘来讲，一般传输10-20Mb/s，同样的，优化可以从多个磁盘并行读写。3、CPU周期。我们将数据读入内存后，需要对它进行处理并获取我们需要的结果。表相对于内存较小时常见的限制因素。但是对于小表，速度通常不成问题。4、内存带宽。当CPU需要的数据超出CPU缓存，主缓存带宽就成为内存的一个瓶颈。再说一下mysql设计上边的瓶颈：（本人了解一下它的数据库引擎，wiki上边说的一些缺陷）MyISAM是MySQL的默认数据库引擎 (5.5版之前)，由早期的ISAM所改良。虽然性能极佳，但却有一个缺点：不支持code error!（transaction）。不过，在这几年的发展下，MySQL也导入了InnoDB (另一种数据库引擎)，以强化code error!与并发违规处理机制，后来就逐渐取代MyISAM。每个MyISAM数据表，皆由存储在硬盘上的3个文件所组成，每个文件都以数据表名称为主文件名，并搭配不同扩展名区分文件类型：.frm－－存储数据表定义，此文件非MyISAM引擎的一部份。.MYD－－存放真正的数据。.MYI－－存储索引信息。1、InnoDB可借由交易记录档 (Transaction Log) 来恢复程序崩溃 (crash)，或非预期退出所造成的数据错误；而MyISAM遇到错误，必须完整扫描后才能重建索引，或修正未写入硬盘的错误。InnoDB的修复时间，大略都是固定的，但MyISAM的修复时间，则与数据量的多寡成正比。相对而言，随着数据量的增加，InnoDB会有较佳的稳定性。2、MyISAM必须依靠操作系统来管理读取与写入的高速缓存，而InnoDB则是有自己的读写高速缓存管理机制。(InnoDB不会将被修改的code error!立即交给操作系统) 因此在某些情况下，InnoDB的数据访问会比MyISAM更有效率。3、InnoDB目前并不支持MyISAM所提供的压缩与 terse row formats，所以对硬盘与高速缓存的使用量较大。因此MySQL从5.0版开始，提供另一个负载较轻的格式，他可减少约略 20% 的系统负载，而压缩功能已计划于未来的新版中推出。4、当操作完全兼容ACID (code error!) 时，虽然InnoDB会自动合并数笔连接，但每次有code error!产生时，仍至少须写入硬盘一次，因此对于某些硬盘或磁盘阵列，会造成每秒200次的code error!处理上限。若希望达到更高的性能且保持code error!的完整性，就必使用软盘高速缓存与电池备援。当然 InnoDB 也提供数种对性能冲击较低的模式，但相对的也会降低code error!的完整性。而MyISAM则无此问题，但这并非因为它比较先进，这只是因为它不支持code error!。（InnoDB，是MySQL的数据库引擎之一，为MySQL AB发行binary的标准之一。InnoDB由Innobase Oy公司所开发，2006年五月时由甲骨文公司并购。与传统的ISAM与MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事务（Transaction）功能，类似于PostgreSQL。）

注：关于关于MySQL的优化全面分析的内容就先介绍到这里，更多相关文章的可以留意