SQL进阶——SQL性能优化

原创 于 2026-07-07 00:13:06 发布 · 11 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
SQL经典实例

当前文章被收录于：

SQL经典实例
26 篇文章 0 人学习

SQL基础

订阅专栏 查看详情

SQL性能优化

1、参数是子查询时，使用EXISTS代替IN

IN谓词非常方便，而且代码也容易理解，所以使用的频率很高。但是方便的同时，IN谓词却有成为性能优化的瓶颈的危险。一般来说，如果代码中大量用到了IN谓词，那么我们只要对它们进行优化，就能大幅度地提升性能。

如果IN的参数是“1, 2, 3”这样的数值列表，一般还不需要特别注意。但是如果参数是子查询，那么就需要注意了。

在大多时候，​[NOT] IN和 [NOT] EXISTS返回的结果是相同的。但是当它们用于子查询时，EXISTS的速度会更快一些。

我们先看一个例子。这里使用前面用过的两张用于管理班级和学生的表作为测试数据。

在这里插入图片描述

我们试着从表Class_A中查出同时存在于表Class_B中的员工。下面两条SQL语句返回的结果是一样的，但是使用EXISTS的SQL语句更快一些。

-- 慢
SELECT *
FROM Class_A
WHERE id IN (SELECT id FROM Class_B);

+----+------+
| id | name |
+----+------+
| 1  | 田中 |
| 2  | 铃木 |
+----+------+

-- 快
SELECT *
FROM Class_A A
WHERE EXISTS (
	SELECT *
	FROM Class_B B
	WHERE A.id = B.id
);

+----+------+
| id | name |
+----+------+
| 1  | 田中 |
| 2  | 铃木 |
+----+------+

使用EXISTS时更快的原因有以下两个。

  1. 如果连接列(id)上建立了索引，那么查询Class_B时不用查实际的表，只需查索引就可以了。
  2. 如果使用EXISTS，那么只要查到一行数据满足条件就会终止查询，不用像使用IN时一样扫描全表。在这一点上，NOT EXISTS也一样。

当IN的参数是子查询时，数据库首先会执行子查询，然后将结果存储在一张临时的工作表里（内联视图）​，接着再扫描整个视图。在很多情况下，这种做法非常耗费资源，而且工作表中通常没有索引。使用EXISTS的话，数据库不会生成临时的工作表。

但是从代码的可读性上来看，IN要比EXISTS好。使用IN时的代码看起来更加一目了然，易于理解。因此，如果确信使用IN也能快速获取结果，就没有必要非得改成EXISTS了。

而且，最近有很多DBMS也尝试着改善了IN的性能。例如，在Oracle数据库中，如果我们使用了建有索引的列，那么即使使用IN，也会先扫描索引。此外，PostgreSQL从版本7.4起也改善了使用子查询作为IN谓词参数时的查询速度。因此，也许在未来的某一天，使用IN谓词将不再被看作一种性能方面的反模式。

2、参数是子查询时，使用连接代替IN

要想改善IN的性能，除了使用EXISTS，还可以使用连接。前面的查询语句就可以像下面这样“扁平化”​。

-- 使用连接代替 IN
SELECT A.id, A.name
FROM Class_A A INNER JOIN Class_B B
ON A.id = B.id;

+----+------+
| id | name |
+----+------+
| 1  | 田中 |
| 2  | 铃木 |
+----+------+

这种写法至少能用到一张表的id列上的索引。而且，因为没有了子查询，所以数据库也不会生成中间表。我们很难说这和写法与EXISTS相比哪个更好，但是如果没有索引，那么与连接相比，可能EXISTS会略胜一筹。

3、避免排序

与面向过程语言不同，在SQL语言中，用户不能显式地命令DBSM进行排序操作。对用户隐藏这样的操作正是SQL的设计思想。

但是，这样并不意味着在DBSM内部也不能进行排序。其实正好相反，DBSM的内部会频繁地在暗中进行排序。因此最终对于用户来说，了解都有哪些运算会进行排序很有必要（从这个意义上讲，​“隐藏操作”这个目标的实现似乎还任重道远）​。

会进行排序的具有代表性的运算有下面这些。

  • GROUP BY子句
  • ORDER BY子句
  • 聚合函数(SUM、COUNT、AVG、MAX、MIN)
  • DISTINCT
  • 集合运算符(UNION、INTERSECT、EXCEPT)
  • 窗口函数（RANK、ROW_NUMBER等）

排序如果只在内存中进行，那么还好；但是如果因内存不足而需要在硬盘上排序，那么排序的性能也会急剧恶化。

因此，我们的目标是尽量避免无谓的排序。

4、灵活使用集合运算符的ALL可选项

SQL中有UNION、INTERSECT、EXCEPT三个集合运算符。在默认的使用方式下，这些运算符会为了排除掉重复数据而进行排序。

SELECT * FROM Class_A
UNION
SELECT * FROM Class_B;

+----+--------+
| id | name   |
+----+--------+
| 1  | 田中   |
| 2  | 铃木   |
| 3  | 伊集院 |
| 4  | 西园寺 |
+----+--------+

如果不在乎结果中是否有重复数据，或者事先知道不会有重复数据，那么请使用UNION ALL来代替UNION。这样就不会进行排序了。

SELECT * FROM Class_A
UNION ALL
SELECT * FROM Class_B;

+----+--------+
| id | name   |
+----+--------+
| 1  | 田中   |
| 2  | 铃木   |
| 3  | 伊集院 |
| 1  | 田中   |
| 2  | 铃木   |
| 4  | 西园寺 |
+----+--------+

对于INTERSECT和EXCEPT也是一样的，加上ALL可选项后就不会进行排序了。加上ALL可选项是优化性能的一个非常有效的手段，但问题是各种DBMS对它的实现情况参差不齐，对此我们需要多加注意。人们很容易想当然地以为所有的数据库都支持ALL可选项，但事实并非如此，请大家记住这一点。

5、使用EXISTS代替DISTINCT

为了排除重复数据，DISTINCT也会进行排序。如果需要对两张表的连接结果进行去重，可以考虑使用EXISTS代替DISTINCT，以避免排序。

在这里插入图片描述
我们来思考一下如何从上面的商品表Items中找出同时存在于销售记录表SalesHistory中的商品。简而言之，就是找出有销售记录的商品。

使用IN是一种做法，但是前面我们说过，当IN的参数是子查询时，使用连接要比使用IN更好。因此，我们像下面这样使用item_no列对两张表进行连接。

SELECT I.item_no
FROM Items I INNER JOIN SalesHistory SH
ON I. item_no = SH. item_no;

+---------+
| item_no |
+---------+
|      10 |
|      20 |
|      30 |
|      10 |
|      30 |
|      20 |
|      30 |
+---------+

因为是一对多的连接，所以item_no列中会出现重复数据。为了排除重复数据，我们需要使用DISTINCT。

SELECT DISTINCT I.item_no
FROM Items I INNER JOIN SalesHistory SH
ON I. item_no = SH. item_no;

+---------+
| item_no |
+---------+
|      10 |
|      20 |
|      30 |
+---------+

但是，其实更好的做法是使用EXISTS。

SELECT item_no
FROM Items I
WHERE EXISTS (
	SELECT *
	FROM SalesHistory SH
	WHERE I.item_no = SH.item_no
);

+---------+
| item_no |
+---------+
|      10 |
|      20 |
|      30 |
+---------+

这条语句在执行过程中不会进行排序。而且，使用EXISTS和使用连接一样高效。

6、在极值函数中使用索引(MAX/MIN)

SQL语言里有MAX和MIN两个极值函数，使用这两个函数时都会进行排序。但是如果参数字段上建有索引，则只需要扫描索引，不需要扫描整张表。以刚才的表Items为例来说，SQL语句可以像下面这样写。

-- 这样写需要扫描全表
SELECT MAX(item)
FROM Items;

-- 这样写能用到索引
SELECT MAX(item_no)
FROM Items;

因为item_no是表Items的唯一索引，所以效果更好。对于联合索引，只要查询条件是联合索引的第一个字段，索引就是有效的，所以也可以对表SalesHistory的sale_date字段使用极值函数。这种方法并不是去掉了排序这一过程，而是优化了排序前的查找速度，从而减弱排序对整体性能的影响。

7、能写在WHERE子句里的条件不要写在HAVING子句里

例如，下面两条SQL语句返回的结果是一样的。

-- 聚合后使用 HAVING 子句过滤
SELECT sale_date, SUM(quantity)
FROM SalesHistory
GROUP BY sale_date
HAVING sale_date = '2018-10-01';


-- 聚合前使用 WHERE 子句过滤
SELECT sale_date, SUM(quantity)
FROM SalesHistory
WHERE sale_date = '2018-10-01'
GROUP BY sale_date;

+------------+---------------+
| sale_date  | SUM(quantity) |
+------------+---------------+
| 2018-10-01 |            17 |
+------------+---------------+

但是从性能上来看，第二条语句写法效率更高。原因有两个：

  • 其一，在使用GROUP BY子句聚合时会进行排序或散列运算，如果事先通过WHERE子句筛选出一部分行，就能够减轻排序的负担；
  • 其二，在WHERE子句的条件里可以使用索引，sale_date可以说是非常重要的列，如果该列有索引，那么筛选的效率也会非常高。

HAVING子句是针对聚合后生成的视图进行筛选的，但是很多时候，聚合后的视图并没有继承原表的索引结构。

8、在GROUP BY子句和ORDER BY子句中使用索引

一般来说，GROUP BY子句和ORDER BY子句都会进行排序，以对行进行排列和替换。不过，通过指定带索引的列作为GROUP BY和ORDER BY的列，可以实现高速查询。特别是在一些数据库中，如果操作对象的列上建立的是唯一索引，那么排序过程本身就会被省略掉。如果大家有兴趣，可以确认一下自己使用的数据库是否支持这个功能。

9、真的用到索引了吗

一般情况下，我们会对数据量相对较大的表建立索引。简单地说，索引的工作原理与C语言中的指针数组是一样的，即相比查找复杂对象的数组，查找轻量的指针会更高效（我们可以想象一下最常见的图书目录）​。而且，最流行的B树索引还进行了一些优化，以使用二分查找来提升查询的速度。

一般情况下，我们会对数据量相对较大的表建立索引。简单地说，索引的工作原理与C语言中的指针数组是一样的，即相比查找复杂对象的数组，查找轻量的指针会更高效（我们可以想象一下最常见的图书目录）​。而且，最流行的B树索引还进行了一些优化，以使用二分查找来提升查询的速度。

10、在索引字段上进行运算

SELECT * 
FROM SomeTable 
WHERE col_1 * 1.1 > 100;

人们普遍认为，SQL语言的主要目的不是进行运算，但实际上，数据库引擎大多连这种程度的转换也不会为我们做。

把运算的表达式放到查询条件的右侧，就能用到索引了，也就是说像下面这样写就好了。

WHERE col_1 > 100 / 1.1

同样，在查询条件的左侧使用函数时，也不会用到索引。

SELECT * 
FROM SomeTable 
WHERE SUBSTR(col_1, 1, 1)= 'a';

如果无法避免在左侧进行运算，那么使用函数索引也是一种办法，但操作起来很麻烦，所以不太推荐大家随意使用。

使用索引时，列应该是原始字段。

11、索引字段中存在NULL

索引中的NULL不好处理，对此的实现也各不相同。这是因为如果使用IS NULL和IS NOT NULL，索引就无法使用了，而且NULL很多的字段也无法使用索引。

SELECT * 
FROM SomeTable 
WHERE col_1 IS NULL;

索引字段中的NULL之所以会成为一个难题，是因为从原则上来说NULL并不是字段的正常值（请参考1-4节）​。因此，如何处理NULL并没有一个统一的标准，这导致情况变得很复杂。

然而，如果需要使用类似IS NOT NULL的功能，又想用到索引，那么可以使用下面的方法。这里假设col_1列的最小值是1。

--IS NOT NULL 的代替方案
SELECT * FROM  SomeTable WHERE  col_1 > 0;

原理很简单，只要使用不等号并指定一个比最小值还小的数，就可以选出col_1中所有的值。因为col_1 > NULL的执行结果是 unknown，所以当col_1列的值为NULL的行不会被选择。不过，如果要选择“非NULL的行”​，正确的做法还是使用IS NOT NULL。上面这种写法在含义上有些容易混淆，所以笔者也不太推荐，请大家只在应急的情况下使用。

12、使用否定形式

下面这几种否定形式不能用到索引。

  • <>
  • !=
  • NOT IN

因此，下面的SQL语句也不会用到索引。

SELECT * 
FROM SomeTable 
WHERE col_1 <> 100;

使用OR

在col_1和col_2上分别建立了不同的索引，或者建立了(col_1, col_2)这样的联合索引时，如果使用OR连接条件，那么要么不会用到索引，要么用到了，但是效率比AND要差很多。

SELECT * 
FROM SomeTable 
WHERE col_1 > 100 OR col_2 = 'abc';

如果无论如何都要使用OR，那么有一个办法是使用位图索引。但是如果使用这种索引，更新数据时的性能开销会增大，而且索引本身的用途也存在限制（通常用于在线更新处理较少的BI/DWH系统）​。

13、使用联合索引时，列的顺序错误

假设存在一个顺序是“col_1, col_2, col_3”的联合索引。这时，指定条件的顺序就很重要。

〇   SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 AND col_3 = 500;
〇   SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 ;
×   SELECT * FROM SomeTable WHERE col_1 = 10 AND col_3 = 500 ;
×   SELECT * FROM SomeTable WHERE col_2 = 100 AND col_3 = 500 ;

联合索引中的第一列(col_1)必须写在查询条件的开头，而且索引中列的顺序不能颠倒。有些数据库里顺序颠倒后也能使用索引，但是性能还是比顺序正确时差一些。如果无法保证查询条件里列的顺序与索引一致，可以考虑将联合索引拆分为多个索引。

14、使用LIKE谓词进行后方一致或中间一致的匹配

使用LIKE谓词时，只有前方一致的匹配才能用到索引。

×   SELECT * FROM SomeTable WHERE col_1 LIKE '%a';
×   SELECT * FROM SomeTable WHERE col_1 LIKE '%a%';
〇   SELECT * FROM SomeTable WHERE col_1 LIKE 'a%';

15、进行默认的类型转换

下面是对字符串类型的col_1列指定条件的示例。

×   SELECT * FROM SomeTable WHERE col_1 = 10;
〇   SELECT * FROM SomeTable WHERE col_1 = '10';
〇   SELECT * FROM SomeTable WHERE col_1 = CAST(10, AS CHAR(2));

默认的类型转换不仅会增加额外的性能开销，还会导致索引不可用，可以说是有百害而无一利。虽然这样写还不至于出错，但还是不要嫌麻烦，在需要类型转换时显式地进行类型转换吧（别忘了转换要写在值的一边，而不是列的一边）​。在有些DBMS（如PostgreSQL）中，数据类型写在表达式的不同侧就会发生错误，显式地进行类型转换还有利于我们在开发时注意避免编写性能低下的查询。

16、减少中间表

在SQL中，子查询的结果会被看成一张新表。这张新表与原始表一样，可以通过代码进行操作。这种高度的相似性使得SQL编程具有非常强的灵活性，但是如果不加限制地大量使用中间表，也会导致查询性能的下降。

频繁地使用中间表会带来两个问题：一是展开数据需要耗费内存（或存储器）资源，二是原始表中的索引不容易被用到（特别是聚合时）​。因此，尽量减少中间表的使用也是一个提升性能的重要方法。

17、灵活使用HAVING子句

对聚合结果指定筛选条件时，使用HAVING子句是基本原则。不习惯使用HAVING子句的数据库工程师可能会倾向于像下面这样先生成一张中间表，然后在WHERE子句中指定筛选条件。

在这里插入图片描述

sale_date      tot_qty
------------   ---------
18-10-01            10
18-10-03            32
18-10-04            22

然而，对聚合结果指定筛选条件时不需要专门生成中间表，像下页这样使用HAVING子句就可以了。

SELECT sale_date, MAX(quantity)
FROM SalesHistory
GROUP BY sale_date
HAVING MAX(quantity)>= 10;

HAVING子句和聚合操作是同时执行的，所以比起先生成中间表，然后再执行的WHERE子句，效率会更高一些，而且代码看起来也更简洁。

18、需要对多个字段使用IN谓词时，先将它们汇总到一处

SQL-92中加入了行与行比较的功能。这样一来，比较谓词=、<、>和IN谓词的参数就不能是标量值，而应是值列表了。

我们来看看下面这道例题。这里对多个字段使用了IN谓词，id列是主键。

SELECT id, state, city
FROM Addresses1 A1
WHERE state IN (
	SELECT state
	FROM Addresses2 A2
	WHERE A1.id = A2.id
) AND city IN (
	SELECT city
	FROM Addresses2 A2
	WHERE A1.id = A2.id
);

这段代码中用到了两个子查询。但是，如果像下面这样把字段连接在一起，就能把逻辑写在一处了。

SELECT *
  FROM Addresses1 A1
 WHERE id || state || city IN (SELECT id || state|| city
                                 FROM Addresses2 A2);

这样一来，子查询就不用考虑关联性了，而且只执行一次就可以。此外，如果所用的数据库实现了行与行的比较，那么我们也可以像下面这样，在IN中写多个字段的组合。

SELECT *
  FROM Addresses1 A1
 WHERE (id, state, city)IN (SELECT id, state, city
                               FROM Addresses2 A2);

这种方法与前面连接字段的方法相比有两个优点：一是不用担心连接字段时出现的类型转换问题，二是这种方法不会对字段进行加工，因此可以使用索引。

19、先进行连接再进行聚合

连接和聚合同时使用时，先进行连接操作可以避免产生中间表。原因是，从集合运算的角度来看，连接做的是“乘法运算”​。连接表双方是一对一、一对多的关系时，连接运算后数据的行数不会增加。而且，因为在很多设计中多对多的关系可以分解成两个一对多的关系，所以这个技巧可以应用在大部分情况中。

20、合理地使用视图

视图是非常方便的工具，相信有很多人会在日常工作中频繁地使用它。但是，如果没有经过深入思考就定义复杂的视图，可能会带来巨大的性能问题。特别是当视图的定义语句中包含以下运算时，SQL会非常低效，执行速度也会变得非常慢。

  • 聚合函数(AVG、COUNT、SUM、MIN、MAX)
  • 集合运算符（UNION、INTERSECT、EXCEPT等）

一般来说，我们需要格外注意，避免在视图中进行聚合操作。最近，越来越多的数据库为了解决视图的这个缺点，实现了物化视图(materialized view)等技术。当视图的定义变得复杂时，大家可以考虑使用那些技术。

标签
#sql #性能优化 #oracle
SQL进阶之性能优化
m0_46132995的博客
10-23 341
SQL进阶之性能优化SQL性能优化越前须知（雾）概述==使用高效的查询====避免排序====使用索引====减少中间表== SQL性能优化 越前须知（雾） 本系列参考《SQL进阶教程》1，DBMS选用MySQL。 本系列不涉及数据库安装与基础语句，对初学者存在一定门槛；基础知识建议阅读《SQL必知必会（第四版）》与《SQL基础教程（第二版）》。 本篇主题为HAVING子句进阶用法，基础用法见同系列前文。 概述 使用高效的查询 避免排序 使用索引 减少中间表 使用高效的查询 参数是子查询时，用EX
mysql进阶之sql性能优化
qq_43049421的博客
12-27 269
1. 视图 创建 2. MYSQL优化 2.1 确定sql执行效率(查询看看是哪种操作比较慢) MySQL 客户端连接成功后，通过 show [session|global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次： # 查看全局数据 show Global status like'Com_____'; # 查看当前对话数据 show session status like 'Com_____';
SQL学习进阶指南：从书籍选择到实战性能优化
最新发布
weixin_30321709的博客
05-29 306
SQL（结构化查询语言）作为数据处理的核心，其学习路径从基础语法掌握到高级性能优化，贯穿数据应用的各个层面。理解SQL的声明式特性是关键，它要求用户描述所需结果而非具体步骤，这直接影响查询效率和执行计划。掌握索引原理、查询优化等技术，能显著提升大数据量下的处理性能，避免全表扫描等常见陷阱。在实际应用中，SQL与大数据平台（如Spark SQL）、流处理框架（如Flink SQL）结合，扩展了其处理海量数据和实时流的能力。通过结合高质量教材（如《SQL Practice Problems》）和刻意练习，可以构
SQL性能优化实战从慢查询到高效查询的进阶之路
alicemqy的博客
10-04 343
分析这些慢查询的执行计划（EXPLAIN）是关键，它能揭示查询是如何被执行的，包括索引使用情况、表连接方式和数据扫描范围等重要信息。定期分析索引使用情况，删除无用索引，维护索引统计信息，确保查询优化器能做出正确决策。了解不同类型的访问路径（如全表扫描、索引扫描、索引范围扫描）、连接算法（嵌套循环连接、哈希连接、合并连接）以及排序和分组操作的代价，能够帮助您精准定位性能瓶颈。本文将深入探讨SQL性能优化的实战路径，从识别慢查询开始，逐步介绍各种优化策略和技术，帮助您构建高效、稳定的数据库查询体系。
MySQL进阶知识：SQL性能优化
zmbwcx的博客
11-30 1426
首先，根据创建索引时指定的索引长度，截取条件中的的对应长度字符取索引中获取第一次出现该索引的id，然后区聚集索引中根据id获取到行信息，从行信息中获取对应字段信息与语句中的信息对比，如果相同，则返回该行信息。可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，索引选择性越高则查询效率越高，唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。比如说，name字段存在单列索引，也和age、sex存在联合索引，那么在只查询name字段时，可能会走联合索引。
MyBatis动态SQL进阶：复杂查询与性能优化实战
m0_58202543的博客
07-05 1755
通过灵活运用MyBatis的动态SQL特性，可显著提升复杂查询场景的开发效率和运行性能。实际开发中需根据数据量、查询复杂度、并发量等因素综合选择优化策略。
SQL 语句进阶实战：从基础查询到性能优化全指南
sengminPark的博客
08-19 1004
若一张表数据量小（如课程表，几十条数据），另一张表数据量大（如学生表，上万条数据），应将小表作为左表，减少外层循环次数。数据规模在变，业务需求在变，但对「简洁、高效、安全」的追求不变。实际业务中，数据往往分散在多张表中（如用户表、订单表、商品表），多表连接是获取关联数据的核心手段。除了基础查询，MySQL 的高级特性（索引、视图、存储过程）能大幅提升 SQL 的复用性和效率，是进阶必备技能。注意：视图本质是 “存储的查询语句”，对视图的更新需满足底层表的约束（如非空、主键），并非所有视图都支持。
in ms sql 集合参数传递_SQL 进阶技巧
weixin_42311349的博客
12-27 319
由于工作需要，最近做了很多 BI 取数的工作，需要用到一些比较高级的 SQL 技巧，总结了一下工作中用到的一些比较骚的进阶技巧，特此记录一下，以方便自己查阅，主要目录如下：SQL 的书写规范SQL 的一些进阶使用技巧SQL 的优化方法SQL 的书写规范在介绍一些技巧之前，有必要强调一下规范，这一点我发现工作中经常被人忽略，其实遵循好的规范可读性会好很多，应该遵循哪些规范呢1、 表名要有意义，且标准...
《sql进阶教程》之几个性能优化建议
uzong
12-08 724
本文是《sql进阶教程》阅读笔记，感兴趣可以阅读该书对应章节，这本适合有一定sql基础的同学阅读。另外作者《sql基础教程》也值得一看 严格地优化查询性能时，必须要了解所使用数据库的功能特点。此外，查询速度慢并不只是因为 SQL 语句本身，还可能是因为内存分配不佳、文件结构不合理等其他原因。因此本节即将介绍的优化SQL 的方法未必能解决所有的性能问题，但是确实很多时候查询性能不好的原因还是 SQ...
简单的SQL性能优化（SQL进阶教程摘录）
桃花庵下桃花仙
03-12 313
总结一下索引失效的情况。 1、条件表达式的左侧不是原始字段 mysql&amp;gt; explain select*from driver_log where substr(name,1,1)='b'; +----+-------------+------------+------------+------+---------------+------+---------+------+------+-...
PostgreSQL入门与进阶学习，体系化的SQL知识，完成终极目标高可用与容灾，性能优化与架构设计，以及安全策略
一个追逐梦想的码农
07-28 4745
对于后端开发者而言，对数据库的熟悉程度不仅是岗位需求的基础，更是职业发展中不可或缺的一环，其全面性对于技术定级具有显著的推动作用。在选择学习的数据库时，建议从广泛应用的postgresql入手，因其在互联网领域占据重要地位。接下来，让我们逐步深入，从基础到进阶，系统梳理数据库技术的关键点。
从日志切面到性能优化：JdbcTemplate SQL日志的进阶实践
rnn9storyteller的博客
02-03 973
本文深入探讨了JdbcTemplate SQL日志的进阶实践，从基础配置到性能调优，提供了一套完整的解决方案。通过AOP切面实现完整SQL日志记录，包括参数替换、执行时间监控等关键功能，并结合SpringBoot环境优化日志性能与安全。文章还分享了生产环境最佳实践、性能压测建议及工具链推荐，帮助开发者高效排查数据库问题。
sql 视图不排序_SQL进阶技巧
weixin_39843338的博客
11-26 407
来源：公众号【码海】链接：SQL 进阶技巧（上）由于工作需要，最近做了很多 BI 取数的工作，需要用到一些比较高级的 SQL 技巧，总结了一下工作中用到的一些比较骚的进阶技巧，特此记录一下，以方便自己查阅，主要目录如下：SQL 的书写规范SQL 的一些进阶使用技巧SQL 的优化方法SQL 的书写规范在介绍一些技巧之前，有必要强调一下规范，这一点我发现工作中经常被人忽略，其实遵循好的规范可读性会好很...
sql进阶教程
保持热爱，持续学习
02-01 4695
SQL进阶教程
SQL进阶技巧高效查询与性能优化实战指南
wangchong91591的博客
10-03 539
在SQL高效查询中，索引是提升性能的核心工具。对于子查询，考虑转化为JOIN操作，因为大多数数据库对JOIN有更好的优化。使用LIKE进行模糊查询时，前导通配符（如'%abc'）也会使索引失效，而后缀匹配（如'abc%'）仍可使用索引。对于分页查询，避免使用OFFSET处理深分页，而是采用WHERE id > last_id LIMIT n的方式，其中id是连续且唯一的标识符。应用程序中采用缓存策略减少数据库访问次数，批量操作替代频繁的单次请求，合理使用连接池管理数据库连接，都能从整体上提升系统性能。
SQL进阶指南高效查询与性能优化技巧
ibrahim9958的博客
10-03 330
通过分析执行计划，可以识别性能瓶颈，例如全表扫描、昂贵的连接操作或低效的索引使用。遵循规范化原则以减少数据冗余，但也要注意，有时为了查询性能，适度反规范化（如预计算和存储派生数据）是必要的。将复杂的子查询重写为JOIN操作，这通常更高效。使用EXISTS替代IN来处理子查询，尤其是在子查询返回大量数据时。B-tree索引适用于范围查询和排序，而哈希索引适合等值查询。窗口函数（如ROW_NUMBER, RANK, LAG）允许在结果集内执行计算，避免使用多个自连接或子查询，从而提高复杂报表查询的效率。
SQL技术进阶高效查询与性能优化实战指南
geyiguang的专栏
10-04 416
使用数据库内置的性能调优工具，如MySQL的Performance Schema、PostgreSQL的pg_stat_statements等。缓存策略也是提高性能的重要手段，合理使用应用层缓存和数据库查询缓存可以减少数据库压力。定期分析索引使用情况，删除无用索引，维护索引统计信息，确保查询优化器能够做出最佳决策。无论是处理大规模数据集还是支撑高并发的在线应用，SQL查询的性能都直接影响着系统的响应速度和用户体验。通过实践这些技术，您将能够构建更高效、更可靠的数据应用系统，为用户提供更优质的服务体验。
SQL进阶之旅 Day 23：事务隔离级别与性能优化
在未来等你的专栏
06-10 1135
事务是一组SQL语句的集合，这些语句要么全部执行成功，要么全部回滚。原子性（Atomicity）：事务中的所有操作要么全部完成，要么完全不执行。一致性（Consistency）：事务执行前后，数据库的状态保持一致。隔离性（Isolation）：多个事务并发执行时，彼此之间互不干扰。持久性（Durability）：事务提交后，结果将被永久保存。根据SQL标准，事务有四种隔离级别：| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
sql 忽略大小写_SQL 进阶技巧
weixin_39605894的博客
12-09 1700
点击上方“数据管道”，选择“置顶星标”公众号干货福利，第一时间送达来源于码海，作者码海由于工作需要，最近做了很多 BI 取数的工作，需要用到一些比较高级的 SQL 技巧，总结了一下工作中用到的一些比较骚的进阶技巧，特此记录一下，以方便自己查阅，主要目录如下：SQL 的书写规范SQL 的一些进阶使用技巧SQL 的优化方法SQL 的书写规范在介绍一些技巧之前，有必要强调一下规范，这一点我发现...
sql 忽略大小写_这么骚的SQL进阶技巧，不怕被揍么？
weixin_39631467的博客
11-25 173
由于工作需要，最近做了很多 BI 取数的工作，需要用到一些比较高级的 SQL 技巧，总结了一下工作中用到的一些比较骚的进阶技巧，特此记录一下，以方便自己查阅。图片来自 Pexels主要目录如下：SQL 的书写规范SQL 的一些进阶使用技巧SQL 的优化方法SQL 的书写规范在介绍一些技巧之前，有必要强调一下规范，这一点我发现工作中经常被人忽略，其实遵循好的规范可读性会好很多，应该遵循哪些规范呢?①...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值