MERGE引擎类型可以把许多结构相同的表合并为一个表。通过对merge表的简单查询，可以轻松实现对多个子表进行查询的目的。
我们的日志系统按照月为单位进行分表，由merge联合所有月份子表，实现跨月（跨表）的日志查询。这样的做法是程序端的逻辑比较简单，无需关注多表的数据整合和处理。
随着子表越来越多、数据越来越大，查询的速度越来越慢。子表的数据量增长并非数量级的，那么从理论上讲通过merge进行查询，速度受到影响的浮动应该是很小的，但现实却非如此。
刚开始并不知道原因，通过profiling检查详细的耗时情况，发现Sending data占用了99%的时间，从官方解释来看，Sending data貌似是发送数据到client端的耗时，检查了一下，仅仅只有几K的数据发送，明显不是此原因。SQL挺简单的，基本的优化也都做了，那么是什么原因？
之后调试代码时无意中针对一个子表进行了一次查询，发现速度几十倍的提高，之前对merge的查询需要20多秒，现在仅仅不到1秒就执行完了，这个感觉是很明显的，于是进一步进行了测试，发现问题的确如此。
所以，建议还是在代码逻辑中对多表数据进行处理，避免使用Merge引擎。
有时间看一下源码中Sending data是如何计算的以及Merge是如何进行多表数据集合的。 希望Mysql能把Merge引擎做的更加稳定、高效，真正发挥Merge引擎的优势。
来源：http://hi.baidu.com/chancey/blog/item/775d8682db4387a90df4d20e.html
我们的日志系统按照月为单位进行分表，由merge联合所有月份子表，实现跨月（跨表）的日志查询。这样的做法是程序端的逻辑比较简单，无需关注多表的数据整合和处理。
随着子表越来越多、数据越来越大，查询的速度越来越慢。子表的数据量增长并非数量级的，那么从理论上讲通过merge进行查询，速度受到影响的浮动应该是很小的，但现实却非如此。
刚开始并不知道原因，通过profiling检查详细的耗时情况，发现Sending data占用了99%的时间，从官方解释来看，Sending data貌似是发送数据到client端的耗时，检查了一下，仅仅只有几K的数据发送，明显不是此原因。SQL挺简单的，基本的优化也都做了，那么是什么原因？
之后调试代码时无意中针对一个子表进行了一次查询，发现速度几十倍的提高，之前对merge的查询需要20多秒，现在仅仅不到1秒就执行完了，这个感觉是很明显的，于是进一步进行了测试，发现问题的确如此。
所以，建议还是在代码逻辑中对多表数据进行处理，避免使用Merge引擎。
有时间看一下源码中Sending data是如何计算的以及Merge是如何进行多表数据集合的。 希望Mysql能把Merge引擎做的更加稳定、高效，真正发挥Merge引擎的优势。
来源：http://hi.baidu.com/chancey/blog/item/775d8682db4387a90df4d20e.html
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/3386/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
serialize(),var_export(),json_encode
如何查看某个Innodb库的大小？ 评论列表
