sql查询慢

sql查询增加一个查询条件后速度变慢，怎么样优化？

优化这个 SQL 查询是一件大事。
2 02 2 年，你遇到一个城市数据太多，查询崩溃。
我当时很困惑，不知道该怎么办。
后来慢慢摸索，发现了很多非常有用的方法。

首先，减少子查询的使用。
这东西听起来很方便，但实际上很慢。
当时我发现将所有子查询合并到主查询中会快得多。
例如，将原来的两个子查询，一个查询用户，一个查询命令，合并起来直接完成为一个查询。

接下来用case case来代替复杂的逻辑判断。
这个方法不错。
它可以避免数据库多次运行该表。
后来我发现统计功能也可以这样用。

然后是改进查询结构。
我当时就想了想，是不是查询逻辑本身有问题。
后来我又使用了联合查询和连接查询，效果明显好很多。

索引优化也很关键。
当时我发现，如果将查询词中常用的列，比如用户ID、订单号等建立索引，查询速度会更快。
如果情况下有多个列，我也会考虑创建复合索引。

分析实施计划的步骤也很重要，我是后来才意识到的。
使用数据库附带的工具来查看瓶颈所在并相应地调整索引。

优化查询条件时，应注意这一点，例如避免使用函数、以通配符开头的LIKE查询、IN语句等。
使用它们时应该小心，否则性能可能会显着下降。

最后，还必须考虑数据库配置和硬件资源。
当时我发现，适当调整内存分配和缓存大小，升级CPU、内存等硬件，可以有效提升性能。

总之，SQL查询优化要综合考虑、分步骤进行。
并非所有方法都适用，应根据具体情况而定。
我当时也在探索和优化，逐步提高了查询效率。

sql查询慢为什么cpu高

说白了，SQL慢导致CPU慢主要是因为查询太复杂、数据量超表、索引乱了、执行计划off了。

首先，我们来谈谈最重要的搜索词。
去年，我们开展了电子商务推广项目。
JOIN 8 个表的查询将 8 核 CPU 使用率提高到 9 5 %。
用技术术语来说，这称为雪崩效应。
事实上，前面有些耽误了，一切都戛然而止了。
当时发现统计函数有嵌套子查询，立刻改写成临时表连接，速度快了3 倍。
还有一点就是数据量太饱和了。
我有一些当时没有分离到数据库中的旧表。
3 000万笔订单通过用户ID确认。
全表扫描的CPU性能迅速提升至1 2 0%。
票数分配后，立即跌破1 0%。
还有另一个重要的细节。
索引越多越好。
例如，这里有一个项目，使用覆盖索引将复杂查询的速度提高了 6 0%。
但增加更多索引会影响更新效率，因此必须动态监控和调整执行计划。

一开始我以为优化就是改SQL，后来发现不对劲。
调整缓存参数和升级内存模块也有效。
等等，还有一件事。
某些数据库默认的统计更新周期太长。
例如，Oracle 每半年才重新计算一次表统计信息。
此时，执行计划可能完全陌生，必须手动收集。

下次当你看到你的CPU飙升时，最好先抓住最近减慢的SQL并查看它的执行计划。
不要只关注 SQL 本身。
当然，临时表滥用其实是一个常见的雷区，很多人都没有关注。