有个过程跑的很慢，最后发现索引造成的，只好删了它，不过觉得还没找出真正原因来...

最新推荐文章于 2025-11-02 17:27:20 发布
最新推荐文章于 2025-11-02 17:27:20 发布 · 98 阅读 · 0

本文介绍了一个具体的SQL查询优化案例，展示了如何通过改进SQL语句来提高数据库查询效率。特别是针对复杂的联表查询进行了详细的分析，并提供了优化后的执行计划。

过程中 这类语句造成的

SELECT ×
From
(
SELECT DISTINCT f_username --取前8-15天充值用户
FROM t_base_user_fill_burse
WHERE f_date >= to_date('2009-10-19', 'YYYY-MM-DD') - 15
AND f_date < to_date('2009-10-19', 'YYYY-MM-DD') - 7
)
INNER JOIN
(
SELECT * --取本周充值信息
FROM t_base_user_fill_burse
WHERE f_date >= to_date('2009-10-12', 'YYYY-MM-DD')
AND f_date < to_date('2009-10-19', 'YYYY-MM-DD')
) Using (f_username)

主要等待事件

执行计划：

iteye_3691
关注
mysql性能优化-慢查询分析、优化索引和配置.doc
11-22
- 慢查询日志：记录执行时间超过预设阈值的查询，通过分析这些日志可以找出拖慢系统性能的查询。 - `EXPLAIN`分析：解析SQL语句，提供关于查询如何使用索引的信息，有助于理解查询执行计划并优化查询。 - `...
运行procedure很慢但运行procedure内容很快.docx
09-27
本文档“运行procedure很慢但运行procedure内容很快.docx”所描述的情况就是一个典型的数据库性能问题，涉及到SQL Server 2021和SSRS 2021（SQL Server Reporting Services）的应用。这个问题的核心在于一个报表在...
有个过程跑的很慢，最后发现索引造成的，只好删了它，不过觉得还没找出真正原因来
海鲨数据库架构师
10-19 1098
过程中 这类语句造成的SELECT ×From (   SELECT DISTINCT f_username --取前8-15天充值用户   FROM t_base_user_fill_burse   WHERE f_date >= to_date(2009-10-19, YYYY-MM-DD) - 15     AND f_date )INNER JOIN (    SELECT * -
一个过程跑的异常慢而无结果却没有找到原因所在
cuiji1279的博客
12-24 100
一个过程跑的异常慢而无结果却没有找到原因所在一个过程跑的异常慢而无结果却没有找到原因所在昨天有个过程从凌晨0点跑到下午5:30 都没有跑完. 它是个移数据的过程.每一万条移一次.它运行过程中只移动了一次 数据量为5337条.后来...
xunsearch与mysql区别_xunsearch由mysql导入数据慢问题
weixin_34298263的博客
01-28 187
经过测试800万数据，越是执行到后面，查询速度越慢，执行了一晚上天才构造完成，通过后台查询得知，mysql查询数据，当OFFSET 很大的时候，查询数据会非常慢，每次查询会消耗大量的IO，数据库会根据索引，依次排除前面的2000000条数据，最后得到1000条。例如：select id,title,content from article limit 1000 offset 2000000 返回数...
MySQL慢查询优化之索引优化（一）
光与热的博客
08-13 448
示例： 从400万条员工表中对比索引查询和费索引的where查询有索引查询： EXPLAIN select * from emp WHERE deptno=28;EXPLAIN结果显示MySQL预估需要访问7840条数据 在使用索引的情况下，多次执行此语句平均消耗时间约为0.02sdeptno上的索引对比一下ALTER TABLE emp drop INDEX index_deptno; EXP
一个insert插入语句很慢的优化
热门推荐
sysmedia的博客
02-09 1万+
一个insert插入语句很慢的优化 原sql语句： INSERTINTO RISKREPT.BASE_FMLG (BATCH_DATE,DATE_STAMP_ST,TIME_STAMP_ST,ORG,ACCT,CARD_NBR,CARD_SEQ,MER_ORG,MER_NBR,REQUEST_TYPE_ID,LOGO,SYSTEM_ACTION,FINAL_ACTION,ACTION_RE
SQL（及存储过程）跑得太慢怎么办？
默默不代表沉默
09-06 2961
SPL，新的SQL处理玩法！
MySQL索引原理及慢查询优化
12-14
例如，如果一个索引被频繁地用于查询，但很少用于更新，那么这个索引是高效的。反之，如果索引在更新操作中造成大量额外开销，可能需要重新考虑其必要性。此外，过多的索引会占用更多的存储空间，并可能导致插入和...
吃透联合索引 B + 树查询：从底层逻辑到实战优化，再也不怕慢查询
最新发布
果酱 の 博客
11-02 1018
本文深入解析MySQL联合索引的B+树底层原理及优化实践。首先介绍了B+树作为索引结构的优势，包括查询效率稳定、支持范围查询和磁盘IO友好。重点阐述了联合索引的构建规则，通过多场景实例演示B+树的查询导航过程，包括完全匹配、最左前缀匹配、范围查询等情况，并分析了索引失效原因。文章提供了联合索引设计原则和Java实战代码，强调高频查询字段置前、避免冗余索引等优化要点，同时给出索引问题排查方案。
前缀索引，一种优化索引大小的解决方案
weixin_34112181的博客
03-03 160
今天在读一篇关于数据库索引介绍的文章时，该文章提到了前缀索引，对于我这个搞数据库应用开发那么多年的人来说，这个词还真是一个新词，没用过。于是打算研究一番。 前缀索引似乎是MySQL中的一个概念，在SQL Server和Oracle中没提出这个概念。于是就安装了一个MySQL来做实验，搞清楚前缀索引。 前缀索引说白了就是对文本的前几个字符（具体是几个字符在建立索引时指定）建立索引，这样建立起来的...
优化慢执行或慢查询的方法
马金波
06-22 4055
1、查询如果慢的建立索引可以提升速度相当于就是之前一个表数据量比较小，之后数据量大了查询就变慢，此时在经常用到的字段上加个索引，效率会翻倍很多的2、建立索引是为了提升速度，所以避免对索引字段进行计算或类型转化例如： where a * 5 = 10 可以 转化为 where a = 10/5 这样既可以保证业务逻辑也可以继续使用原索引去操作，所以要避免对索引字段进行计算或类型转化3、表的设计尤为重
xunsearch由mysql导入数据慢问题
weixin_30600503的博客
01-04 463
经过测试800万数据，越是执行到后面，查询速度越慢，执行了一晚上天才构造完成，通过后台查询得知， mysql查询数据，当OFFSET 很大的时候，查询数据会非常慢，每次查询会消耗大量的IO，数据库会根据索引，依次排除前面的2000000条数据，最后得到1000条。 例如：select id,title,content from article limit 1000 offset 2000000...
一个类，在任何时候都可以向它查询“你已经创建了多少个对象！
weixin_30758821的博客
10-21 121
import java.util.Scanner; public class Number { private static int i = 0; public Number() { i++; } public static int getNumber() { return i; } public static void main(String[] args) { Number...
xunsearch创建索引时越来越慢解决办法
nydxsy的博客
08-29 1287
为什么会为什么会越来越慢？        因为创建索引时用limit分段加载创建，limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。当数据越来越大时，速度越来越慢。         新问题：当数据量太大时，后面数据不会创建索引，猜测是数据加入太快的原因，所以加入一个间隔时间，代码加在下面了 废话不多说直接上解决办法: 修改...
网易研发工程师编程题——小易的升级之路
九月鹰飞
08-12 701
小易经常沉迷于网络游戏，有一次，他在玩一个打怪升级的游戏，他的角色的初始能力值为a。在接下来的一段时间内，他将会依次遇见n个怪物，每个怪物的防御力为b1,b2,b3...bn.如果遇到的怪物防御力bi小于等于小易的当前能力值c,那么他就能轻松打败怪物，并且使得自己的能力值增加bi；如果bi大于c，那么他也能打败怪物，但他的能力值只能增加bi与c最大公约数，那么问题来了，在一系列的锻炼后，小易的最终
有个查询很慢，如何定位到造成缓慢的具体位置
05-05
<think>嗯，用户问的是如何定位和优化导致查询缓慢的具体位置，主要是针对SQL或数据库性能调优。首先，我得回忆一下之前提供的引用内容，看看有没有相关的步骤和方法。记得引用[1]提到启用慢查询日志是定位慢SQL的第一步，然后分析执行计划。引用[3]也提到了优化器处理执行计划的过程。用户可能需要详细的步骤，所以得一步步来。 首先，定位慢SQL的方法。用户可能需要知道如何开启慢查询日志，比如在MySQL里设置参数，像slow_query_log和long_query_time这些。然后，需要分析日志，找出执行时间长的查询。这里可以推荐工具，比如mysqldumpslow或者Percona Toolkit，这些工具能帮助分析日志中的慢查询。 接下来，分析执行计划是关键。EXPLAIN命令是必须提到的，用户需要了解每个字段的含义，比如type列的值是否全表扫描（ALL），或者有没有用到索引。引用[2]里提到索引优化是重要的一环，所以这里需要详细说明如何通过执行计划判断索引使用情况。 然后，优化阶段需要考虑索引优化。比如，检查WHERE子句和JOIN条件是否有合适的索引，避免在索引列上使用函数或运算，这些会导致索引失效。还有覆盖索引的概念，可以减少回表操作，提升性能。这部分需要结合引用[2]和[3]的内容。 SQL重写方面，用户可能需要知道如何避免SELECT *，使用JOIN代替子查询，分页优化等技巧。比如大分页时的延迟关联，减少数据扫描量。此外，临时表和文件排序的情况也要注意，这可能会出现在GROUP BY和ORDER BY子句中，需要优化索引来避免。 数据库参数调优也不能少，比如调整缓冲池大小、日志写入策略等。引用[4]提到内存占用的问题，如果缓存区太小，可能导致频繁IO，这时候需要调整innodb_buffer_pool_size。这部分需要根据具体的数据库系统来调整参数。 高级工具方面，性能分析工具如SHOW PROFILE和SHOW STATUS可以帮助深入分析查询的每个阶段耗时。监控工具如Grafana可以实时观察数据库状态，引用[4]里提到的Memory Over图表就是例子，用户可能需要结合监控来定位问题。 最后，架构优化，比如读写分离、分库分表，这些属于更高层次的优化，当单机性能不足时考虑。不过用户的问题主要是定位和优化具体查询，所以这部分可能作为补充。 用户可能还关心如何验证优化是否有效，所以需要提到逐步验证和A/B测试的方法。同时，注意避免常见误区，比如过多索引影响写性能，或者过度依赖工具而不理解执行计划。 总结一下，回答的结构应该是先定位后优化，每个步骤给出具体的方法和工具，并结合引用中的内容，比如启用慢查询日志来自引用[1]，索引优化来自引用[2]，执行计划分析来自引用[3]等。确保逻辑清晰，用户能一步步跟着操作。</think>### 如何定位和优化导致查询缓慢的具体位置 #### 一、定位慢查询的核心步骤 1. **启用慢查询日志** 在MySQL中通过配置参数开启慢查询日志，记录执行时间超过阈值的SQL语句： ```sql SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2; -- 单位：秒 ``` 日志文件路径可通过`SHOW VARIABLES LIKE 'slow_query_log_file'`查询[^1]。 2. **分析日志工具** - 使用`mysqldumpslow`工具统计高频慢SQL： ```bash mysqldumpslow -s t /var/lib/mysql/slow.log ``` - 使用Percona Toolkit的`pt-query-digest`进行深度分析[^2]。 3. **执行计划分析（EXPLAIN）** 在SQL语句前添加`EXPLAIN`关键字，查看执行计划中的关键字段： - `type`：查询类型（如`ALL`表示全表扫描，需优化） - `key`：实际使用的索引 - `rows`：预估扫描行数 - `Extra`：额外信息（如`Using filesort`表示未利用索引排序）[^3]。 --- #### 二、优化慢查询的关键方法 1. **索引优化** - **缺失索引定位**：通过`EXPLAIN`发现全表扫描后，对`WHERE`、`JOIN`条件字段添加复合索引。 - **避免索引失效**： - 禁止对索引列使用函数（如`WHERE YEAR(create_time)=2023`） - 避免隐式类型转换（如字符串字段用数字查询） - **覆盖索引**：通过索引直接返回数据，减少回表操作。例如： ```sql -- 原始查询 SELECT id, name FROM users WHERE age > 25; -- 优化索引 CREATE INDEX idx_age_name ON users(age, name); ``` 2. **SQL重写技巧** - **减少数据量**： - 避免`SELECT *`，明确指定字段 - 分页优化：对大偏移量分页使用延迟关联 ```sql SELECT * FROM users JOIN (SELECT id FROM users LIMIT 1000000,10) AS tmp USING(id) ``` - **简化复杂查询**： - 用`JOIN`替代嵌套子查询 - 拆分大事务为小批次操作 3. **数据库参数调优** - **缓冲池配置**： ```sql SET GLOBAL innodb_buffer_pool_size = 8G; -- 通常设为物理内存的70% ``` - **日志写入策略**： ```sql SET GLOBAL innodb_flush_log_at_trx_commit = 2; -- 非严格ACID场景提升写入性能 ``` --- #### 三、高级工具与验证 1. **性能分析工具** - `SHOW PROFILE`：查看SQL各阶段耗时 ```sql SET profiling = 1; SELECT * FROM orders WHERE amount > 1000; SHOW PROFILES; SHOW PROFILE FOR QUERY 1; ``` - `SHOW STATUS`：监控关键指标（如`Handler_read_next`索引效率） 2. **逐步验证法** 每次仅修改一个变量（如索引或SQL结构），通过`EXPLAIN`和实际执行时间对比验证效果。 --- #### 四、常见误区与注意事项 1. **索引过多问题**：索引会降低写性能，单表建议不超过5个 2. **统计信息不准确**：定期执行`ANALYZE TABLE`更新统计信息 3. **硬件瓶颈判断**：通过`iostat`观察磁盘IO，或`vmstat`分析CPU/内存压力[^4] --- ### 相关问题 1. 如何通过执行计划判断索引是否生效？ 2. 数据库缓冲池大小设置不当会引发哪些问题？ 3. 分页查询性能差时有哪些优化手段？ 4. 如何区分SQL性能问题是索引缺失还是参数配置导致？ --- ### 引用说明 [^1]: 通过慢查询日志定位高频低效SQL，需结合日志分析工具快速提取关键信息。 [^2]: 索引设计需遵循最左前缀原则，复合索引字段顺序影响查询效率。 [^3]: 执行计划中的`Using temporary`表示需要创建临时表，常见于未优化的`GROUP BY`操作。 [^4]: 内存不足时可能出现频繁的磁盘交换，可通过监控工具实时观察资源使用趋势。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值