【SQL】MySql常见的性能优化方式

一、引言

• 近期参加了数据岗位的一些面试（如下图：近几年的面试数据），非常多的同学在简历上会写熟悉、精通SQL，但一旦进行原理性（对应数据开发岗）或者实操性（数据分析、数据产品岗）的沟通和测试，往往表现的不尽如人意。所以打算再开一个【SQL】的专栏，分享一些SQL的知识和技巧。
• SQL专题往期内容：
  • 【SQL】基于多源SQL 去重方法对比 – 精华版
  • 【SQL】常见SQL 行列转换的方法汇总 - 精华版
    

二、MySQL性能优化的常用方式及对比说明

1. 索引优化

1.1 合理创建索引​

• 方式​：为高频查询字段（如WHERE、JOIN、ORDER BY中的列）创建索引，优先使用联合索引并遵循最左前缀原则。
• 对比优势​：减少全表扫描，提升查询速度，但过多索引会增加写入开销（如INSERT/UPDATE/DELETE）。
• 适用场景​：查询频繁但数据更新较少的表，如订单表、用户表。

1.2 ​覆盖索引​

• ​方式​：通过联合索引包含查询所需字段，避免回表操作。
• ​对比优势​：减少磁盘I/O，但需牺牲索引存储空间。
• 适用场景​：高频查询且字段固定的场景，如统计类查询。

1.3 ​索引下推

• 方式​：在索引遍历时提前过滤非索引字段条件，减少回表次数。
• 对比优势​：提升模糊查询效率（如LIKE ‘xx%’），仅适用于二级索引。

2. SQL语法优化

2.1 ​避免低效操作​

• ​方式​：避免全表扫描 SELECT *等、隐式类型转换、函数操作字段、前导通配符（LIKE '%abc%）
• 对比优势​：减少CPU和I/O消耗。

2.2 ​分页优化​

• ​方式​：使用分页或延迟关联，避免LIMIT 偏移量过大问题。
  ​对比优势​：减少临时表生成，但需业务支持连续ID或时间戳排序。

# 示例
SELECT * FROM login_logs WHERE id > 1000000 ORDER BY id LIMIT 100;

2.3 ​JOIN优化​

• ​方式​：大小表关联时，优先JOIN，避免子查询。（同Hive或大数据框架的MAPJOIN一样，避免大小表间数据倾斜和减少shuffle）
• ​对比优势​：减少中间结果集大小。

3. 配置与架构优化

3.1 参数调优​

• ​核心参数​：

innodb_buffer_pool_size：设置合理的物理内存，提升缓存命中率。
max_connections：合理设置最大连接数

• 对比优势​：提升吞吐量，比较吃硬件资源

3.2 ​读写分离与分库分表​

• 方式​：
  • 垂直拆分​：比如按业务模块拆分，如用户主库、订单库
  • 水平拆分​：按哈希或范围分片
• ​对比优势​：解决单表数据量过大问题，但增加事务管理和查询复杂度。

3.3 ​缓存机制​

• 方式​：Redis缓存热点数据，或开启MySQL查询缓存，和版本关系较大
• 对比优势：减少数据库压力。

4. 存储与维护优化

4.1 ​存储引擎选择​

• ​方式​：InnoDB支持事务和行锁，适合高并发写入，MyISAM适合读密集型场景。
• ​对比优势​：需选择合适的业务场景。

4.2 定期维护​

• 方式​：
  • 重建索引（OPTIMIZE TABLE），清理碎片，清理历史数据等；
  • 冷热数据分离，冷数据转至成本更低数据库等；
• ​对比优势​：可能引起短暂性能波动，但表结构稳定

三、对比总结

​优化方向​​	常用方法	适用场景	优势​​	劣势
​索引优化	联合索引、覆盖索引	高频查询	较大提升查询速度	增加写入开销，需定期维护
SQL语法优化	分页优化、避免全表扫描	复杂查询或大数据量分页	简单，减少资源消耗	统一约定规范
配置与架构优化	参数调优、分库分表	高并发或超大规模数据	提升系统吞吐量	复杂度高
存储与硬件	SSD、内存升级	I/O密集型或预算充足的环境	成本高，需停机维护	监控和人力成本高