MySQL数据库性能优化有哪些技巧？

1.存储引擎的选择如果数据表需要事务处理，应该考虑使用InnoDB，因为它完全符合ACID特性。如果不需要事务处理，使用默认存储引擎MyISAM是比较明智的。并且不要尝试同时使用这两个存储引擎。思考一下：在一个事务处理中，一些数据表使用InnoDB，而其余的使用MyISAM.结果呢？整个subject将被取消，只有那些在事务处理中的被带回到原始状态，其余的被提交的数据转存，这将导致整个数据库的冲突。然而存在一个简单的方法可以同时利用两个存储引擎的优势。目前大多数MySQL套件中包括InnoDB、编译器和链表，但如果你选择MyISAM，你仍然可以单独下载InnoDB，并把它作为一个插件。很简单的方法，不是吗？

2.计数问题如果数据表采用的存储引擎支持事务处理（如InnoDB），你就不应使用COUNT（*）计算数据表中的行数。这是因为在产品类数据库使用COUNT（*），最多返回一个近似值，因为在某个特定时间，总有一些事务处理正在运行。如果使用COUNT（*）显然会产生bug，出现这种错误结果。

3.反复测试查询查询最棘手的问题并不是无论怎样小心总会出现错误，并导致bug出现。恰恰相反，问题是在大多数情况下bug出现时，应用程序或数据库已经上线。的确不存在针对该问题切实可行的解决方法，除非将测试样本在应用程序或数据库上运行。任何数据库查询只有经过上千个记录的大量样本测试，才能被认可。

4.避免全表扫描通常情况下，如果MySQL（或者其他关系数据库模型）需要在数据表中搜索或扫描任意特定记录时，就会用到全表扫描。此外，通常最简单的方法是使用索引表，以解决全表扫描引起的低效能问题。然而，正如我们在随后的问题中看到的，这存在错误部分。

5.使用“EXPLAIN”进行查询当需要调试时，EXPLAIN是一个很好的命令，下面将对EXPLAIN进行深入探讨。

经过前面的介绍现在我们都知道，一行一行的数据是存放在数据页里的，所以接下来我们该分析一下数据页的结构了。之前介绍过，每个数据页，实际上是默认有16kb的大小，那么这16kb的大小就是存放大量的数据行吗？明显不是的，其实一个数据页拆分成了很多个部分，大体上来说包含： 文件头、数据页头，最小记录和最大记录、多个数据行、空闲空间、数据页目录、文件尾部。下面我们来看一张图：

简单来说，就是平时我们创建的那些表，其实都有一个表空间的概念，在磁盘上都会对应着“表名.ibd”这样的一个磁盘数据文件。所以在物理层面，表空间就是对应一些磁盘上的数据文件。有的表空间，比如系统表空间可能对应的是多个磁盘文件，我们自己创建的表对应的表空间可能就是对应了一个“表名.ibd”数据文件。

在表空间的磁盘文件里会有很多的数据页，但是如果一个表空间包含了太多数据页的话就不便于管理，所以在表空间里又引入了一个 的概念，英文就是extent，一个数据区对应着连续的64个数据页，每个数据页是16kb，所以一个数据区是1mb，然后256个数据区被划分为一组。

对于表空间而言，它的第一组数据区的第一个数据区的前3个数据页都是固定的，里面存放了一些描述性的数据。比如fsp_hdr这个数据页，它里面就存放了表空间和这一组数据区的一些属性。ibuf_bitmap数据页，里面存放的是这一组数据页的所有insert buffer的一些信息。inode数据页，这里也存放了一些特殊信息。

我们现在先不去具体了解它们是干什么的，只要知道第一组数据区的第一个数据区的前3个数据页，都是存放一些特殊信息的。然后这个表空间里的其它各组数据区，每一组数据区的第一个数据区的头两个数据页都是存放特殊信息的，比如xdes数据页就是用来存放这一组数据区的一些相关属性的，其实就是很多描述这组数据区的东西。下面我们通过一张图来看一下表空间的存储结构。

1、linux *** 作系统的存储系统软件层原理分析以及IO调度优化原理

简单来说，linux的存储系统分为 VFS层、文件系统层，Page Cache缓存层，通用Block层、IO调度层、Block设备驱动层、Block设备层 ，如下图：

最后IO完成调度之后，就会决定哪个IO请求先执行，哪个IO请求后执行，此时可以执行的IO请求就会交给Block设备驱动层，最后经过驱动把IO请求发送给真正的存储硬件，也就是Block设备层。硬件设备完成IO读写 *** 作，最后就把响应经过上面的层级反向依次返回，最终MySQL可以得到本次IO读写 *** 作的结果。

---