侧边栏壁纸
博主头像
coydone博主等级

记录学习,分享生活的个人站点

  • 累计撰写 306 篇文章
  • 累计创建 51 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

SQL优化

coydone
2022-01-16 / 0 评论 / 0 点赞 / 321 阅读 / 12,942 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-04-07,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

B站黑马程序员《MySQL高级》:https://www.bilibili.com/video/BV1Kr4y1i7ru?p=75

步骤

在应用的开发过程中,由于初期数据量小,开发人员写SQL语句时更重视功能上的实现,但是当应用系统正式上线后,随着生产数据量的急剧增长,很多SQL语句开始逐渐显露出性能问题,对生产的影响也越来也大,此时这些有问题的SQL语句就成为整个系统性能的瓶颈,因此我们必须要对它们进行优化。

当面对一个有SQL性能问题的数据库时,我们应该从何处入手来进行系统的分析,使得能够尽快定位问题SQL并尽快解决问题?

1、查看SQL执行频率

MySQL客户端连接成功后,通过show [session | global] status命令可以提供服务器状态信息。该命令可以根据需要加上参数session或者global来显示session级(当前连接)的统计结果、和global级(自数据库上次启动至今)的统计结果。如果不写,默认使用参数为session。

-- 显示当前session中所有统计参数的值
show status like 'Com_______';

show global status like 'Innodb_rows_%';

Com_xxx表示每个xxx语句执行的次数,我们通常比较关心的是以下几个统计参数:

参数 含义
Com_select 执行select操作的次数,一次查询只累加1
Com_insert 执行INSERT操作的次数,对于批量插入的INSERT操作,只累加1次
Com_update 执行UPDATE操作的次数
Com_delete 执行DELETE操作的次数
Innodb_rows_read select查询返回的行数
Innodb_rows_inserted 执行INSERT操作插入的行数
Innodb_rows_updated 执行UPDATE操作更新的行数
Innodb_rows_deleted 执行DELETE操作删除的行数
Connections 试图连接MYSQL服务器的次数
Uptime 服务器工作时间
Slow_queries 慢查询的次数

Com_***:这些参数对于所有存储引擎的表操作都会进行累计。Innodb_***:这几个参数只是针对InnoDB存储引擎的,累加的算法也略有不同。

2、定位低效率执行SQL

可以通过以下两种方式定位执行效率低的SQL语句。

  • 慢查询日志:通过慢查询日志定位那些执行效率较低的SQL语句,用--log-slow-queries[=file_name]选项启动时,mysqlId写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。

  • show processlist:慢查询日志在查询结束以后才记录,所有在应用反映执行效率出现问题的时候查询日志并不能定位问题,可以使用show processlist 命令查看当前MySQL在进行的线程,包括线程的状态、是否锁表等,可以实时地查看SQL的执行情况,同时对一些锁表操作进行优化。

1、id列,用户登录mysql时,系统分配的“connection_id”,可以使用函数connection_id()查看
2、user列,显示当前用户。如果不是root,这个命令就只显示用户权限范围的sql语句
3、host列,显示这个语句是从哪个ip的哪个端口上发的,可以用来跟踪出现问题语句的用户
4、db列,显示这个进程目前连接的是哪个数据库
5、command列,显示当前连接的执行的命令,一般取值为休眠(sleep)、查询(query)、连接(connect)等
6、time列,显示这个状态持续的时间,单位为秒
7、state列,显示使用当前连接的sql语句的状态,很重要的列。state描述的是语句执行中的某一个状态。
   一个sql语句,以查询为例,可能需要经过copying to tmp table、sorting result、sending data等状态才可以完成
8、info列,显示这个sql语句,是判断问题语句的一个重要依据

3、explain分析执行计划

通过以上步骤查询到效率低的SQL语句后,可以通过EXPLAIN或者DESC命令获取MySQL如何执行select语句的信息,包括在select语句执行过程中如何连接和连接的顺序。

查询SQL语句的执行计划:

explain select * from tb_item where id = 1;

字段 含义
id select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序
select_type 表示SELECT的类型,常见的取值有SIMPLE(简单表,即不使用表连接或者子查询)、PRIMARY(主查询,即外层的查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(子查询中的第一个SELECT)等
table 输出结果集的表
type 表示表的连续类型,性能由好到差的连接类型为(system→const→eq_ref→ref→ref_or_null→index_merge→index_subquery→range→index→all)
possible_keys 表示查询时,可能使用的索引
key 表示实际使用的索引
key_len 索引字段的长度
rows 扫描行的数量
extra 执行情况的说明和描述

id:select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。id情况有三种:

  • id相同表示加载表的顺序是从上到下。

  • id不同id值越大,优先级越高,越先被执行。

  • id有相同,也有不同,同时存在。id相同的可以认为是一组,从上往下顺序执行,在所有的组中,id的值越大,优先级越高,越先执行。

select_type:表示select的类型,常见的取值,如下表所示:

select_type 含义
SIMPLE 简单的select查询,查询中不包含子查询或者UNION
PRIMARY 查询中若包含任何复杂的子查询,最外层查询标记为该标识
SUBQUERY 在select或where列表中包含了子查询
DERIVED 在from列表中包含的子查询,被标记为DERIVED(衍生)MYSQL会递归执行这些字查询,把结果放在临时表中
UNION 若第二个select出现在union之后,则标记为union;若union包含在from子句的子查询中,外层select将被标记为:DERIVED
UNION RESULT 从UNION表获取结果的select

table:展示这一行的数据是关于哪一张表的。

type:显示的是访问类型,是较为重要的一个指标,可取值为:

type 含义
NULL MySQL不访问任何表,索引,直接返回结果
system 表只有一行记录(等于系统表),这是const类型的特例,一般不会出现
const 表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据,所以很快。如将主键置于where列表中,MySQL就能将查询转换为一个常量。const将主键或唯一索引的所有部分与常量值进行比较
eq_ref 类似ref,区别在于使用的是唯一索引,使用主键的关联查询,关联查询出的记录只有一条。常见于主键或唯一索引扫描
ref 非唯一性索引扫描,返回匹配某个单独值的所有行。本质上也是一种索引访问,返回所有匹配某个单独值所有行(多个)
range 只检索给定返回的行,使用一个索引来选择行。where之后出现between、<、>、in等操作
index index与all的区别为index类型只是遍历了索引数,通常比all快,all是遍历数据文件
all 将遍历全表以找到匹配的行

一般来说,我们需要保证查询至少达到range级别,最好达到ref。

key:实际使用的索引,如果为NULL,则没有使用索引。

possible_keys:显示可能应用在这张表的索引,一个或多个。

key:实际使用的索引,如果为NULL,则没有使用索引。

key_len:表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下,长度越短越好。

rows:扫描行的数量。

extra:其它的额外的执行计划信息,在该列展示。

extra 含义
using filesort 说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取,称为文件排序,效率低
using temporary 使用了临时表保存中间结果,mysql在对查询结果排序时使用临时表。常见于order by和group by
using index 表示相应的select操作使用了覆盖索引,避免访问表的数据行,效率不错

show profile分析SQL

MySQL从5.0.37版本开始增加了对show profiles和show profile语句的支持。show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

通过have_profiling参数,能够看到当前MySQL是否支持profile:select @@have_profiling;。默认profiling是关闭的(select @@profiling;),可以通过set语句在Session级别开启profiling。

set profiling=1; --开启profiling开关

通过profile,我们能够更清楚地了解SQL执行的过程。

首先,我们可以执行一系列的操作,再执行show profiles指令,来查看SQL语句执行的耗时:

通过show profile for query query_id语句可以查看到该SQL执行过程中每个线程的状态和消耗的时间:

Sending data 状态表示MySQL线程开始访问数据行并把结果返回给客户端,而不仅仅是返回客户端。由于在Sending data状态下,MySQL线程往往需要做大量的磁盘读取操作,所以经常是整个查询中耗时最长的状态。

在获取到最消耗时间的线程状态后,MySQL支持进一步选择all、cpu、block io、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如,选择查看CPU的耗费时间:

trace分析优化器执行计划

MySQL5.6提供了对SQL的跟踪trace,通过trace文件能够进一步了解为什么优化器选择A计划,而不是B计划。

打开trace,设置格式为JSON,并设置trace最大能够使用的内存大小,避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace="enabled=on",end_markers_in_json=on;
SET optimizer_trace_max_mem_size=1000000

执行SQL语句:select * from tb_item where id <= 4;

最后,检查information_schema.optimizer_trace就可以知道MySQL是如何执行SQL的:

select * from information_schema.optimizer_trace\G;

索引的使用

索引是数据库优化最常用也是最重要的手段之一,通过索引通常可以帮助用户解决大多数的MySQL的性能优化问题。

-- 根据id查询,查询速度很快,主要原因是id是主键,有索引
select * from tb_item where id = 1999\G;
-- 根据name查询,速度慢,因为name没有索引
select * from tb_item where name = '张三';
-- 解决方案,针对name字段,创建索引
create index idx_item_name on tb_item(name);

避免索引失效

1、全值匹配,对索引中所有列都指定具体值。该情况下,索引生效,执行效率高。

-- 创建联合索引
create index idx_seller_name_sta_addr on tb_seller(name,status,address);
-- 测试
explain select * from tb_seller where name = '小米科技' and status = '1' and address = '北京市'\G;

2、最左前缀法则

如果索引了多列,要遵守最左前缀法则。指的是查询从索引的最左前列开始,并且不跳过索引中的列。

匹配最左前缀法则,走索引:(与查询条件的顺序无关,只看查询的条件包不包含)

-- 此时name走索引,address不走索引
explain select * from tb_seller where name = '小米科技' and address = '北京市';

3、范围查询右边的列,不能使用索引。

根据前面的两个字段name、status查询时走索引的,但是最后一个条件address没有用到索引。(范围查询后的字段索引失效)

4、不要在索引列上进行运行操作,索引将失效。

5、字符串不加单引号,造成索引失效。(底层会对字符串隐式运算操作)

6、尽量使用覆盖索引(只访问索引的查询,即索引列完全包含查询列),避免select *。如果查询列超出索引列,也会降低性能。

using index:使用覆盖索引的时候就会出现
using where:在查找使用索引的情况下,需要回表去查询所需的数据
using index condition:查找使用了索引,但是需要回表查询数据
using index; using where:查找使用了索引,但是需要的数据都在索引列中能找到,所以不需要回表查询数据

7、用or分割开的条件,如果or前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会被用到。

-- name字段是索引列,而createtime不是索引列,中间是or进行连接是不走索引的
explain select * from tb_seller where name='张三' or createtime='2020-01-01 12:00:00';

8、以%开头的like模糊查询,索引失效。如果仅仅是尾部模糊查询,索引不会失效。如果是头部模糊查询,索引失效。

解决方案:通过覆盖索引来解决。

explain select sellerid,name,status,address from tb_seller where name like '%科技%';

9、如果MySQL评估使用索引比全表更慢,则不使用索引。

10、is NULL,is NOT NULL 有时索引失效。(根据数据库数据量决定,如果NULL值比较多,is NOT NULL走索引,反之亦然)

11、in 走索引,not in索引失效。

12、单列索引和复合索引。尽量使用复合索引,而少使用单列索引。

-- 就相当于创建了三个索引:name、name+status、name+status+address
create index idx_name_sta_address on tb_seller(name,status,address);

-- 创建单列索引,数据库会选择一个最优的索引(辨识度最高的索引)来使用,并不会使用全部索引

查看索引使用情况

show status like 'Handler_read%';
show global status like 'Handler_read%';

Handler_read_first:索引中第一条被读的次数。如果越高,表示服务器正执行大量全索引扫描(这个值越低越好)
Handler_read_key:如果索引正在工作,这个值代表一个行被索引值读的次数,如果值越低,表示索引得到的性能改善不高,因为索引不经常使用(这个值越高越好)。
Handler_read_next:按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列,该值增加。
Handler_read_prev:按照键顺序读前一行的请求数。该读方法主要用于优化ORDER BY ... DESC。
Handler_read_rnd:根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。
    你可能使用了大量需要MySQL扫描整个表的查询或你的连接没有正确使用键。这个值较高,意味着运行效率低,应该建立索引来补救。
Handler_read_rnd_next:在数据文件中读下一行的请求数。如果你正进行大量的表扫描,该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。    

SQL优化

大批量插入数据

当使用load命令导入数据的时候,适当的设置可以提高导入的效率。

对于InnoDB类型的表,有以下几种方式可以提高导入的效率:

1、主键顺序插入

因为InnoDB类型的表是按照主键的顺序保存的,所以将导入的数据按照主键的顺序排列,可以有效的提高导入数据的效率。如果InnoDB表没有主键,那么系统会自动默认创建一个内部列作为主键,所以如果可以给表创建一个主键,将可以利用这点,来提高导入数据的效率。

load data local infile '/root/sql.log' into table `tb_user` fields terminated by ',' lines terminated by '\n';

2、关闭唯一性校验

在导入数据前执行SET UNIQUE_CHECKS=0;,关闭唯一性效验,在导入结束后执行SET UNIQUE_CHECKS=1,恢复唯一性效验,可以提高导入的效率。

3、手动提交事务

如果应用使用自动提交的方式,建议在导入前执行SET AUTOCOMMIT=0,关闭自动提交,导入结束后再执行SET AUTOCOMMIT=1,打开自动提交,也可以提高导入的效率。

优化insert语句

当进行数据的insert操作的时候,可以考虑采用以下几种优化方案:

1、如果需要同时对一张表插入很多行数据时,应该尽量使用多个值表的insert语句,这种方式将大大的缩减客户端与数据库之间的连接、关闭等消耗。使得效率比分开执行的单个insert语句快。

-- 原始方式
insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');

-- 优化后的方案
insert into tb_test values(1,'Tom'),(2,'Cat');

2、在事务中进行数据插入

start transaction;
insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');
commit;

3、数据有序插入

优化order by语句

两种排序方式

  • 第一种是通过对返回数据进行排序,也就是通常说的filesort排序,所有不是通过索引直接返回排序结果的排序都叫FileSort排序。

  • 第二种通过有序索引顺序扫描直接返回有序数据,这种情况即为using index,不需要额外排序,操作效率高。

尽量减少额外的排序,通过索引直接返回有序数据。where条件和order by 使用相同的索引,并且order by的顺序和索引顺序相同,并且order by 的字段都是升序,或者都是降序。否则肯定需要额外的操作,这样就会出现FileSort。

Filesort优化

通过创建合适的索引,能够减少Filesort的出现,但是在某些情况下,条件限制不能让Filesort消失,那就需要加快Filesort的排序操作。对于Filesort,MySQL有两种排序算法:

1、两次扫描算法:MySQL4.1以前,使用该方式排序。首先根据条件取出排序字段和行指针信息,然后在排序区sort buffer 中排序,如果sort buffer不够,则在临时表temporary table中存储排序结果。完成排序之后,再根据行指针回表读取记录,该操作可能会导致大量随机I/O操作。

2、一次扫描算法:一次性取出满足条件的所有字段,然后在排序区sort buffer中排序后直接输出结果集。排序时内存开销较大,但是排序效率比两次扫描算法要高。

MySQL通过比较系统变量max_length_for_sort_data 的大小和Query语句取出的字段总大小,来判定是否那种排序算法,如果max_length_for_sort_data更大,那么使用第二种优化之后的算法,否则使用第一种。

可以适当提高sort_buffer_size和max_length_for_sort_data系统变量,来增大排序区的大小,提高排序的效率。

show variables like 'sort_buffer_size';
show variables like 'max_length_for_sort_data';

优化group by语句

由于group by 实际上也同样会进行排序操作,而且与order by相比,group by主要只是多了排序之后的分组操作。当然,如果在分组的时候还使用了其它的一些聚合函数,那么还需要一些聚合函数的计算。所以,在group by的实现过程中,与order by一样也可以利用到索引。

如果查询包含group by但是用户想要避免排序结果的消耗,则可以执行order by null 禁止排序。如下:

drop index idx_emp_age_salary on emp;
explain select age,count(*) from emp group by age; --using temporary,using filesort(使用临时表和文件系统)

-- 优化后
explain select age,count(*) from emp group by age order by null; --using temporary

-- 创建索引(不使用临时表,使用索引)
create index idx_emp_age_salary on emp(age,salary);

优化嵌套查询

MySQL4.1版本后,开始支持SQL子查询。这个技术可以使用select语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作,同时也可以避免事务或者表锁死,并且写起来也很容易。但是有些情况下,子查询是可以被更高效的连接(join)替代。

explain select * from t_user where id in (select user_id from user_role);
explain select * from t_user u,user_role ur where u.id = ur.user_id;

优化OR条件

对于包含or的查询子句,如果要利用索引,则or之间的每个条件列都必须用到索引,而且不能使用到复合索引;如果没有索引,则应该考虑增加索引。

explain select * from emp where id = 1 or age = 30;
-- 建议使用union替换or
explain select * from emp where id = 1 union select * from emp where age = 30;

我们来比较下重要指标,发现主要差别是type和ref两项

type显示的是访问类型,是较为重要的一个指标,结果值从好到坏依次是:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge 
> unique_subquery > index_subquery > range > index > all

union 语句的type值为ref,or语句的type值为range,可以看到这是一个很明显的差距。

union 语句的ref值为const,or语句的type值为null,const表示是常量值引用,非常快。这两项的差距就说明了union要优于or。

优化分页查询

一般分页查询时,通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是limit 2000000,10,此时需要MySQL排序前2000010记录,仅仅返回2000000-2000010的记录,其它记录丢弃,查询排序的代价非常大。

优化思路一

在索引上完成排序分页操作,最后根据主键关联回原表查询所需要的其它列内容。

explain select * from tb_item t ,
(select id from tb_item order by id limit 2000000,10) a 
where t.id = a.id;

优化思路二

该方案适用于主键自增的表,且主键不能断层。可以把limit查询转换成某个位置的查询。

explain select * from tb_item where id > 1000000 limit 10;

使用SQL提示

SQL提示,是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化操作的目的。

use index

在查询语句中表名的后面,添加use index 来提供希望MySQL去参考的索引列表,就可以让MySQL不再考虑其它可用的索引。

create index idx_seller_name on tb_seller(name);
explain select * from tb_seller use index(idx_seller_name) 
where name = '小米科技';

ignore index

如果用户只是单纯的想让MySQL忽略一个或者多个索引,则可以使用ignore index作为hint。

explain select * from tb_seller ignore index(idx_seller_name) 
where name = '小米科技';

force index

为强制MySQL使用一个特定的索引,可在查询中使用force index作为hint。

create index idx_seller_address on tb_seller(address);
explain select * from tb_seller force index(idx_seller_address) 
where address='北京市';

应用优化

在实际生产环境中,由于数据库本身的性能局限,就必须要对前台的应用进行一些优化,来降低数据库的访问压力。

使用连接池

对于访问数据库来说,建立连接的代价是比较昂贵的,因为我们频繁的创建关闭连接,是比较耗费资源的,我们有必要建立连接池,以提高访问的性能。

减少对MySQL的访问

1、避免对数据进行重复检索

在编写应用代码时,需要能够理清对数据库的访问逻辑。能够一次连接就获取到结果的,就不用两次连接,这样可以大大减少对数据库无用的重复请求。

2、增加cache层

在应用中,我们可以在应用中增加缓存层来达到减轻数据库负担的目的。缓存层有很多种,也有很多实现方式,只要能达到降低数据库的负担又能满足应用需求就可以。

因此可以部分数据从数据库抽取出来放到应用端以文本方式存储,或者使用框架mybatis、hibernate提供的一级缓存/二级缓存,或者使用redis数据库来缓存数据。

负载均衡

负载均衡是应用中使用非常普遍的一种优化方法,它的机制就是利用某种均衡算法,将固定的负载量分布到不同的服务器上,以此来降低单台服务器的负载,达到优化的效果。

1、利用MySQL复制分流查询

通过MySQL的主从复制,实现读写分离,使增删改操作走主节点,查询操作走从节点,从而可以降低单台服务器的读写压力。

2、采用分布式数据库架构

分布式数据库架构适合大数据量、负载高的情况,它有良好的扩展性和高可用性。通过在多台服务器之间分布数据,可以实现在多台服务器之间的负载均衡,提高访问效率。

MySQL中查询缓存优化

概述

开启MySQL的查询缓存,当执行完全相同的SQL语句的时候,服务器就会直接从缓存中读取结果,当数据被修改,之前的缓存会失效,修改比较频繁的表不适合做查询缓存。

操作流程

1、客户端发送一条查询给服务器。

2、服务器先会检查查询缓存,如果命中了缓存,则立即返回存储在缓存中的结果。否则进入下一阶段。

3、服务器端进行SQL解析、预处理,再由优化器生成对应的执行计划。

4、执行计划会查询执行引擎,通过存储引擎查询数据将结果返回给客户端,并将结果写入缓存中。

查询缓存配置

1、查看当前的MySQL数据库是否支持查询缓存:

show variables like 'have_query_cache';

2、查看当前MySQL是否开启了查询缓存:

show variables like 'query_cache_type';

3、查看查询缓存的占用大小:

show variables like 'query_cache_size'; --单位:字节

4、查看查询缓存的状态变量:

show status like 'Qcache%';

开启查询缓存

MySQL的查询缓存默认是关闭的,需要手动配置参数query_cache_type,来开启查询缓存。query_cache_type该参数的可取值有3个:

含义
OFF 或 0 查询缓存功能关闭
ON 或 1 查询缓存功能打开,select 到的结果符合缓存条件即会缓存,否则,不予缓存,显式指定SQL_NO_CACHE,不予缓存
DEMAND 或 2 查询缓存功能按需进行,显式指定SQL_CACHE的select语句才会缓存,其它均不予缓存

/usr/my.cnf配置中,增加以下配置:

# 开启mysql的查询缓存
query_cache_type=1

配置完毕后,重启服务即可生效。

查询缓存select选项

可以在select语句中指定两个与查询缓存相关的选项:

SQL_CACHE:如果查询结果是可缓存的,并且query_cache_type 系统变量的值为ON或DEMAND,则缓存查询结果。

SQL_NO_CACHE:服务器不使用查询缓存。它既不检查查询缓存,也不检查结果是否已缓存,也不缓存查询结果。

SELECT SQL_CACHE id,name FROM customer;
SELECT SQL_NO_CACHE id,name FROM customer;

查询缓存失效的情况

1、SQL语句不一致的情况,要想命中查询缓存,查询的SQL语句必须一致。(SQL语句的大小写也要一致)

2、当查询语句中有一些不确定的时,则不会缓存。如:now(),current_date(),curdate(),curtime(),rand(),uuid(),user(),database()。

select * from tb_item where updatetime < now() limit 1;
select user();
select database();

3、不使用任何查询语句。

select 'A';

4、查询mysql,information_schema 或 performance_schema 数据库中的表时,不会走查询缓存。

select * from information_schema.engines;

5、在存储的函数,触发器或事件的主体内执行的查询。

6、如果表更改,则使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除。这包括使用MERGE映射到已更改表的表的查询。一个表可以被许多类型的语句,如被改变insert、update、delete、truncate table、alter table、drop table 或drop database。

0

评论区