有好几天没有写文章了, 实在不好意思. 之前就有朋友希望我写写 MySQL 优化的文章. 我迟迟没有动笔, 主要是因为, SQL 优化这个东西, 很广, 技巧也很多. 自己在 SQL 优化方面的知识又还很欠缺. 总觉得还不到分享的. 思考许久, 还是写一篇文章, 记录一下. 就算是抛砖引玉吧!
SQL 优化
SQL 优化是一个分析, 优化, 再分析, 再优化的过程. 站在执行计划的角度来说, 我们这个过程, 就是在不断的减少 rows 的数量. 主要步骤有:
通过 explain 来查看执行计划. 通过这一步骤, 我们能够分析出, 该语句有没有走索引, 索引合不合理的重要依据.《 读懂 MySQL 执行计划 》
缩小范围. 例如使用 < > ,between ...and. 来缩小扫描范围.
(对于该类, 通常可优化于 limit, 时间范围等 SQL, 而且非常有效).
减少连接数量 (对于连接查询, 我们必须尽可能减少每个子连接的结果集数量, 只包含有效数据).
避免类型转换.
之前我们就谈过, 隐式类型转换是最容易疏忽的慢 SQL. 如何避免? 大家可以参考之前的文章《 谈谈 MySQL 隐式类型转换 》.
对于主键连续时而且允许的情况下, 我们甚至可以使用 max(id) 来代替 count(*) 来统计用户数.
用 in 代替 or, 少用 like, 避免使用函数运算.
系统拆分
对于互联网应用, 特别是高并发应用来说, 我们遇到多表连接导致慢 SQL 影响性能时. 我们不应一味的追求在 SQL 上如何优化. 更应该考虑这样的设计是否合理, 是否有拆分的可能性. 所以,
我甚至认为: 系统拆分才是解决慢 SQL 的终极方法.
报表库
其实呀, 有些 SQL 是无法再进行优化的, 为什么这么说呢? 没有在线运算, 没有离线运算, 统计报表如何出? 在一定量级的数据表中, 做统计报表. 即使合理的索引, 也会比较慢, 这时建议将这些 SQL 放入特定的报表库执行. 以免造成主库压力. 性能下降. 对主流程造成影响.
结语
SQL 优化是一个比较广的话题且非常有意思的话. 这篇文章主要给的是一些优化思路, 不足的是并没有给出更多的优化实例. 等攒够了优化实例, 会再次分享出来.
最后: 在留言区也分享一下你们 SQL 优化的思路呗～
来源: http://blog.csdn.net/u010695794/article/details/79202248