共计 1088 个字符,预计需要花费 3 分钟才能阅读完成。
在优化有问题的查询时,目标应该是找到一个更优的方法获得实际需要的结果,而不是一定总是要求从 MySQL 获取一模一样的结果集
一个复杂查询还是多个简单查询
设计查询的时候一定需要考虑的问题就是,是否需要将一个复杂的查询分成多个简单的查询。
虽然在传统实现中,总是强调需要在数据库层完成尽可能多的工作,这是因为在过去总是认为网络通信、查询解析和优化是一件代价很高的事情。
但是这样的想法对于 MySQL 并不合适,因为 MySQL 从设计上就让连接和断开都很轻量,在返回一个小查询结果方面十分高效。
MySQL 内部每秒能够扫描内存中上百万行的数据,相比之下,MySQL 响应数据给客户端的速度就慢得多。在其他条件都相同的时候,使用尽可能少的查询当然是更好的。但是有时候,将一个大的查询分解为多个小查询是很有必要的。
切分查询
有时候需要对一个大查询分而治之,将大查询分为数个小查询,每个查询功能完全相同,只完成一小部分,每次只返回一小部分查询结果。
删除旧的数据就是一个很好的例子。定期清理大量数据时,如果使用一个大的语句一次性完成的话,可能需要锁住很多数据,占用很多数据并且会阻塞很多小的但是很重要的查询。
将一个大的 DELETE 语句切分成为多个较小的查询可以尽可能小的影响 MySQL 性能。
分解关联查询
很多高性能的应用都会第关联查询进行分解。简单地说,就是对每一个表进行一次单表查询,然后将结果在应用程序中进行关联。比如下面这个查询:
SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
这个查询可以分解成下面这些查询来代替:
SELECT * FROM tag WHERE tag = ‘mysql’;
SELECT * FROM tag_post WHERE tag_id = 1234;
SELECT * FROM post WHERE post.id in (123,456,789);
这样拆分的好处是:
- 让缓存的效率更加高效。 许多应用程序可以方便地缓存单表查询对应的结果对象
- 减少查询时可能遇到的锁竞争
- 在应用层做关联,可以更容易对数据库进行拆分,做到高性能和可拓展
- 查询本身效率也可能随之提升 。在这个例子中使用 IN() 代替关联查询,可以让 MySQL 按照 ID 顺序进行查询,这可能会比随机的关联更加高效
- 可以减少冗余记录的查询。在应用层进行关联查询,意味着对于某条记录应用只需要查询一次,而在数据库中进行关联查询,则可能需要重复的访问一部分数据。这样的重构有助于减少网络和内存的消耗。
- 在应用中实现了哈希关联,而不是使用 MySQL 的嵌套循环关联
: