SQL查询优化

写在前面

大家经常听到此类问题 : 1亿条数据如何优化, 提高查询效率? , 单纯这一句话, 其实是毫无意义的.什么是优化? 遇到了某一个瓶颈, 解决了这个瓶颈, 才是优化. 任何一个问题， 一定是伴随着某一个或几个场景出现的. 同样的问题, 不同场景下的解决方案可能千差万别, 任意的问题, 一定得是加上场景, 才有其实际意义. 否则就是单纯的臆想. 相面就从几个具体的场景来介绍, 查询慢的时候, 如何做优化. 注意是 查询优化 , 而非单纯的SQL优化, 数据库查询优化是一个 综合工程 , 会涉及方方面面的各种知识, 根本无法一言以蔽之.

软件层面一些经验

• SQL语句尽量简单
• SQL语句无法简单, 可以采用空间换时间的方式, 查询字段按照自身需求来, 不要直接查询所有字段, 减少IO
• 表设计层面, 未必必须按照三大范式来设计, 有时候反范式设计会有更好的效果.
• 主键无论如何都要使用单调递增的数字
• 索引层面, 针对索引查询, 尽量走 索引覆盖 , 避免 二次回表

慢查询日志

https://juejin.cn/post/7147941447029751822

SQL语句分析

主键查询慢

条件查询慢

分组聚合慢

深度分页慢

深度分页 不要通过 limit offset 来查询, 要使用 游标 的思想来查询

工程优化

数据缓存

应用检索场景

数仓场景

数据库优化

• 分库分表 一般是能最快速度解决查询慢的问题, 但是可能软件应用层面可能会带来较大影响
• 运维部署层面, 做主从集群 , 能够迅速将数据库的读能力扩展一倍甚至几倍

硬件优化

• 内存、CPU升级均可提高性能 , 有限成本内, 可优先升级内存, 因为Mysql这种OLTP数据库(OnLine Transaction Processsing 联机事务处理, 是与功能、业务强相关的事务查询系统，要保证高并发场景下低时延的查询和处理效率), 大部分是IO密集型操作, 特点就是对 内存要求高 , 对CPU 要求相对较低, 而且 innodb 存储引擎有一个特点, 将 数据、索引等 , 均放在了 inndb buffer pool 这个缓冲区当中, 所以, 内存越大, 缓冲区就可以配置的越大, 性能自然提升.
• 磁盘类型 也能提升数据库的查询效率, 固态硬盘优越的读性能, 就极其适合放在从库上面, 分担数据的读压力.