SQL优化思路+经典案例分析

最新推荐文章于 2024-09-19 22:25:59 发布
最新推荐文章于 2024-09-19 22:25:59 发布
阅读量1.9k 收藏 44
点赞数 3
分类专栏： java 文章标签： sql 数据库 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_71777195/article/details/127192470
版权
java 专栏收录该内容
3550 篇文章 121 订阅
订阅专栏

前言

SQL调优这块呢，大厂面试必问的。最近金九银十嘛，所以整理了SQL的调优思路，并且附几个经典案例分析。

1.慢SQL优化思路。

  1. 慢查询日志记录慢SQL

  2. explain分析SQL的执行计划

  3. profile 分析执行耗时

  4. Optimizer Trace分析详情

  5. 确定问题并采用相应的措施

1.1 慢查询日志记录慢SQL

如何定位慢SQL呢、我们可以通过慢查询日志来查看慢SQL。默认的情况下呢，MySQL数据库是不开启慢查询日志（slow query log）呢。所以我们需要手动把它打开。

查看下慢查询日志配置，我们可以使用show variables like 'slow_query_log%'命令，如下：

  • slow query log表示慢查询开启的状态

  • slow_query_log_file表示慢查询日志存放的位置

我们还可以使用show variables like 'long_query_time'命令，查看超过多少时间，才记录到慢查询日志，如下：

  • long_query_time表示查询超过多少秒才记录到慢查询日志。

我们可以通过慢查日志，定位那些执行效率较低的SQL语句，重点关注分析。

1.2 explain查看分析SQL的执行计划

当定位出查询效率低的SQL后，可以使用explain查看SQL的执行计划。

当explain与SQL一起使用时，MySQL将显示来自优化器的有关语句执行计划的信息。即MySQL解释了它将如何处理该语句，包括有关如何连接表以及以何种顺序连接表等信息。

一条简单SQL，使用了explain的效果如下：

一般来说，我们需要重点关注type、rows、filtered、extra、key。

1.2.1 type

type表示连接类型，查看索引执行情况的一个重要指标。以下性能从好到坏依次：system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

  • system：这种类型要求数据库表中只有一条数据，是const类型的一个特例，一般情况下是不会出现的。

  • const：通过一次索引就能找到数据，一般用于主键或唯一索引作为条件，这类扫描效率极高，，速度非常快。

  • eq_ref：常用于主键或唯一索引扫描，一般指使用主键的关联查询

  • ref : 常用于非主键和唯一索引扫描。

  • ref_or_null：这种连接类型类似于ref，区别在于MySQL会额外搜索包含NULL值的行

  • index_merge：使用了索引合并优化方法，查询使用了两个以上的索引。

  • unique_subquery：类似于eq_ref，条件用了in子查询

  • index_subquery：区别于unique_subquery，用于非唯一索引，可以返回重复值。

  • range：常用于范围查询，比如：between ... and 或 In 等操作

  • index：全索引扫描

  • ALL：全表扫描

1.2.2 rows

该列表示MySQL估算要找到我们所需的记录，需要读取的行数。对于InnoDB表，此数字是估计值，并非一定是个准确值。

1.2.3 filtered

该列是一个百分比的值，表里符合条件的记录数的百分比。简单点说，这个字段表示存储引擎返回的数据在经过过滤后，剩下满足条件的记录数量的比例。

1.2.4 extra

该字段包含有关MySQL如何解析查询的其他信息，它一般会出现这几个值：

  • Using filesort：表示按文件排序，一般是在指定的排序和索引排序不一致的情况才会出现。一般见于order by语句

  • Using index ：表示是否用了覆盖索引。

  • Using temporary: 表示是否使用了临时表,性能特别差，需要重点优化。一般多见于group by语句，或者union语句。

  • Using where : 表示使用了where条件过滤.

  • Using index condition：MySQL5.6之后新增的索引下推。在存储引擎层进行数据过滤，而不是在服务层过滤，利用索引现有的数据减少回表的数据。

1.2.5 key

该列表示实际用到的索引。一般配合possible_keys列一起看。

1.3 profile 分析执行耗时

explain只是看到SQL的预估执行计划，如果要了解SQL真正的执行线程状态及消耗的时间，需要使用profiling。开启profiling参数后，后续执行的SQL语句都会记录其资源开销，包括IO，上下文切换，CPU，内存等等，我们可以根据这些开销进一步分析当前慢SQL的瓶颈再进一步进行优化。

profiling默认是关闭，我们可以使用show variables like '%profil%'查看是否开启，如下：

可以使用set profiling=ON开启。开启后，可以运行几条SQL，然后使用show profiles查看一下。

show profiles会显示最近发给服务器的多条语句，条数由变量profiling_history_size定义，默认是15。如果我们需要看单独某条SQL的分析，可以show profile查看最近一条SQL的分析，也可以使用show profile for query id（其中id就是show profiles中的QUERY_ID）查看具体一条的SQL语句分析。

除了查看profile ，还可以查看cpu和io，如上图。

1.4 Optimizer Trace分析详情

profile只能查看到SQL的执行耗时，但是无法看到SQL真正执行的过程信息，即不知道MySQL优化器是如何选择执行计划。这时候，我们可以使用Optimizer Trace，它可以跟踪执行语句的解析优化执行的全过程。

我们可以使用set optimizer_trace="enabled=on"打开开关，接着执行要跟踪的SQL，最后执行select * from information_schema.optimizer_trace跟踪，如下：

大家可以查看分析其执行树，会包括三个阶段：

  • join_preparation：准备阶段

  • join_optimization：分析阶段

  • join_execution：执行阶段

1.5 确定问题并采用相应的措施

最后确认问题，就采取对应的措施。

  • 多数慢SQL都跟索引有关，比如不加索引，索引不生效、不合理等，这时候，我们可以优化索引。

  • 我们还可以优化SQL语句，比如一些in元素过多问题（分批），深分页问题（基于上一次数据过滤等），进行时间分段查询

  • SQl没办法很好优化，可以改用ES的方式，或者数仓。

  • 如果单表数据量过大导致慢查询，则可以考虑分库分表

  • 如果数据库在刷脏页导致慢查询，考虑是否可以优化一些参数，跟DBA讨论优化方案

  • 如果存量数据量太大，考虑是否可以让部分数据归档

我之前写了一篇文章，有关于导致慢查询的12个原因，大家看一看一下哈:盘点MySQL慢查询的12个原因

2. 慢查询经典案例分析

2.1 案例1：隐式转换

我们创建一个用户user表

CREATE TABLE user (
  id int(11) NOT NULL AUTO_INCREMENT,
  userId varchar(32) NOT NULL,
  age  varchar(16) NOT NULL,
  name varchar(255) NOT NULL,
  PRIMARY KEY (id),
  KEY idx_userid (userId) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

userId字段为字串类型，是B+树的普通索引，如果查询条件传了一个数字过去，会导致索引失效。如下：

如果给数字加上'',也就是说，传的是一个字符串呢，当然是走索引，如下图：

为什么第一条语句未加单引号就不走索引了呢？这是因为不加单引号时，是字符串跟数字的比较，它们类型不匹配，MySQL会做隐式的类型转换，把它们转换为浮点数再做比较。隐式的类型转换，索引会失效。

2.2 案例2：最左匹配

MySQl建立联合索引时，会遵循最左前缀匹配的原则，即最左优先。如果你建立一个（a,b,c）的联合索引，相当于建立了(a)、(a,b)、(a,b,c)三个索引。

假设有以下表结构：

CREATE TABLE user (
  id int(11) NOT NULL AUTO_INCREMENT,
  user_id varchar(32) NOT NULL,
  age  varchar(16) NOT NULL,
  name varchar(255) NOT NULL,
  PRIMARY KEY (id),
  KEY idx_userid_name (user_id,name) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

假设有一个联合索引idx_userid_name，我们现在执行以下SQL，如果查询列是name，索引是无效的：

explain select * from user where name ='捡田螺的小男孩';

因为查询条件列name不是联合索引idx_userid_name中的第一个列，不满足最左匹配原则，所以索引不生效。在联合索引中，只有查询条件满足最左匹配原则时，索引才正常生效。如下，查询条件列是user_id

2.3 案例3：深分页问题

limit深分页问题，会导致慢查询，应该大家都司空见惯了吧。

limit深分页为什么会变慢呢？ 假设有表结构如下：

CREATE TABLE account (
  id int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',
  name varchar(255) DEFAULT NULL COMMENT '账户名',
  balance int(11) DEFAULT NULL COMMENT '余额',
  create_time datetime NOT NULL COMMENT '创建时间',
  update_time datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  KEY idx_name (name),
  KEY idx_create_time (create_time) //索引
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='账户表';

以下这个SQL，你知道执行过程是怎样的呢？

select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;

这个SQL的执行流程酱紫：

  1. 通过普通二级索引树idx_create_time，过滤create_time条件，找到满足条件的主键id。

  2. 通过主键id，回到id主键索引树，找到满足记录的行，然后取出需要展示的列（回表过程）

  3. 扫描满足条件的100010行，然后扔掉前100000行，返回。

因此，limit深分页，导致SQL变慢原因有两个：

  • limit语句会先扫描offset+n行，然后再丢弃掉前offset行，返回后n行数据。也就是说limit 100000,10，就会扫描100010行，而limit 0,10，只扫描10行。

  • limit 100000,10 扫描更多的行数，也意味着回表更多的次数。

如何优化深分页问题?

我们可以通过减少回表次数来优化。一般有标签记录法和延迟关联法。

标签记录法

就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。

假设上一次记录到100000，则SQL可以修改为：

select  id,name,balance FROM account where id > 100000 limit 10;

这样的话，后面无论翻多少页，性能都会不错的，因为命中了id索引。但是这种方式有局限性：需要一种类似连续自增的字段。

延迟关联法

延迟关联法，就是把条件转移到主键索引树，然后减少回表。如下

select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;

优化思路就是，先通过idx_create_time二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。

2.4  案例4：in元素过多

如果使用了in，即使后面的条件加了索引，还是要注意in后面的元素不要过多哈。in元素一般建议不要超过200个，如果超过了，建议分组，每次200一组进行哈。

反例:

select user_id,name from user where user_id in (1,2,3...1000000); 

如果我们对in的条件不做任何限制的话，该查询语句一次性可能会查询出非常多的数据，很容易导致接口超时。尤其有时候，我们是用的子查询，in后面的子查询，你都不知道数量有多少那种，更容易采坑.如下这种子查询：

select * from user where user_id in (select author_id from artilce where type = 1);

如果type = 1有1一千，甚至上万个呢？肯定是慢SQL。索引一般建议分批进行，一次200个，比如：

select user_id,name from user where user_id in (1,2,3...200);

in查询为什么慢呢？

这是因为in查询在MySQL底层是通过n*m的方式去搜索，类似union。

in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。

2.5 order by 走文件排序导致的慢查询

如果order by 使用到文件排序，则会可能会产生慢查询。我们来看下下面这个SQL：

select name,age,city from staff where city = '深圳' order by age limit 10;

它表示的意思就是：查询前10个，来自深圳员工的姓名、年龄、城市，并且按照年龄小到大排序。

查看explain执行计划的时候，可以看到Extra这一列，有一个Using filesort，它表示用到文件排序。

order by文件排序效率为什么较低

大家可以看下这个下面这个图:

order by排序，分为全字段排序和rowid排序。它是拿max_length_for_sort_data和结果行数据长度对比，如果结果行数据长度超过max_length_for_sort_data这个值，就会走rowid排序，相反，则走全字段排序。

2.5.1 rowid排序

rowid排序，一般需要回表去找满足条件的数据，所以效率会慢一点。以下这个SQL，使用rowid排序，执行过程是这样：

select name,age,city from staff where city = '深圳' order by age limit 10;

  1. MySQL为对应的线程初始化sort_buffer，放入需要排序的age字段，以及主键id；

  2. 从索引树idx_city， 找到第一个满足 city='深圳’条件的主键id,假设id为X；

  3. 到主键id索引树拿到id=X的这一行数据， 取age和主键id的值，存到sort_buffer；

  4. 从索引树idx_city拿到下一个记录的主键id，假设id=Y；

  5. 重复步骤 3、4 直到city的值不等于深圳为止；

  6. 前面5步已经查找到了所有city为深圳的数据，在sort_buffer中，将所有数据根据age进行排序；遍历排序结果，取前10行，并按照id的值回到原表中，取出city、name 和 age三个字段返回给客户端。

2.5.2 全字段排序

同样的SQL，如果是走全字段排序是这样的：

select name,age,city from staff where city = '深圳' order by age limit 10;

  1. MySQL 为对应的线程初始化sort_buffer，放入需要查询的name、age、city字段；

  2. 从索引树idx_city， 找到第一个满足 city='深圳’条件的主键 id，假设找到id=X；

  3. 到主键id索引树拿到id=X的这一行数据， 取name、age、city三个字段的值，存到sort_buffer；

  4. 从索引树idx_city 拿到下一个记录的主键id，假设id=Y；

  5. 重复步骤 3、4 直到city的值不等于深圳为止；

  6. 前面5步已经查找到了所有city为深圳的数据，在sort_buffer中，将所有数据根据age进行排序；

  7. 按照排序结果取前10行返回给客户端。

sort_buffer的大小是由一个参数控制的：sort_buffer_size。

  • 如果要排序的数据小于sort_buffer_size，排序在sort_buffer内存中完成

  • 如果要排序的数据大于sort_buffer_size，则借助磁盘文件来进行排序。

借助磁盘文件排序的话，效率就更慢一点。因为先把数据放入sort_buffer，当快要满时。会排一下序，然后把sort_buffer中的数据，放到临时磁盘文件，等到所有满足条件数据都查完排完，再用归并算法把磁盘的临时排好序的小文件，合并成一个有序的大文件。

2.5.3  如何优化order by的文件排序

order by使用文件排序，效率会低一点。我们怎么优化呢？

  • 因为数据是无序的，所以就需要排序。如果数据本身是有序的，那就不会再用到文件排序啦。而索引数据本身是有序的，我们通过建立索引来优化order by语句。

  • 我们还可以通过调整max_length_for_sort_data、sort_buffer_size等参数优化；

2.6 索引字段上使用is null， is not null，索引可能失效

表结构:

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `card` varchar(255) DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE,
  KEY `idx_card` (`card`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

单个name字段加上索引，并查询name为非空的语句，其实会走索引的，如下:

单个card字段加上索引，并查询name为非空的语句，其实会走索引的，如下:

但是它两用or连接起来，索引就失效了，如下：

很多时候，也是因为数据量问题，导致了MySQL优化器放弃走索引。同时，平时我们用explain分析SQL的时候，如果type=range,要注意一下哈，因为这个可能因为数据量问题，导致索引无效。

2.7 索引字段上使用（！= 或者 < >），索引可能失效

假设有表结构：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userId` int(11) NOT NULL,
  `age` int(11) DEFAULT NULL,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

虽然age加了索引，但是使用了！= 或者< >，not in这些时，索引如同虚设。如下：

其实这个也是跟mySQL优化器有关，如果优化器觉得即使走了索引，还是需要扫描很多很多行的哈，它觉得不划算，不如直接不走索引。平时我们用！= 或者< >，not in的时候，留点心眼哈。

2.8 左右连接，关联的字段编码格式不一样

新建两个表，一个user，一个user_job

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) CHARACTER SET utf8mb4 DEFAULT NULL,
  `age` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

CREATE TABLE `user_job` (
  `id` int(11) NOT NULL,
  `userId` int(11) NOT NULL,
  `job` varchar(255) DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

user表的name字段编码是utf8mb4，而user_job表的name字段编码为utf8。

执行左外连接查询,user_job表还是走全表扫描，如下：

如果把它们的name字段改为编码一致，相同的SQL，还是会走索引。

2.9 group by使用临时表

group by一般用于分组统计，它表达的逻辑就是根据一定的规则，进行分组。日常开发中，我们使用得比较频繁。如果不注意，很容易产生慢SQL。

2.9.1 group by执行流程

假设有表结构：

CREATE TABLE `staff` (
  `id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `id_card` varchar(20) NOT NULL COMMENT '身份证号码',
  `name` varchar(64) NOT NULL COMMENT '姓名',
  `age` int(4) NOT NULL COMMENT '年龄',
  `city` varchar(64) NOT NULL COMMENT '城市',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='员工表';

我们查看一下这个SQL的执行计划：

explain select city ,count(*) as num from staff group by city;

  • Extra 这个字段的Using temporary表示在执行分组的时候使用了临时表

  • Extra 这个字段的Using filesort表示使用了文件排序

group by是怎么使用到临时表和排序了呢？我们来看下这个SQL的执行流程

select city ,count(*) as num from staff group by city;

  1. 创建内存临时表，表里有两个字段city和num；

  2. 全表扫描staff的记录，依次取出city = 'X'的记录。

  • 判断临时表中是否有为city='X'的行，没有就插入一个记录 (X,1);

  • 如果临时表中有city='X'的行，就将X这一行的num值加 1；

  1. 遍历完成后，再根据字段city做排序，得到结果集返回给客户端。这个流程的执行图如下：

临时表的排序是怎样的呢？

就是把需要排序的字段，放到sort buffer，排完就返回。在这里注意一点哈，排序分全字段排序和rowid排序

  • 如果是全字段排序，需要查询返回的字段，都放入sort buffer，根据排序字段排完，直接返回

  • 如果是rowid排序，只是需要排序的字段放入sort buffer，然后多一次回表操作，再返回。

2.9.2 group by可能会慢在哪里？

group by使用不当，很容易就会产生慢SQL问题。因为它既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表。

  • 如果执行过程中，会发现内存临时表大小到达了上限（控制这个上限的参数就是tmp_table_size），会把内存临时表转成磁盘临时表。

  • 如果数据量很大，很可能这个查询需要的磁盘临时表，就会占用大量的磁盘空间。

2.9.3 如何优化group by呢

从哪些方向去优化呢？

  • 方向1：既然它默认会排序，我们不给它排是不是就行啦。

  • 方向2：既然临时表是影响group by性能的X因素，我们是不是可以不用临时表？

我们一起来想下，执行group by语句为什么需要临时表呢？group by的语义逻辑，就是统计不同的值出现的个数。如果这个这些值一开始就是有序的，我们是不是直接往下扫描统计就好了，就不用临时表来记录并统计结果啦?

可以有这些优化方案：

  • group by 后面的字段加索引

  • order by null 不用排序

  • 尽量只使用内存临时表

  • 使用SQL_BIG_RESULT

2.10  delete + in子查询不走索引！

之前见到过一个生产慢SQL问题，当delete遇到in子查询时，即使有索引，也是不走索引的。而对应的select + in子查询，却可以走索引。

MySQL版本是5.7，假设当前有两张表account和old_account,表结构如下：

CREATE TABLE `old_account` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',
  `name` varchar(255) DEFAULT NULL COMMENT '账户名',
  `balance` int(11) DEFAULT NULL COMMENT '余额',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='老的账户表';

CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',
  `name` varchar(255) DEFAULT NULL COMMENT '账户名',
  `balance` int(11) DEFAULT NULL COMMENT '余额',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='账户表';

执行的SQL如下：

delete from account where name in (select name from old_account);

查看执行计划，发现不走索引：

但是如果把delete换成select，就会走索引。如下：

为什么select + in子查询会走索引，delete + in子查询却不会走索引呢？

我们执行以下SQL看看：

explain select * from account where name in (select name from old_account);
show WARNINGS; //可以查看优化后,最终执行的sql

结果如下：

select `test2`.`account`.`id` AS `id`,`test2`.`account`.`name` AS `name`,`test2`.`account`.`balance` AS `balance`,`test2`.`account`.`create_time` AS `create_time`,`test2`.`account`.`update_time` AS `update_time` from `test2`.`account` 
semi join (`test2`.`old_account`)
where (`test2`.`account`.`name` = `test2`.`old_account`.`name`)

可以发现，实际执行的时候，MySQL对select in子查询做了优化，把子查询改成join的方式，所以可以走索引。但是很遗憾，对于delete in子查询，MySQL却没有对它做这个优化。

日常开发中，大家注意一下这个场景哈

肥肥技术宅
关注
专栏目录
基于AI大模型实现自然语言转SQL、SQL解释、SQL优化和SQL转换
AI天才研究院
06-28 518
随着大数据和人工智能技术的发展，数据分析和数据挖掘在各行各业中的应用越来越广泛。SQL（Structured Query Language）作为关系数据库的查询语言，是数据分析的重要工具。然而，SQL语言的复杂性和专业性使得许多非技术背景的用户难以直接使用，阻碍了数据的广泛利用。为了降低SQL的使用门槛，许多研究者和企业开始探索如何通过自然语言处理（NLP）技术，将自然语言转化为SQL查询语句，从而让用户可以通过自然语言与数据库进行交互。
SQL优化的思路和步骤
weixin_68954386的博客
05-23 221
in查询在进行cost代价计算时(代价=元组数 *IO平均值)，是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MVSOL设置了个临界值(eg_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参计算了。对于大分页的场暴，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式，一个是把上一次的最后一条数据，也即上面的c传过来，然后做"c< xxx”处理，但是这种一般需要改接口协议，并不一定可行。在索引上，避免使用NOT、!
一次非常有意思的SQL优化经历:从30248.271s到0.001s
iteye_6274的博客
05-19 1330
场景 我用的数据库是mysql5.6，下面简单的介绍下场景 课程表 create table Course( c_id int PRIMARY KEY, name varchar(10) ) 数据100条 学生表: create table Student( id int PRIMARY KEY, name varchar(10) ) 数据70000条 ...
Mysql高级篇（中）—— SQL优化
最新发布
weixin_44666786的博客
09-19 1737
本篇博文主要介绍了MySQL中的SQL优化思路、以及关联查询、子查询、分组排序相关优化内容；此外针对exists的理解，单路排序和多路排序的概念做了简述。
一个sql优化案例
xudajian的专栏
05-31 455
最近，公司上线一个新项目，但上线后没几天，数据库的性能问题尤为明显，其中一个较为特殊，查询缓慢，还经常导致应用端服务内存溢出而崩溃。 原语句： SELECT media_id,ad_id,ad_name, advertiser_id,ad_modify_time, ad_create_time, `status`,opt_status,delivery_range,inventory_type,open_url,bid,budget,budget_mode,mm.smart_...
Mysql优化方案
YuanZhea的博客
09-19 285
这篇文章讲述了在大家平时学习和工作中，遇到的80% 的sql优化方案。 一、创建数据表 CREATE TABLE `users` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(20) NOT NULL DEFAULT '0' C...
一个SQL优化很好的例子
cipanxiu3864的博客
01-23 200
在数据库开发的过程中有很多经典的优化例子；下面就是其中之一，这个SQL是要找日期的最小的值，这种情况通常大家会遇到；在写代买时特别留意，会有帮助； 原始的SQL语句： SELECT * from T...
SQL优化与索引设计 经典实战案例+原理思路详解
生成式AI应用架构与技术分享，实战架构案例和源码技术方案，前沿技术研究与科普
09-07 1660
SQL优化与索引使用是后端开发的重要技能之一，也是区分后端开发能力强弱的关键技能之一，但其涉及的知识理论之广之深，任拿其中一点都足以成书。正如培养一个飞行员，不单单要有理论和地面模拟试驾，更要有足够的驾驶战机飞行时间，在能充分掌握SQL优化和索引的大部分理论后，充足丰富的SQL优化经验对于该项能力的磨练十分关键，纸上得来终觉浅，觉知此事要躬行。本文分享了近期工作中遇到的两个经典case，在解决过程中运用实践了大量理论，愿在文中的相处，能为你带来工作与生活中的灵感。
SQL优化实战经典案例分析
m0_73583495的博客
12-24 198
今天和大家聊聊SQL优化的场景。SQL调优这块呢，大厂面试必问的。最近金九银十嘛，所以整理了SQL的调优思路，并且附几个经典案例分析。
收获不止SQL优化
08-07
第2章　风驰电掣——有效缩短SQL优化过程 24 2.1　SQL调优时间都去哪儿了 25 2.1.1　不善于批处理频频忙交互 25 2.1.2　无法抓住主要矛盾瞎折腾 25 2.1.3　未能明确需求目标白费劲 26 2.1.4　没有分析操作难度乱调优...
数据库应用+SQL优化+Git
weixin_55817753的博客
06-25 4817
数据库应用1.1 概念1.1.1 什么是数据库1.1.2 关系型和非关系型1.1.3 关系型数据库1.2 Mysql数据库1.2.1 MySQL数据存放在哪里？1.2.2 MySQL服务端1.2.3 MySQL客户端1：DOS窗口1.2.4 MySQL客户端2：可视化工具1.3 数据库的结构1.3.1 数据库结构1.4 SQL语句1.4.1 定义1.4.2 分类1.5
基于Oracle的SQL优化典型案例分
04-28
基于Oracle的SQL优化典型案例分
sql语句的优化分析
weixin_34062469的博客
04-25 172
开门见山，问题所在 sql语句性能达不到你的要求，执行效率让你忍无可忍，一般会时下面几种情况。 网速不给力，不稳定。 服务器内存不够，或者SQL 被分配的内存不够。 sql语句设计不合理 没有相应的索引，索引不合理 没有有效的索引视图 表数据过大没有有效的分区设计 数据库设计太2，存在大量的数据冗余 索引列上缺少相应的统计信息，或者统计信息过期 .... 那么我们如何...
sql优化思路
xiao玖的博客
09-09 346
SQL优化 1、查询语句中不要使用select * 2、尽量减少子查询，使用关联查询（left join,right join,inner join）替代 3、减少使用IN或者NOT IN ,使用exists，not exists或者关联查询语句替代 4、or 的查询尽量用 union或者union all 代替(在确认没有重复数据或者不用剔除重复数据时，union all会更好) 5、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 6、应尽量避免在
SQL优化思路
ianhol的博客
10-13 1176
SQL优化步骤 1.   使用pt-query-digest分析慢日志，拿到调用频率高并且执行时间长的语句。 2.   获取语句相关表的信息，以及explain等相关信息，一般收集如下信息 l  执行计划：explain query;l  详细执行计划：explain extended query;show warnings;l  相关表信息：show create table te
SQL优化的一些思路
c82525的博客
03-14 544
SQL优化的一些思路
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值