在这篇文章中，我将重新探究ProxySQL中的Query Rewrite功能，因为query rewriting是创建ProxySQL的最根本初衷。 为什么我们需要重写查询？这儿举例你作为DBA发现了一个“坏查询”，你确认是它导致了服务缓慢，并且可能会导致服务不可用。那这个查询必须被优化，你和开发沟通要修正这个SQL，但是开发反馈回来的信息是能改，但是由于技术的非技术的种种原因吧，没有那么快。这时你怎么办，等着？显然不能，你可以在开发完成修正之前通过ProxySQL的Query Rewrite功能重写某些查询来完成优化同时对应用保持透明。如何重写查询？通过ProxySQL有两种方式来完成（译者注：其实应该理解为两种匹配查询的方式）。Query rewrite其实就是通过 mysql_query_rules 表中一个 match_pattern + replace_pattern 的过程，而match_digest （注意区分 match_pattern 和 match_digest ）仅用来匹配一个查询，而非重写它。逻辑上讲，match_digest 和 username，schemaname，proxy_addr 等字段的作用是一样的，仅用来匹配查询。这两种不同的机制为不同的查询类型（例如DML操作，SELECT等）提供了灵活高效匹配方式。注意如果你希望重写查询，那么规则中的match_pattern必须能匹配到原始的查询。查询规则按照rule_id字段的升序顺序处理，并且只有在active字段为1的前提下才会处理。下面是我们如何在我们的测试环境演示 match_digest 如果想清空 query rules 的统计信息，使用下列方法接下来是 match_pattern 示例：路由规则中一个关键点是 mysql_query_rules 的 apply 字段（译者注：类似于nginx rewrite 指令中的 break 参数）如下面测试中所展示的，所有匹配rule_id = 10 或 rule_id = 20 的查询都准确的匹配上了。实际上，现在所有的规则在 runtime_mysql_query_rules 表中都是激活的。如果我们想禁用 mysql_query_rules 表中某条规则，设置 active = 0另外，ProxySQL还能帮忙识别出“低效的查询”，登录管理界面按如下操作
找出总耗时最多的查询找出平均耗时最高的查询我发现关于ProxySQL query rewrite 的“最好”的文档在IBM，这里介绍了查询重写的原理和示例，值得一读。还有一些别的场景你可能需要重写查询，试想有一张表的自增ID列已经达到了int类型的最大值，你可以将新插入的数据重定向到另一张表同时你通过alter命令来修正原表的问题，在这期间所有的查询还将访问原表，等alter原表完成后，将新表的数开发云主机域名据导入的原表，即可达到不停机修DDL的效果。从MySQL 5.7.6 起，MySQL以插件形式提供了 query rewrite 功能，你可以在这里找到相关文档。MySQL内建的查询重写功能的一个最大的劣势在于重写规则仅作用于当前MySQL实例，这也是相比之下ProxySQL 的优势所在：它处在应用和数据库之间，所以它的重写规则是全局的。原文链接
相关推荐: MySQL—MMM高可用群集的搭建（全过程，纯干货~~）
其中，配置ALI云源（若已安装可跳过）这里以master1作示范，实际五台均需要安装给所有主从服务器安装MySQL，并配置m1给m2从权限，m2给m1从权限配置两台从服务器指向master1修改mmm_common配置文件修改mmm_monitor配置文件（仅…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
