mysql 添加limit,sql 语句执行时间变长的问题

最新推荐文章于 2024-11-04 19:36:12 发布
转载 最新推荐文章于 2024-11-04 19:36:12 发布 · 2.4k 阅读 · 1
文章标签：

#调优 #mysql #explain  #执行计划 #limit

本文介绍了一种通过修改SQL语句来提高查询效率的方法。当使用order by与limit结合时，MySQL会扫描全部数据进行排序，导致性能下降。文章提供了一个解决方案，即使用子查询的方式减少全表扫描，显著提升了查询速度。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 调优一个sql语句，在语句本身是很简单的查询

select * from a where id > 1 order by addtime desc  limit 10

查询的结果集很小 只有10

修改为 limit 1后，依然很慢大概2s的查询时间。

explain 发现没有使用索引，去掉limit后，查询出几千数据，0.02s的查询时间，

后来查证mysql官方文档，在order 的同时使用limit，将会对所有数据进行扫描重排，所以效率差。

而只需要10条数据，查询出再程序上取略麻烦。

改为：

select * from (select * from a where id > 1 order by addtime desc) b limit 10 

效率很高，而且无序再程序上进行改动了

分页查询LIMIT慢SQL优化
kirito_lewis的博客
05-28 924
一、问题描述 在做分页查询的时候，遇到一个问题。之前做分页查询的功能的时候，都是从前端页面发回 searchCondition（查询条件）、curPage（当前页面）、pageSize（页面记录条数）两个参数，然后通过构造 sql 语句，实现查询的功能。 比如说，查询性别为男，年级是21级的学生，分页是第10页，每页30条数据，那么发回的内容中: {searchCondition:{'sex':'male','grade':'2021'}, curPage: 10, pageSize: 30} 按照上面逻辑
mysql用limit取数慢_mysql – LIMIT 1非常慢,对于特定的记录,使用不同的键
weixin_35662051的博客
01-28 887
我正在诊断间歇性慢查询,并在MySQL中发现了一个奇怪的行为我无法解释.对于一个特定的情况,它只是选择一个不同的,非最优的关键策略,只有当做LIMIT 1时.表(为简洁起见,删除了一些未引用的数据列)CREATE TABLE `ch_log` (`cl_id` BIGINT(20) NOT NULL AUTO_INCREMENT,`cl_unit_id` INT(11) NOT NULL DEFA...
MYSQL分页limit速度太慢优化方法
iteye_16982的博客
10-10 1224
当一个表数据有几百万的数据时，分页的时候成了问题 如 select * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢，可以按照一下方法解决 最近一个网站的服务器评论被人刷死，导致mysql数据库异常发生too many open connections   引发的SQL语句  代码如下复制代码   SELECT ...
数据库中使用order by 和limit查询变慢解决办法
weixin_34352449的博客
12-22 471
2019独角兽企业重金招聘Python工程师标准>>> ...
mysql limit耗时过长
qq_41633199的博客
02-04 1212
limit运行机制是先检索符合条件的指定数量的数据，再对数据进行截取，这样数据量很大的时候就会有性能问题，这里介绍的是运用数据表索引对limit查询进行优化。 一下面一张200万数据的表为例： 传统limit SELECT * FROM tableName ORDER BY id LIMIT 1000000,100; 时间: 5.371s 子查询方式，索引扫描 SELECT * FROM t...
mysql--大数据表order by + limit 导致查询缓慢问题
yizhihuli的博客
11-19 4547
问题描述：数据表有3000万行，单表分页查询，count时间在10s内，limit查询需要一分钟左右；表的索引非常多，几乎每写一个sql都会创建对应的索引， sql类似： select [data] from [table] where [condition] order by [sort] limit ? 尽管数据量很大，但也很慢的离谱了。查阅资料加上自己的尝试，发现sql慢的原因是mysql优化器默认选择了sort字段的索引，这个字段是个时间戳，区分度比较小，所以查询就会很慢。 跟业务沟通，他们坚持不允
mysql优化limit查询语句的5个方法
12-15
mysql的分页比较简单，只需要limit offset,length就可以获取数据了，但是当offset和length比较大的时候，mysql明显性能下降 1.子查询优化法 先找出第一条数据，然后大于等于这条数据的id就是要获取的数据 缺点：...
SQL语句执行深入讲解（MySQL架构总览->查询执行流程->SQL解析顺序）
09-09
本文将深入讲解SQL语句在MySQL中的执行过程，包括MySQL的架构总览、查询执行流程以及SQL语句的解析顺序。 首先，我们来看MySQL的架构总览。MySQL是一个分层的系统，主要分为两个层次：SQL Layer（SQL层）和Storage ...
Oracle Sql语句转换成Mysql Sql语句
02-17
本项目提供了一个Java源码工具，能够帮助用户便捷地将Oracle SQL语句转换为MySQL SQL语句。 Oracle SQL与MySQL SQL的主要差异在于以下几个方面： 1. **数据类型**：Oracle支持的数据类型如NUMBER、LONG、RAW等在...
MySQL优化SQL语句的技巧
09-08
MySQL优化SQL语句的技巧是数据库管理员和开发人员提高系统性能的关键技能。本文主要探讨了四种常见的SQL优化策略，旨在帮助开发者更好地理解和改进SQL查询性能。 1. **分解SQL**： 在面对复杂的SQL查询时，一个...
SQL语句执行深入讲解（MySQL架构总览-查询执行流程-SQL解析顺序）
12-15
本文将深入探讨MySQL数据库系统中的SQL语句执行过程，包括MySQL的架构总览、查询执行流程以及SQL语句的解析顺序。 首先，我们来看MySQL的架构总览。MySQL架构分为两个主要层次：SQL Layer（SQL层）和Storage Engine...
慢SQL-mysql in + order by id + limit 导致的慢SQL
一个技术菜鸟的博客
04-10 3450
背景 有通知表，建表SQL如下： CREATE TABLE `perf2_notice_info` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `notice_type` varchar(32) DEFAULT NULL COMMENT '通知类型: ALIWORK_TODO_TASK、EMAIL', `deal_status` varchar(32) DEFAULT 'NOT_START' COMMENT '
order by --- limit 导致查询速度慢
Mr1ght的博客
11-15 1727
当 limit 的数据大于查询的总数据量的时候。此时使用的是文件排序，他会全表从头开始扫描，直到把整个表都扫描完。最后不管够不够 limit 的数量，都会将结果返回。这时就会导致查询速度很慢
查询语句写了limit 1，为什么依然很慢？
华为云官方博客
05-31 1521
很多时候计算引擎会对语句进行代价估计并调整语句的执行顺序。执行计划是语句如何执行的直观表达。语句如何执行不能只关注语句写法，要想写出符合预期执行顺序的查询语句，还需要关注语句执行计划。
MySQL查询之limit耗时原理分析
上善若泪
09-18 1480
文章目录1 需求说明1.1 问题复现1.2 limit耗时1.2.1 limit耗时复现1.2.2 limit耗时原理 1 需求说明 有一张财务流水表，未分库分表，目前的数据量为9555695，分页查询使用到了limit，优化之前的查询耗时16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms)，按照下文的方式调整SQL后，耗时347 ms (execution: 163 ms, fetching: 184 ms)； 解决操作：查询条件放到子查询中，子查询
Mysql 大表limit查询优化&原理&实战
jianghuchuang的博客
11-04 693
答：正常情况下不行，例如你select * ，那么此时你的查询耗时会和优化前查询耗时一样，因为此时你的查询不是覆盖索引查询，由于非聚簇索引里面没有你要select的内容，故而innodb直接就不借助非聚簇索引找第8w条记录；：由于你的叶子存的是记录的ID，一个叶子节点占用空间小，故而一次IO可以查询到大量的叶子节点，故而只需要少次IO次，才能快速找到第8w条记录的ID。：由于你的叶子存的是数据，一个叶子节点占用空间大，故而一次IO可能查询到少数的叶子节点，故而需要IO很多次，才能找到第8w条记录。
SQL优化——limit1
qq_45979629的博客
11-15 1506
还在用 select count(*) from xx where xx=?吗
MySQL-explain-局限
浩然的博客
02-04 319
MySQL中explain的局限性
MySQL进阶-----limit、count、update优化
m0_73633088的博客
04-15 2298
上一期我们学习了order by优化和group by优化，本期我们就继续学习sql语句的优化，分为以下三个部分MySQL进阶-----limit、count、update优化。
sql语句执行时间过长如何优化
最新发布
03-28
<think>嗯，用户想优化执行时间过长的SQL语句。首先，我需要回想一下常见的SQL优化方法。索引优化应该是关键，比如确保WHERE和JOIN的列有索引。不过，联合索引的顺序也很重要，可能需要调整。然后，避免全表扫描，比如使用函数或通配符开头的LIKE查询，这些都会影响性能。 接下来是SQL语句本身的写法。子查询太多可能会拖慢速度，或许可以改成JOIN。还有，减少SELECT *，只取需要的字段。分页优化方面，大的OFFSET可以用WHERE条件替代，比如用id > 上一页最大值来分页。 数据库结构设计方面，分区表或分表可以处理大数据量的情况。数据类型不合适也可能导致问题，比如用VARCHAR存数字，这会影响比较和排序的效率。冗余字段有时候能减少JOIN操作，但需要权衡数据一致性。 执行计划分析也很重要，用EXPLAIN看看有没有全表扫描或者索引没用到的情况。另外，控制事务的大小，避免长时间锁表。批量操作比逐条处理更高效，特别是INSERT和UPDATE。 还有外部工具，比如慢查询日志，找出具体哪些SQL需要优化。缓存机制，比如应用层缓存或者MySQL的查询缓存，不过注意缓存失效的情况。连接池管理也能减少连接开销。 可能需要结合用户提供的引用内容。引用[1]提到了索引和查询语句规范，引用[2]提到复杂SQL难以理解和性能低下，引用[3]的例子是长SQL的问题。所以应该强调简化SQL结构，拆分复杂语句，使用工具分析执行计划。 还要考虑用户可能的场景，比如处理大数据表，有死锁或超时问题。需要综合索引优化、语句重构、数据库结构调整和工具使用来全面解决。最后，提醒用户优化前备份数据，避免意外影响。</think>### 如何优化导致执行时间过长的SQL语句？ #### 一、索引优化（核心方法） 1. **确保关键字段有索引** - WHERE、JOIN、ORDER BY、GROUP BY涉及的列需建立索引，但需避免过度索引（影响写入性能） - 联合索引遵循最左前缀原则：若索引为$index(a,b,c)$，则条件$where\ a=1\ AND\ b>5$可用索引，但$where\ b>5$无法使用 - 示例优化：将`SELECT * FROM orders WHERE create_time > '2023-01-01'`的`create_time`字段添加索引[^1] 2. **避免索引失效场景** - 对索引列使用函数：`WHERE YEAR(create_time)=2023` → 改为范围查询`WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'` - 隐式类型转换：`WHERE mobile = 13800138000`（mobile是varchar类型）会导致全表扫描 - 前导通配符查询：`WHERE name LIKE '%张%'`无法使用索引 #### 二、SQL语句优化（直接影响执行效率） 1. **减少数据扫描范围** - 使用分页优化：避免`LIMIT 100000,10`，改用`WHERE id > 100000 LIMIT 10` - 添加有效过滤条件：通过业务逻辑缩小查询范围 - 示例优化前： ```sql SELECT * FROM logs WHERE DATE_FORMAT(create_time,'%Y-%m')='2023-07' ``` 优化后： ```sql SELECT * FROM logs WHERE create_time >= '2023-07-01' AND create_time < '2023-08-01' ``` 2. **重构复杂查询** - 将多层嵌套子查询改为JOIN操作 - 拆分大事务为小事务，减少锁竞争 - 示例优化前： ```sql SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000) ``` 优化后： ```sql SELECT u.* FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.amount > 1000 ``` #### 三、数据库结构优化（长期性改进） 1. **分区表与分表策略** - 按时间范围分区：对日志类表使用`PARTITION BY RANGE` - 垂直分表：将大字段（如TEXT类型）拆分到独立表 - 水平分表：按业务维度（如地区、用户ID哈希）拆分 2. **数据类型优化** - 用TINYINT代替ENUM类型 - 使用DATETIME而非VARCHAR存储时间 - 示例优化：将`mobile_number VARCHAR(15)`改为`BIGINT`存储数值型手机号[^3] #### 四、执行分析与工具使用 1. **使用EXPLAIN分析执行计划** - 重点关注`type`列（应出现ref/range/index）和`Extra`列（避免Using filesort/Using temporary） 2. **启用慢查询日志** ```sql SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; -- 设置慢查询阈值（秒） ``` 3. **使用性能分析工具** - Percona Toolkit的`pt-query-digest`分析慢日志 - MySQL Workbench可视化执行计划 #### 五、其他关键优化点 1. **控制事务粒度** ```sql START TRANSACTION; -- 批量操作（建议每次处理1000-5000条） COMMIT; ``` 2. **批量操作优化** ```sql INSERT INTO table VALUES (1),(2),(3); -- 优于多次单条插入 ``` 3. **连接池配置** - 设置合理的最大连接数（避免连接风暴） - 使用连接复用机制 #### 典型优化案例 某订单查询优化前耗时12秒： ```sql SELECT * FROM orders WHERE status = 1 AND product_id IN (SELECT id FROM products WHERE category = 'electronics') ORDER BY create_time DESC LIMIT 1000; ``` 优化步骤： 1. 为`orders.status`和`products.category`添加索引 2. 改写为JOIN查询： ```sql SELECT o.* FROM orders o INNER JOIN products p ON o.product_id = p.id WHERE o.status = 1 AND p.category = 'electronics' ORDER BY o.create_time DESC LIMIT 1000; ``` 3. 添加联合索引`(status, product_id)` 优化后执行时间降至0.3秒[^2]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值