MySQL 重写查询语句的三种策略

对于一个数据库开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《MySQL 重写查询语句的三种策略》，主要介绍了语句、查询、MySQL重写，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

在优化存在问题的查询时，我们需要改变方式去获取查询结果——但这并不意味着从 MySQL获取同样的结果集。有些时候我们可以将查询转换为获取相同结果，但更好性能的查询形式。然而，我们也需要考虑重写查询去获取不同的结果，因为这样可以提高开发效率。也可以通过修改应用程序代码来取得相同的效果。本篇文章将介绍如何重写查询的技巧。

复杂查询与分步查询

一个重要的查询设计课题是将复杂查询分解为多个简单查询是否会更好。在传统的数据库设计中强调尽可能地用更少的查询解决大量工作。在过往，这种方式会更好。这是因为以前的网络通讯成本更高以及考虑查询解析器和优化器的负荷。

然而，这种建议并不怎么适用于 MySQL，这是由于 MySQL 处理建立连接和断开连接的方式十分高效，并且对简单查询的响应很快。当今的网络速度相比以前也有了大幅度的提升。根据不同的服务端版本，MySQL 可以在普通机器上一秒内运行超过10万次的简单查询，并且在千兆网络上完成每秒2000次的查询通讯。因此，进行分布查询并不是过往说的那么糟糕。

相比于每秒遍历的数据行数，连接响应依旧是比较慢的。在内存数据中，这个时间达到了毫秒级。当然，使用尽可能的查询次数依旧是一个不错的选择。但是，有时我们可以通过拆分复杂查询为几个简单的查询来提高性能。接下来我们将展示一些示例。

在程序设计中，使用过多的查询是一个常犯的错误。例如，有些应用执行了10个单独的查询来获取10行数据（使用循环一条条获取），而这本可以通过一条查询10行数据的查询来完成。因此，这并不是倡导每次都做查询的拆分，而是根据实际情况来。

切分查询语句

另一个方式是拆分查询后重新再组合。通过在大数据量的查询拆分为更小范围的查询以减少每次影响的行数。

清洗旧数据就是一个典型的例子。周期性的清洗数据工作需要移除大量数据，进行这样的操作会长时间锁定大量数据行。这种操作还会产生事务日志、消耗大量资源并且会阻塞那些本不应该被打断的小数据量的查询。将DELETE语句切分后，使用中等规模的查询可以显著改善性能，并且在查询是重复的时候可以减少重复查询产生的额外延迟。例如下面的删除语句：

DELETE FROM messages WHERE created 

<p>应用的伪代码的形式如下：</p>

<pre class="brush:cpp;">
rows_affected = 0
do {
  rows_affected = do_query (
  "DELETE FROM messages WHERE created  0

一次删除10000行对于提高每次查询的效率来说已经是一个足够大的任务了。一个足够短的任务会减少对服务端的影响（事务存储引擎会从中受益）。在 DELETE 语句中插入一些休眠时间也是一个不错的主意，这样可以在时间上分散负荷并且缩短持有锁的持续时间。

拆解联合查询

很多高性能的应用会拆解联合查询。可以通过将联合查询拆分为多个单表查询，然后在应用中再将结果组合起来。例如：

SELECT * FROM tag
	JOIN tag_post ON tag_post.tag_id=tag.id
  JOIN post ON tag_post.post_id=post.id
WHERE tag.tag='mysql';

可以将这个联合查询拆分如下是哪个部分。

SELECT * FROM tag WHERE tag='mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123, 456, 567, 9098, 8904);

注：这里的 tag_id=1234和post.id IN (123, 456, 567, 9098, 8904)都是基于前面查询的结果得到的值。为什么要这么做？第一眼看过去好像是毫无必要的——增加了查询的次数而已。然而，这种重建查询可以带来如下优势：

• 缓存机制会更有效。很多应用直接使用 ORM 映射数据表。在这个例子中，如果 tag 为 mysql 的对象已经被缓存了，第一条查询就会跳过。如果 posts 中 id 为123，567或9908在缓存中，则可以从 IN 列表中移除这几个。通过这种策略，查询缓存会得到相应的受益。如果只有其中的一个表经常变化，拆解联合查询可以减少缓存失效的次数。
• 单独执行这些查询有时候可以减少锁表的机会。
• 通过这种方式很容易扩展数据库，并把数据表放到不同的机器上。
• 查询自身可以进行优化。这个例子中，使用 IN 查询替代联合查询后，MySQL 对行 ID 进行排序和获取数据行有可能会更优。
• 可以减少冗余的行访问。使用这种方式意味着只做一次数据行获取，而在联合查询中有可能重复获取相同的数据。基于这种原因，这种拆解方式也可能会减少整个网络负荷和内存占用。
• 扩展一下，也可以通过人为进行哈希联合查询来替代MySQL联合查询的嵌套循环，哈希联合查询也可能会更有效。
  

最终可以看到，通过拆解联合查询可以使得缓存复用性更高，多服务器分布式数据方案更简单，并可以在大的数据表中使用 IN 查询替代联合查询或同一张表的多次重复查询。

到这里，我们也就讲完了《MySQL 重写查询语句的三种策略》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于mysql的知识点！