MYSQL多层面优化总结

Posted 2023-02-03 守拙的厨子

关于数据库优化是一个老生常谈的问题, 这块也有很多既有的经验. 下面就这个问题谈一下我在平时工作中的一些总结. 着重从多个层面来总结这块的优化技巧.

硬件层面

1. 使用高速的存储设备, ssd 或者 Fusion io卡
2. 考虑使用磁盘阵列

---

操作系统层面

• 尽可能的扩大innodb buffer pool，一般设置为物理内存的3/4

对innodb引擎而言, 读写操作对缓冲池的依赖非常高, 较大的缓冲池可以有效提高读写性能

• mysql写日志是顺序io, 可以借助内核缓冲提高写日志的速度; 写数据是随机io, 所以写数据尽量使用 direct io, 不使用内核缓冲反而效率更高.
  -

---

server和存储引擎层面优化

1. 将日志文件和数据文件配置到不同的磁盘路径, 提高数据库并行io能力. 特别是在binlog打开的情况下

2. 合理的日志和事务参数配置, 这里主要指sync_binlog和innodb_flush_log_at_trx_commit两个参数, 需要根据自身的业务场景, 设置合理的值, 很多时候需要兼顾性能和可靠性.

sync_binlog=1, innodb_flush_log_at_trx_commit=1 每一次数据变更, 每次事务将日志写到redo log并且刷到磁盘, 保证数据和事务最大程度不丢, 同时效率最低
sync_binlog=100, innodb_flush_log_at_trx_commit=2 每100次数据变更刷binlog到磁盘; 每次事务提交将redo log提交到内核缓冲, 每1s执行一次刷盘动作.—> 较高性能, 可能丢数据或者事务

---

下面分析应用层面进行优化

数据库设计层面的优化

• 根据自身的业务场景, 合理的范式和反范式设计

遵从范式意味着最少的数据冗余, 但这也表示你在查询的时候需要更多的join操作. 这对于互联网中高并发的应用场景来说是致命的. 很多时候在做表设计的时候需要适当的冗余, 做反范式设计

• 根据业务对数据库进行垂直和水平拆分(这里不展开讲)

---

索引层面优化

索引层面主要是高效的索引策略, 要理解, 索引也是一种空间换时间的策略, 在换取时间的同时也有一定的开销, 若索引失当, 可能开销大于收益.下面介绍较好的建索引策略

1. 对查询,排序, 分组的字段建立索引, 是最基本的索引策略
2. 对于建索引的列, 该列的选择性应该尽量高. 比如:性别这种列, 没有必要建立索引.
3. 若一列经常被修改, 对该列建立索引需要斟酌(考虑修改索引的开销)
4. 对长度较长的字段建立索引要特别小心, 只能针对其固定长度前缀建立索引(长度较长字段建立索引, 索引文件会比较大, 占用较多磁盘空间的同时, 检索索引的时候对io资源消耗也较大)
5. 复合索引, 主要是在建立复合索引的时候, 将选择性较强的列放置在前.
6. 避免冗余索引, 比如index(a,b)存在的情况下, 再建index(a)就完全冗余了, 但index(b)可能是需要的

---

SQL应用层面的优化

这块主要是在应用中对sql的应用, 我们主要可以从以下几个查询的开销 指标来进行优化: 响应时间, 扫描行数, 返回行数, 访问数据类型

• 是否向数据库请求了不需要的数据

 查询了多余的行(比如常见的分页,  查询了大量数据, 然后limit)
 多表关联的时候, 返回全部的列(审视 select *)

• 关注执行计划 (最直接用于分析sql执行效率的手段)

数据访问类型(全表扫描, 索引扫描, 索引范围扫描, 唯一索引扫描 …)
扫描是数据行数
返回的数据行数
是否有走索引, 走的什么索引
返回的数据行数
是否有临时表, 文件排序, 可否利用索引优化

• 合理利用覆盖索引

减少回表扫描
分页的情况使用延迟关联

• 利用查询缓存, 配置查询缓存大小

当一个表中有更新操作(update/insert), 涉及到这
个表的所有查询缓 存都会失败