查询性能的优化 - 查询慢的基础知识:优化数据访问

核心提示： 获取所有的列 当你看到select *的时候一定要有所怀疑，你真的需要所有的列么？也许不是，查询性能的优化 - 查询慢的基础知识:优化数据访问(2)，获取所有的列可能会使一些优化失效，比如覆盖索引，并且还有硬件-都可能影响到执行的时间，这个指标非常有助于f发现那些对应用响应时间或者服务器取读取的

获取所有的列

当你看到select *的时候一定要有所怀疑。你真的需要所有的列么？也许不是。获取所有的列可能会使一些优化失效，比如覆盖索引，同样的会增加I/O，内存，CPU的消耗。

一些DBA因为这个原因已经禁用了SELECT *，并且当修改了表的列也会降低了发生错误的几率。

当然，获取一些超出你需要的数据也并不总是不好的。在许多我们研究的案例中，人们告诉我们这种浪费资源的方法可以简化一些开发，它能让开发者在不同的地方使用相同的代码。这一点是可以考虑的，只要你能明白性能的消耗在哪就行了。如果你在程序中应用了一些缓存方案或者有一些其他好的想法，获取不需要的数据还是很有用的。获取和缓存所有的对象可能要比许多单独获取一部分数据要更好些。

MySQL是否检查了过多的数据？

一旦你确定了你的查询获取了所需的数据，你就可以查看查询是否检查了太多的数据。在MySQL中，最简单的消耗指标是：

执行时间

所检查的行数

返回的行数

没有一个指标可以完美的衡量查询的消耗。但是它们能反映出MySQL执行一个查询所访问的数据并且能大约的推算出查询运行的速度。这三个指标都记录在慢查询日志中，因此要想知道是否检查了过多的数据，查看慢查询日志是最好的方法。

执行时间

在第二章我们已经讨论过了，在MySQL5.0以及之前的版本中，慢查询日志有很多的限制。包括了缺乏更细颗粒度的日志。

幸运的是，有许多补丁可以使你记录和测量微秒级别的查询。它们都包含在了MySQL5.1服务器之中了，但是如果你用的是老版本的话，只能打补丁了。要小心的是，不要过度的看重执行时间。看这个指标的原因是它是一个目标的指标，但是在变化的条件下它并不是一直不变的。其他的因素-比如存储引擎的锁，高并发，并且还有硬件-都可能影响到执行的时间。这个指标非常有助于f发现那些对应用响应时间或者服务器取读取的影响的查询语句，但是它不能给出实际的执行时间。