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
这个缓冲区当中, 所以, 内存越大, 缓冲区就可以配置的越大, 性能自然提升.磁盘类型
也能提升数据库的查询效率, 固态硬盘优越的读性能, 就极其适合放在从库上面, 分担数据的读压力.
SQL查询优化
http://www.zhangdeman.cn/archives/54e07f3b.html