新特性解读 | MySQL 8.0 对 limit 的优化

作者:杨奇龙

网名“北在南方”,资深 DBA,主要负责数据库架构设计和运维平台开发工作,擅长数据库性能调优、故障诊断。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


一、前言

提到 limit 优化,大多数 MySQL DBA 都不会陌生,能想到各种应对策略,比如延迟关联,书签式查询等等,之前我也写过一篇优化的文章:https://mp.weixin.qq.com/s/2nSdHiGsu35Yf3fRStzumQ ,有兴趣的朋友可以复习一下。

二、MySQL 8.0 对limit 的改进

对于 limit N 带有 group by ,order by 的 SQL 语句 (order by 和 group by 的字段有索引可以使用),MySQL 优化器会尽可能选择利用现有索引的有序性,减少排序–这看起来是 SQL 的执行计划的最优解,但是实际上效果其实是南辕北辙,相信很多 DBA 遇到的相关案例中 sql 执行计划选择 order by id 的索引进而导致全表扫描,而不是利用 where 条件中的索引查找过滤数据。MySQL 8.0.21 版本之前,并没有什么参数来控制这种行为,但是自 MySQL 8.0.21 之后提供一个优化器参数 prefer_ordering_index ,通过设置 optimizer_switch 来开启或者关闭该特性 。 比如:

SET  optimizer_switch  = "prefer_ordering_index=off";

SET  optimizer_switch = "prefer_ordering_index=on";

三、实践出真知

测试环境 MySQL 社区版 8.0.30

构造测试数据

CREATE TABLE t (
id1 BIGINT  NOT NULL  PRIMARY KEY auto_increment, 
id2 BIGINT NOT NULL,
c1 VARCHAR(50) NOT NULL,
c2 varchar(50) not null,
INDEX i (id2, c1));

insert into t(id2,c1,c2) values(1,'a','xfvs'),(2,'bbbb','xfvs'),(3,'cdddd','xfvs'),(4,'dfdf','xfvs'),(12,'bbbb','xfvs'),(23,'cdddd','xfvs'),(14,'dfdf','xfvs'),
(11,'bbbb','xfvs'),(13,'cdddd','xfvs'),(44,'dfdf','xfvs'),(31,'bbbb','xfvs'),(33,'cdddd','xfvs'),(34,'dfdf','xfvs');
3.1 默认开启参数
mysql  (test) >  SELECT @@optimizer_switch LIKE '%prefer_ordering_index=on%';
+------------------------------------------------------+
| @@optimizer_switch LIKE '%prefer_ordering_index=on%' |
+------------------------------------------------------+
|                                                    1 |
+------------------------------------------------------+
1 row in set (0.00 sec)

查询非索引字段 ,id2 上有索引 ,order by 主键 id1 ,explain 查看执行计划 type index 说明使用索引扫描使用 using where 过滤结果集。这个是优化器的自以为的最优选择,但是实际上遇到数据集合比较大的表,该执行计划就不是最优解,反而导致慢查。

mysql  (test) > explain select c2 from t where id2>8 ORDER BY id1 ASC LIMIT 2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
   partitions: NULL
         type: index
possible_keys: i
          key: PRIMARY
      key_len: 8
          ref: NULL
         rows: 2
     filtered: 69.23
        Extra: Using where
1 row in set, 1 warning (0.00 sec)
3.2 关闭该参数
mysql  (test) > SET optimizer_switch = "prefer_ordering_index=off";

mysql  (test) > explain select c2 from t where id2>8 ORDER BY id1 ASC LIMIT 2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
   partitions: NULL
         type: range
possible_keys: i
          key: i
      key_len: 8
          ref: NULL
         rows: 9
     filtered: 100.00
        Extra: Using index condition; Using filesort
1 row in set, 1 warning (0.00 sec)

经过调整之后,查看执行计划发现优化器选择 id2 索引字段找到记录做过滤,并且使用了ICP 特性,减少物理 io 请求,而不是选择使用主键 id1 遍历索引然后回表查询。

显然 通过人为介入参数调整优化器的行为能带来更好的优化效果。

四、总结

从不同版本的 MySQL 发展轨迹来看 MySQL 的优化器越来越智能 (比如大家期待已久的直方图特性) ,能更多的减少人为干预,提升执行计划的准确性。

have fun with MySQL 8.0 _

<think>我们正在讨论MySQL SQL语句优化。这是一个广泛的主题,涉及多个层面。我将从以下几个方面展开: 1. 理解执行计划(EXPLAIN) 2. 索引优化 3. 查询语句优化 4. 表结构和数据类型优化 5. 服务器参数和配置优化 6. 其他最佳实践 由于用户要求尽可能多的参考上一次的问题(关于Spring Boot异常处理)和回答,但本次问题与上次问题主题不同,因此我们专注于当前问题。 注意:在回答中,我会在适当的地方添引用标识[^1](尽管没有实际引用来源,但按用户要求添),并确保使用LaTeX格式的数学表达式(如需要)。 开始回答:</think>### MySQL SQL语句优化技巧与最佳实践 #### 一、核心优化方法论 1. **性能分析优先原则** 使用`EXPLAIN`分析执行计划是优化的第一步: ```sql EXPLAIN SELECT * FROM orders WHERE customer_id = 100; ``` 关键指标解读: - `type`:访问类型(最优到最差) `system > const > eq_ref > ref > range > index > ALL` - `rows`:扫描行数(值越小越好) - `Extra`:附信息(避免`Using filesort`和`Using temporary`) 2. **性能瓶颈定位工具** ```sql -- 开启性能分析 SET profiling = 1; SELECT * FROM large_table; SHOW PROFILES; -- 显示各查询耗时 SHOW PROFILE FOR QUERY 1; -- 查看详细执行阶段 ``` #### 二、索引优化技巧 1. **索引设计黄金法则** - 最左前缀原则:联合索引$(A,B,C)$有效场景: ```sql WHERE A=1 AND B=2 -- ✓ WHERE B=2 AND C=3 -- ✗ (索引失效) ``` - 覆盖索引优化:索引包含所有查询字段 ```sql -- 创建覆盖索引 CREATE INDEX idx_cover ON orders (customer_id, order_date, total_amount); -- 查询只需扫描索引 SELECT customer_id, order_date FROM orders WHERE customer_id=100; ``` 2. **索引失效场景规避** | 失效场景 | 优化方案 | |---------------------------|-----------------------------------| | 对索引列进行计算 | `WHERE YEAR(order_date)=2023` → `WHERE order_date BETWEEN '2023-01-01' AND '2023-12-31'` | | 使用`NOT`/`<>` | 改为范围查询 | | 隐式类型转换 | 确保比较双方数据类型一致 | | 模糊查询`LIKE '%abc'` | 改为`LIKE 'abc%'` | 3. **索引选择性公式** 创建索引前评估字段选择性: $$ \text{Selectivity} = \frac{\text{COUNT(DISTINCT column)}}{\text{COUNT(*)}} $$ 选择性 > 0.2 适合建索引 #### 三、查询语句优化 1. **JOIN优化策略** - 小表驱动原则:小表作为驱动表 ```sql SELECT * FROM small_table s JOIN large_table l ON s.id = l.small_id ``` - 避免`SELECT *`:只取必要字段 - 分页优化:避免`OFFSET`大偏移量 ```sql -- 低效 SELECT * FROM orders ORDER BY id LIMIT 10000, 20; -- 优化(基于上次ID) SELECT * FROM orders WHERE id > 10000 ORDER BY id LIMIT 20; ``` 2. **子查询优化** 优先使用`JOIN`代替子查询: ```sql -- 低效 SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000); -- 高效 SELECT u.* FROM users u JOIN orders o ON u.id = o.user_id WHERE o.amount > 1000; ``` 3. **批量操作优化** 使用批量插入代替单条插入: ```sql -- 低效(约10秒/万条) INSERT INTO logs (msg) VALUES ('msg1'); INSERT INTO logs (msg) VALUES ('msg2'); -- 高效(约0.5秒/万条) INSERT INTO logs (msg) VALUES ('msg1'), ('msg2'), ... ('msg1000'); ``` #### 四、表结构与数据类型优化 1. **数据类型选择原则** | 场景 | 推荐类型 | 空间节省 | |---------------------|------------------|-------------------| | 整数 | `TINYINT`/`INT` | `BIGINT`的50% | | 小数 | `DECIMAL(18,2)` | 精确计算 | | 短文本(<255字符) | `VARCHAR` | 变长存储 | | 大文本 | `TEXT` | 独立存储 | 2. **范式与反范式平衡** - 第三范式(3NF):减少数据冗余 - 适度反范式:增冗余字段提升查询速度 ```sql -- 订单表增"用户姓名"冗余字段 ALTER TABLE orders ADD customer_name VARCHAR(50); ``` 3. **分区表优化** 按时间范围分区提升查询效率: ```sql CREATE TABLE logs ( id INT AUTO_INCREMENT, log_time DATETIME, content TEXT, PRIMARY KEY (id, log_time) ) PARTITION BY RANGE (YEAR(log_time)) ( PARTITION p2020 VALUES LESS THAN (2021), PARTITION p2021 VALUES LESS THAN (2022), PARTITION p2022 VALUES LESS THAN (2023) ); ``` #### 五、服务器级优化 1. **InnoDB关键参数** ```ini # my.cnf配置 [innodb] innodb_buffer_pool_size = 16G # 建议内存的70-80% innodb_log_file_size = 2G # 减少写操作 innodb_flush_log_at_trx_commit = 2 # 事务提交策略 ``` 2. **查询缓存取舍** MySQL 8.0+已移除查询缓存,低版本建议关闭: ```ini query_cache_type = 0 query_cache_size = 0 ``` #### 六、高级优化技术 1. **索引下推(ICP)** MySQL 5.6+默认启用,减少回表次数: ```sql -- 联合索引 (last_name, first_name) SELECT * FROM employees WHERE last_name='Smith' AND first_name LIKE 'J%'; ``` ICP在存储引擎层过滤数据[^1] 2. **MRR优化(Multi-Range Read)** 随机IO转顺序IO: ```ini # my.cnf optimizer_switch='mrr=on,mrr_cost_based=off' ``` 3. **直方图统计(MySQL 8.0+)** 优化非均匀数据分布查询: ```sql ANALYZE TABLE orders UPDATE HISTOGRAM ON price; ``` #### 七、优化流程总结 ```mermaid graph TD A[发现慢查询] --> B[EXPLAIN分析] B --> C{问题类型} C -->|索引问题| D[优化索引] C -->|JOIN问题| E[重写查询] C -->|数据量过大| F[分库分表] D --> G[性能测试] E --> G F --> G G -->|达标| H[完成] G -->|未达标| B ``` > **最佳实践**:监控 + 分析 → 实施 → 验证 → 迭代[^2] #### 八、性能监控工具 | 工具 | 用途 | |--------------------|---------------------------| | `SHOW PROCESSLIST` | 实时查看线程状态 | | `Percona Toolkit` | 高级分析工具包 | | `Prometheus`+`Grafana` | 可视化监控 | | `Slow Query Log` | 记录慢查询 | --- ### 相关问题 1. 如何解读`EXPLAIN`输出中的`key_len`字段? 2. 在分库分表场景下如何优化跨片JOIN查询? 3. MySQL的`FORCE INDEX`和`USE INDEX`提示有什么区别? 4. 如何为JSON类型字段创建高效索引? 5. 在云数据库(RDS)环境中有哪些特殊的优化注意事项? [^1]: 索引下推技术将WHERE条件过滤下推到存储引擎层执行 [^2]: 持续监控是保持数据库性能的关键环节
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值