DBA大牛MySQL优化心得

一打开科技类论坛，最常看到的文章主题就是MySQL性能优化了，为什么要优化呢?

因为：

• 数据库出现瓶颈，系统的吞吐量出现访问速度慢
• 随着应用程序的运行，数据库的中的数据会越来越多，处理时间变长
• 数据读写速度缓慢

就是咱们说的“性能问题”，程序员一遇到它总是焦头烂额!

今天小编对MySQL优化总结了一些心得，希望在大家之后的工作中能有所有帮助!

示例二：

not in 和 not exist

如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引;而not exist 的子查询依然能用到表上的索引。所以无论哪个表大，用not exists都比not in要快!

子查询优化

• MySQL 5.6 之前的版本对子查询处理：不会将查询的结果集计算出来用作与其他表做join,outer表每扫描一条数据，子查询都会被重新执行一遍。
• MySQL 5.6 对子查询的处理 ：将子查询的结果集 cache 到临时表里，临时表索引主要用来移除重复记录，并且随后也可能用于做join查询，这种技术在 5.6 中叫做物化的子查询，物化子查询可以看到select_type字段为subquery，而在 5.5 里为DEPENDENT SUBQUERY。
• 子查询一般都可以改成表的关联查询，子查询会有临时表的创建、销毁，效率低下。

straight_join

mysql hint：

Mysql 优化器在处理多表的关联的时候，很有可能会选择错误的驱动表进行关联，导致了关联次数的增加，从而使得sql语句执行变得非常的缓慢。

这个时候需要有经验的DBA进行判断，选择正确的驱动表，这个时候 straightjoin 就起了作用了，下面我们来看一看使用straight_join进行优化的案例：

尝试采用user表做驱动表，使用straight_join强制连接顺序：

高效分页

传统分页：

select * from table limit 10000,10 

limit原理：

• Limit 10000,10
• 偏移量越大则越慢

推荐分页：

复杂关联SQL的优化

• 首先查询返回的结果集，通常查询返回的结果集很少，是有优化的空间的。
• 通过查看执行计划，查看优化器选择的驱动表，从执行计划的rows可以大致反应出问题的所在。
• 搞清各表的关联关系，查看关联字段是否有合适的索引。
• 使用straight_join关键词来强制调整驱动表的选择，对优化的想法进行验证。
• 如果条件允许，对复杂的SQL进行拆分。尽可能越简单越好。

force index

有时优化器可能由于统计信息不准确等原因，没有选择最优的执行计划，可以人为改变mysql的执行计划，例如：

count的优化

按照效率排序的话，count(字段)

总结

MySQL 性能优化 最主要是理解 innodb 的索引原理及结构及 SQL 的执行计划，在不断累积经验的基础上熟能生巧。

文章名称：DBA大牛MySQL优化心得
网站URL：https://www.cdcxhl.com/news/100821.html

成都网站建设公司_创新互联，为您提供定制网站、全网营销推广、营销型网站建设、网站改版、品牌网站建设、虚拟主机

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联