Mysql - 索引

目录

一、存储引擎

二、索引

索引结构

索引分类

 索引语法

 联合索引

前缀索引

索引使用规则

最左前缀法则

范围查询使索引失效 

字段做运算操作索引失效

字符串字段不加单引号索引失效

 字段做前模糊查询索引失效

or连接条件索引失效

数据发布情况索引失效

指定使用索引

三、帮助 SQL优化的工具

慢查询日志记录

 profiles

explain

四、SQL优化

为什么不要使用select *

插入优化 insert

主键优化

排序优化 order by

 分组优化group by

limit优化

count优化

update优化


一、存储引擎

MySQL体系结构:

查询当前数据库支持的存储引擎:

show engines ;

InnoDB是默认的存储引擎,也是最常用的,广泛应用于各种需要高并发和高可靠性的应用场景(支持事务、行级锁和外键

InnoDB引擎的数据文件:

xxx.ibd:xxx代表的是表名,innoDB引擎的每张表都会对应这样一个表空间文件,存储该表的表结构、数据和索引。

  • 表空间 : InnoDB存储引擎逻辑结构的最高层,ibd文件其实就是表空间文件,在表空间中可以 包含多个Segment段。
  • 段 : 表空间是由各个段组成的, 常见的段有数据段、索引段、回滚段等。InnoDB中对于段的管 理,都是引擎自身完成,不需要人为对其控制,一个段中包含多个区。
  • 区 : 区是表空间的单元结构,每个区的大小为1M。 默认情况下, InnoDB存储引擎页大小为 16K, 即一个区中一共有64个连续的页。
  • 页 : 页是组成区的最小单元,页也是InnoDB 存储引擎磁盘管理的最小单元,每个页的大小默 认为 16KB。为了保证页的连续性,InnoDB 存储引擎每次从磁盘申请 4-5 个区。
  • 行 : InnoDB 存储引擎是面向行的,也就是说数据是按行进行存放的,在每一行中除了定义表时 所指定的字段以外

创建表时,没有指定存储引擎,默认是InnoDB存储引擎。查看指定表使用的存储引擎等信息:

show create table emp;

 MyISAM是MySQL早期的默认存储引擎。(不支持事务,不支持外键 支持表锁,不支持行锁 访问速度快)

储存的文件 xxx.sdi:存储表结构信息 xxx.MYD: 存储数据 xxx.MYI: 存储索引

Memory引擎的表数据时存储在内存中的,由于受到硬件问题或断电问题的影响,只能将这些表作为临时表或缓存使用

在选择存储引擎时,应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统,还可以根据 实际情况选择多种存储引擎进行组合。

  • InnoDB: 是Mysql的默认存储引擎,支持事务、外键。如果应用对事务的完整性有比较高的要 求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包含很多的更新、删除操 作,那么InnoDB存储引擎是比较合适的选择。
  • MyISAM : 如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完 整性、并发性要求不是很高,那么选择这个存储引擎是非常合适的。
  • MEMORY:将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。MEMORY的缺陷就是 对表的大小有限制,太大的表无法缓存在内存中,而且无法保障数据的安全性。

二、索引

索引是一种用于提高数据库查询效率的数据结构。通过为表中的数据创建索引,即利用数据结构为数据创建一种映射关系,可以显著减少查询所需的时间,从而提高数据库的整体性能

索引结构

MySQL的索引是在存储引擎层实现的,不同的存储引擎有不同的索引结构,索引主要有以下几种:

索引结构描述
B+Tree索引最常见的索引类型,大部分引擎都支持 B+ 树索引
Hash索引底层数据结构是用哈希表实现的, 只有精确匹配索引列的查询才有效, 不 支持范围查询
R-tree(空间索 引)空间索引是MyISAM引擎的一个特殊索引类型,主要用于地理空间数据类 型,通常使用较少
Full-text(全文 索引)是一种通过建立倒排索引,快速匹配文档的方式。类似于Elasticsearch

B Tree的结构:

对于二叉树而言,最多只能有两个孩子节点,(度数最多为 2),但B树可以有多个孩子节点

最多有 n 个节点,那么就称为 n 阶B树,以 5 阶B树为例:

那这个B树每个节点最多存储4个key,5 个指针,即每个节点最多存储4个值和指向孩子节点的5个指针

 查数据时,与二叉搜索树类似,比插入值大的走右边,小的走左边,以下5阶B树插入数值19为例,其结构示意图:

 key的数量为5超过了4,需要分裂,中间元素上移。

B+Tree索引

B+Tree是B-Tree的变种,在分裂上移时,只是将key值赋值一份上移,值仍然存储在最下面的叶子节点上,也就是说,数据只存储在叶子节点 上,其它节点储存的是索引(key),在Mysql的B+Tree索引中,所有的叶子节点会形成双向链表,这样就可以做范围查询和排序等操作

 

为什么InnoDB存储引擎选择使用B+tree索引结构?

A. 相对于二叉树,层级更少,搜索效率高;

B. 对于B-tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储 的键值减少,指针跟着减少,要同样保存大量数据,只能增加树的高度,导致性能降低;

C. 相对Hash索引,B+tree支持范围匹配及排序操作;

MySQL中除了支持B+Tree索引,还支持一种索引类型---Hash索引。

Hash索引

将数据库中每一行数据有对应的哈希值,当我们对name字段添加索引时,就会为name所有值生成对应的hash值,映射到对应的槽位上,然后将name值和每一行得hash值存储在 hash表中,如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了hash冲突(也称为hash碰撞),可以通过链表来解决,也就是相同hash值得使用链表储存。

  • Hash索引只能用于对等比较(=,in),不支持范围查询(between,>,< ,...)
  • 无法利用索引完成排序操作
  • 查询效率高,通常(不存在hash冲突的情况)只需要一次检索就可以了,效率通常要高于B+tree索 引

索引分类

在MySQL数据库,将索引的具体类型主要分为以下几类:

主键索引(PRIMARY)、唯一索引(UNIQUE)、常规索引、全文索引

 其中主键索引只能有一个其它可以有多个

主键索引(PRIMARY)、唯一索引(UNIQUE)在建表时指定主键或唯一约束时会自动创建索引

常规索引为对特定数据创建索引

聚集索引、二级索引

在InnoDB存储引擎中,根据索引的存储形式,又可以分为以下两种:

  1. 聚集索引(Clustered Index):将数据存储与索引放到了一块,索引结构的叶子节点保存了行数据(必须有,而且只 有一个)
  2. 二级索引(Secondary Index):(辅助索引)将数据与索引分开存储,索引结构的叶子节点存放的值是对应的主键索引列的值

聚集索引选取规则:

如果存在主键,主键索引就是聚集索引。 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引。 如果表没有主键,或没有合适的唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索 引。

在查询二级索引中的数据时,会根据创建的索引去查询对应的主键,再根据主键去查询对应的整行数据,例如以下SQL:

select * from emp where name='Arm' ;

查询过程是:实现在二级索引中查询对应的主键id,再根据主键id去聚集索引去查询对应的行数据

而下面的SQL则是直接从聚集索引中查询整条数据,效率会更高些:

select * from emp where id= 10 ;

回表查询: 这种先到二级索引中查找数据,找到主键值,然后再到聚集索引中根据主键值,获取 数据的方式,就称之为回表查询。

 假设: 一行数据大小为1k,一页中可以存储16行这样的数据,即一页(一个叶子节点)可以存放16K的数据

InnoDB的指针占用6个字节的空间,主键假使为bigint,占用字节数为8。一个节点中指针数量永远比主键数量多一,所以:

高度为2: (n + 1) * 6 + n * 8 = 16*1024 , 算出n约为 1170,即指针有1171个,所以叶子节点有1171个,又每个叶子节点可以存储16行数据,所以:

1171 * 16 = 18736

即高度为2的树可以存储 18000 多条记录。

高度为3: 1171 * 1171 * 16 = 21939856,因为1170个节点中,每个节点又可以存储1171个子节点,也就是说,如果树的高度为3,则可以存储 2200w 左右的记录。

 阿里巴巴 Java 开发手册V1.2中:

14. 【推荐】单表行数超过500万行或者单表容量超过2GB,才推荐进行分库分表。 说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

 索引语法

#查询索引
show index from tb_user;
#创建唯一索引 
create unique index idx_user_phone on tb_user(phone);
#创建单列索引
create index idx_email on tb_user(email);
#创建联合索引
create index idx_profession_age_status on tb_user (profession, age, status);

 联合索引

  (Composite Index)是由两个或多个列组成的索引。这种索引可以提高在多个列上执行查询时的性能。使用联合使用需要遵循最左前缀法则

单列索引和联合索引的选择:

当需要多个条件查询时,建议创建联合索引。例如:

select id,username,password from tb_user where phone = '18081404110' and username = '张三' ;

 若phone和username都是单列索引,只能走一个索引,所以需要去查询另一个字段,必然会走回表查询,只是可以对两字段建立联合索引避免。能使用联合索引尽量使用联合索引

前缀索引

前缀索引是指在针对某一字段创建索引时,字段类型为字符串(varchar,text,longtext等)(例如文章数据)时,该字段的内容可能会很庞大,建立的索引的体积就会非常大,浪费大量的磁盘IO, 影响查询效率。可以减少索引的存储空间和维护成本

 语法:通过截取该字段的前一部分来做为索引的值

#以email字段的前五个字符创建索引
create index idx_content on tb_user(content(5));

 前缀长度

可以根据不重复的索引值(基数)和数据表的记录总数的比值来确定(也称选择性), 比值越高则查询效率越高, 唯一索引的选择性是 1,这是最好的索引选择性,性能也是最好的。

 比值查询示例:

 select  count(distinct content) / count(*)   from  tb_user ;select  count(distinct substring(content,1,5)) / count(*)  from  tb_user ;

 查询流程:先通过前缀去索引中查,在通过id回表查询查出该字段的整体值,比对是否与给出条件符合。

索引设计原则

  • 1). 针对于数据量较大,且查询比较频繁的表建立索引。
  • 2). 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索 引。
  • 3). 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高。
  • 4). 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引。
  • 5). 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间, 避免回表,提高查询效率。
  • 6). 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价也就越大,会影响增 删改的效率。
  • 7). 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含 NULL值时,它可以更好地确定哪个索引最有效地用于查询。

索引使用规则

最左前缀法则

在使用联合索引时应注意遵守的法则:

最左前缀法则:查询必须需包含的最左列, 并且不跳过索引中的列。如果跳跃某一列,索引将会部分失效(后面的字段索引失效)。

例如:以tb_user表的profession, age, status三个字段创建联合索引为例:

使用explain关键字可以显示 SQL 查询的执行计划,详细看【帮助 SQL优化的工具】

正常使用三字段时,走索引,三字段都走索引,索引长度为49:

当查询时没有最左列profession则不会使用索引查询:

当只使用profession字段,正常走索引,索引长度只有profession的长度47

当使用前两个字段时会走索引,profession和age两字段时索引长度为49

当中间age字段跳过,没有使用时,则此后面的字段status使用索引失效,索引长度只有profession的长度47

范围查询使索引失效 

若某字段出现范围查询小于(<)、大于(>)则该字段右侧的列索引会失效,例如age使用此范围查询时,status的索引会失效,但是使用小于等于(<=)、大于等于(>=)时不会失效

注意】这与我们写的SQL条件先后顺序无关,例如必须需包含的最左列,是指查询条件中有索引的最左列profession即可使索引失效。SQL中的条件书写顺序无需与索引顺序一致

字段做运算操作索引失效

当我们在使用某字段索引时,若对该索引做了运算,则会使索引失效。

例如:我们对手机号phone字段创建了索引,在使用时加了字符串截取的运算,查询手机号后四位为4110的用户信息,此时会使索引失效

select * from tb_user where substring(phone,7,4) = '4110';
字符串字段不加单引号索引失效

在字符串类型的字段做条件查询时,没加单引号,虽然能查出数据,但是不会走索引

select * from tb_user where substring(phone,7,4) = 4110 ;
 字段做前模糊查询索引失效

当对某字段做模糊查询时,只要%加在前面会使索引失效,比如:查询姓名以”三“结尾的用户信息

select * from tb_user where username like '%三' ;

 而以下形式就不会使索引失效:查询姓张的用户

select * from tb_user where username like '张%' ;
or连接条件索引失效

当使用or做连接条件查询时,需要or连接的条件的字段都要有索引才能使索引生效,有其中一个字段没有索引,索引都不会生效

例如:查询性别为男或则年龄为20的用户:若age有索引而gender没有索引,则索引失效

select * from tb_user where gender = '男' or age = 20 ;
数据发布情况索引失效

当我们在做查询时,绝大部分数据是满足我们的条件时,MySQL评估使用索引比全表更慢,则不使用索引,相反,Mysql评估走索引会更快才会走索引。

指定使用索引

当我们在做条件查询时,字段有多个索引时,可以指定Mysql使用哪个索引,有以下三种方式:

use 建议Mysql走指定索引,其中Mysql会做评估,有更快的索引时,不会走建议的索引

explain select * from tb_user use index(idx_profession) where profession = '英语' ;

ignore 忽略指定的索引:

explain select * from tb_user ignore index(idx_profession) where profession = '英语' ;

force 强制使用指定索引:

explain select * from tb_user force index(idx_profession) where profession = '英语' ;

三、帮助 SQL优化的工具

在MySQL中,SHOW GLOBAL STATUS 是一个非常有用的命令,它显示了服务器级别的状态变量。这些状态变量提供了关于服务器运行时的各种统计信息和性能指标。使用这个命令可以帮助你了解服务器的当前状态,诊断问题,或者优化数据库性能

使用like关键字进行过滤(Com后面7个 _ 模糊查询Com后7个字符的状态信息):

show global status like 'Com_______';

 索引主要是针对查询,当数据库查询占绝大部分比例时,可能需要考虑创建索引来优化数据库性能

慢查询日志记录

Mysql默认关闭,需要配置开启才能失效,可以通过这些记录去优化这些SQL

查询是否开启慢查询日志记录

show variables like 'slow_query_log' ;

 

 编辑my.cnf文件,末尾追加以下内容:

sudo vim /etc/mysql/my.cnf

 我的是Ubuntu系统,其它系统类似,windows中是my.ini

[mysqld]
#开启慢查询日志记录,当SQL执行时间超过指定时间时就会记录日志到/var/lib/mysql/localhost-slow.log
slow_query_log=1
#日志存放地址
slow_query_log_file = /var/log/mysql/mysql-slow.log
#指定时间
long_query_time=2

查询是否配置成功:

 profiles

使用profiles查询SQL执行时间等情况:

查看当前MySQL是否支持profile操作:

SELECT @@have_profiling ;

 开启profiling:

SET  profiling = 1;

 查询所有命令执行耗时和根据命令id查询耗时:

explain

        在MySQL中,EXPLAIN 是一个非常有用的命令,用于显示 SQL 查询的执行计划。执行计划是数据库如何执行查询的详细说明,包括它如何使用索引、表的连接顺序、预计需要扫描的行数等。通过分析执行计划,你可以优化查询性能,理解查询的工作原理。

 EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息,多条数据时包括在 SELECT 语句执行过程中表如何连接和连接的顺序

使用:直接在select语句之前加上关键字 explain / desc

各字段含义
字段含义
idselect查询的序列号,表示查询中执行select子句或者是操作表的顺序 (id相同,执行顺序从上到下;id不同,值越大,越先执行)。
select_type表示 SELECT 的类型,常见的取值有 SIMPLE(简单表,即不使用表连接 或者子查询)、PRIMARY(主查询,即外层的查询)、 UNION(UNION 中的第二个或者后面的查询语句)、 SUBQUERY(SELECT/WHERE之后包含了子查询)等
type表示连接类型,性能由好到差的连接类型为NULL、system、const、 eq_ref、ref、range、 index、all 。
possible_key显示可能应用在这张表上的索引,一个或多个。
key实际使用的索引,如果为NULL,则没有使用索引。
key_len表示索引中使用的字节数, 该值为索引字段最大可能长度,并非实际使用长 度,在不损失精确性的前提下, 长度越短越好 。
rowsMySQL认为必须要执行查询的行数,在innodb引擎的表中,是一个估计值, 可能并不总是准确的。
filtered表示返回结果的行数占需读取行数的百分比, filtered 的值越大越好。
extra

额外信息。这里可以显示一些额外的执行计划信息,如是否使用了临时表、是否需要进行文件排序等。

using index condition : 查找使用了索引,但需要回表查询

using where;using index: 查找使用了索引,在索引中能查到所需的数据,无需回表查询

四、SQL优化

为什么不要使用select *

因为 * 会包含没有创建索引的字段,此时通过索引不能直接查到信息的字段,需要通过id做回表查询,也就是说尽量使用覆盖索引(查询的字段写明,并且这些字段都可以通过走一边索引即可查询到所需的数据,无需回表查询),索引有聚集索引和二级索引两类,聚集索引包含整行数据,二级索引也就是我们对字段创建的索引,只包含该索引字段的数据和id。

以根据用户名查询用户的id例当已经为username创建单列索引时

select * from tb_user where username = '张三' ;

该查询会走username的索引,能走索引查出username 和 id,但是select * 还需要查询其它信息,索引还要根据id在聚集索引中查询其它信息,即回表查询。这样走了两次索引,效率就有所降低。

 而使用以下SQL不用走回表查询时,效率更高:

select id from tb_user where username = '张三' ;

 再以用户名查询用户id、用户名、用户密码为例:

select id,username,password from tb_user where username = '张三' ;

当我们要查询效率更高时,可以为username和password建立联合索引时,不需要走回表查询去查询其它信息,查询效率更高。

插入优化 insert

批量插入,防止频繁的执行SQL语句

insert into tb_user values
('1','张三'),
('2','李四'),
('3','王五');

 手动提交事务,防止事务频繁的开启和提交

start  transaction;insert  into  tb_test  values(1,'Tom'),(2,'Cat'),(3,'Jerry');insert  into  tb_test  values(4,'Tom'),(5,'Cat'),(6,'Jerry');insert  into  tb_test  values(7,'Tom'),(8,'Cat'),(9,'Jerry');
commit;

 主键顺序插入,性能要高于乱序插入

比如,按照主键id  1、2、3、4、5...的顺序插入

大批量数据插入

如果一次性需要插入大批量数据(比如: 几百万的记录),使用insert语句插入性能较低,此时可以使 用MySQL数据库提供的 load 指令进行插入。操作如下:

1、客户端连接服务端时,加上参数 -–local-infile

 mysql –-local-infile  -u  root  -p

 2、设置全局参数local_infile为1,开启从本地加载文件导入数据的开关

set  global  local_infile = 1;

3、执行load指令将准备好的数据,加载到表结构中

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

 其中 /root/load_user.sql 是大批量数据文件的路径

插入到 tb_user 表中,字段之间是 ',' 分割,每行之间是 '\n' 分割

这样插入性能高于insert,若主键是顺序插入性能高于乱序插入

主键优化

在InnoDB存储引擎中,表数据都是根据主键顺序组织存放的,这种存储方式的表称为索引组织表

逻辑存储结构是表空间-->段-->区-->页-->行

页分裂

因为B+Tree索引中,数据都是存储在叶子节点,并且数据是按照索引字段(主键)顺序存放,当乱序插入时,会出现以下情况:

页合并

当相邻两页之间的数据只有50%时,InnoDB会判断是否可以将两页进行合并,若可以则会将该相邻两页的数据进行合并,50%可以在创建表或者创建索引时指定参数MERGE_THRESHOLD设置,默认是50%。

  • 满足业务需求的情况下,尽量降低主键的长度,减小索引体积
  • 插入数据时,尽量选择顺序插入,选择使用AUTO_INCREMENT自增主键。
  • 尽量不要使用UUID做主键或者是其他自然主键,如身份证号。 业务操作时,避免对主键的修改。因为这些都是乱序的主键,会出现页分裂的情况

排序优化 order by

MySQL的排序,有两种方式

        Using filesort : 通过表的索引或全表扫描,读取满足条件的数据行,然后在排序缓冲区sort buffer中完成排序操作,所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。

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

        Using filesort 通常比使用索引排序慢得多,因为它需要在磁盘上创建临时文件并进行排序操作。这会增加 I/O 操作,从而影响查询性能。在大数据量的情况下,Using filesort 可能会显著降低查询效率。Using index的性能高,而Using filesort的性能低,我们在优化排序 操作时,尽量要优化为 Using index

当根据年龄(age)字段排序查询时,可以看出extra额外信息显示的是Using filesort

当我们对price字段创建了索引进行排序时,正常走索引,效率高,当使用select * 即需要回表查询做排序操作时,还是会另开辟空间做Using filesort 查询

当根据age倒叙排列,而B+Tree中索引中,数据是根据索引字段正序排列,反向扫描索引(Backward index scan;)

 对多字段进行排序:

先对价格(price)进行排序,若价格相同,则根据评分排序:

explain select id, price, score  from tb_hotel order by price, score;

 针对多字段进行排序的情况需要对这多字段创建联合索引,才能让排序走索引:

 这时需要注意,两字段要都是升序或都是降序才能走索引,并且必须是先根据price排序再根据score排序才会走索引,因为这是创建的联合索引,若是先根据score排序则违背了最左前缀法则,不会走索引,Collection列是A表示索引中的数据根据升序排列

 若一个升序一个降序,即price升序,score降序,则根据price排序时会走索引,而price相同时根据score降序排序则不会走索引,这时若想走索引则需要再创建一个索引指定索引中的字段数据price升序,score降序:

创建索引时指定规则(ASC/DESC),默认是升序ASC。

 create index idx_price_score_AD on tb_hotel(price asc,score desc);

 若不得不走缓存区使用Using filesort 进行排序,在大数据量的情况下可以增加缓冲区的大小:

查看缓冲区大小:

show variables like 'sort_buffer_size';

order by优化总结:

  1. 根据排序字段建立合适的索引,多字段排序时,也遵循最左前缀法则。
  2. 尽量使用覆盖索引。
  3. 多字段排序, 一个升序一个降序,此时需要注意联合索引在创建时的规则(ASC/DESC)。
  4. 如果不可避免的出现filesort,大数据量排序时,可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)。 

 分组优化group by

需要对分组优化,同样需要对需要分组的字段添加索引,走索引进行分组查询效率更高,需要注意的是也需要满足最左前缀法则,尽量使用联合索引

没有索引走临时表,type为ALL走全表扫描效率低

 建立索引后:

 联合索引时不满足最左前缀法则:

有where条件时是满足最左前缀法则的,走索引:

limit优化

在数据量比较大时,如果进行limit分页查询,在查询时,越往后,分页查询效率越低。

优化方式:使用覆盖索引子查询形式进行优化。

 explain   select  *  from tb_sku  t,
(select  id  from  tb_sku  order  by  id limit  2000000,10)  a #将该页数据的id查询,然后对做多表查询
where t.id  =  a.id;

 Mysql不支持 in 后加 limit 关键字

count优化

用法:count(*)、count(主键)、count(字段)、count(数字)

  • count(主 键): InnoDB 引擎会遍历整张表,把每一行的 主键id值都取出来,返回给服务层。 服务层拿到主键后,直接按行进行累加(主键不可能为null)
  • count(字 段) :
    • 没有not null 约束 : InnoDB 引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,服务层判断是否为null,不为null,计数累加。
    • not null 约束:InnoDB 引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,直接按行进行累加。
  • count(1): InnoDB 引擎遍历整张表,但不取值。服务层对于返回的每一行,放一个数字“1” 进去,直接按行进行累加。(可以是其它数字)
  • count(*) :InnoDB引擎并不会把全部字段取出来,而是专门做了优化,不取值,服务层直接 按行进行累加。

综上按效率排列:count(字段) < count(主键 id) < count(1) ≈ count(*),所以尽 量使用 count(*)。

update优化

在执行update更新操作时要根据有索引的字段进行更新:

将城市为成都的都改为四川,若city字段没有创建索引,则InnoDB会对整个表tb_hotel都加锁,即表级锁,若事务还未提交,此时就不能执行该表的其它更新操作

若创建了索引,则会对该行数据添加锁,即行级锁。

update tb_hotel set city = '四川' where city = '成都';

在执行上述的SQL时, 当开启多个事务,发现行锁升级为了表锁。 导致该update语句的性能大大降低。会影响效率。

 所以在执行update更新操作时,尽量使用有索引的字段做为where条件

InnoDB的行锁是针对索引加的锁,不是针对记录加的锁 ,并且该索引不能失效,否则会从行锁 升级为表锁 。

\G :SQL最后加,以键值对一列形式返回

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/875068.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

AIGC高频产品面试题(二)

什么叫大模型&#xff0c;人工智能大模型是什么&#xff1f; 之前&#xff0c;人工智能大多针对特定的场景应用进行训练&#xff0c;生成的模型难以迁移到其他场景&#xff0c;属于“小模型”的范畴。整个训练过程中&#xff0c;不仅手工调参工作量大&#xff0c;还需要给机器“…

[ECCV 2024] [复旦]RECE:扩散模型概念移除,只需3秒即可充分移除风险概念!

本文内容来自公众号粉丝投稿&#xff0c;作者来自复旦大学的视觉与学习实验室(FVL)。研究团队提出了一种可靠、高效的概念移除方法&#xff08;RECE&#xff09;。该方法以解析解的形式&#xff0c;迭代地进行风险概念移除、风险概念嵌入推导&#xff0c;从而确保模型彻底移除风…

【MySQL进阶之路 | 高级篇】优化数据库结构和大表优化

目录结构&#xff1a; 目录 目录结构&#xff1a; 1. 优化数据库结构 1.1 拆分表&#xff1a;冷热数据分离 1.2 增加冗余字段 1.3 优化数据类型 情况1&#xff1a;对整数类型数据进行优化 情况2&#xff1a;既可以使用文本类型也可以使用整数类型的字段&#xff0c;要选…

LeetCode热题100刷题17:124. 二叉树中的最大路径和、437. 路径总和 III、199. 二叉树的右视图

124. 二叉树中的最大路径和 /*** Definition for a binary tree node.* struct TreeNode {* int val;* TreeNode *left;* TreeNode *right;* TreeNode() : val(0), left(nullptr), right(nullptr) {}* TreeNode(int x) : val(x), left(nullptr), right(nul…

Github 2024-07-17 开源项目日报 Top10

根据Github Trendings的统计,今日(2024-07-17统计)共有10个项目上榜。根据开发语言中项目的数量,汇总情况如下: 开发语言项目数量非开发语言项目3Python项目3Rust项目2TypeScript项目2MDX项目1项目化学习 创建周期:2538 天协议类型:MIT LicenseStar数量:161973 个Fork数量…

基于51单片机的指纹红外密码电子锁

基于51单片机的指纹红外密码电子锁 1、系统功能介绍2、演示视频3、系统框图4、系统电路介绍4.1、STC89C52单片机最小系统设计4.2、LCD12864显示屏电路设计4.3、矩阵键盘按键控制部分电路设计4.4、AS608指纹模块电路设计 5、程序设计5.1、LCD12864屏幕初始化5.2、AT24C02存储芯片…

打造直播工具详解:从零开始开发直播美颜SDK

今天&#xff0c;笔者将详细讲解如何从零开始开发一个直播美颜SDK&#xff0c;帮助开发者了解开发过程中的关键环节和技术要点。 一、需求分析与规划 在开发之前&#xff0c;首先需要明确美颜SDK的功能需求。一般来说&#xff0c;美颜SDK应包含以下几个核心&#xff1a; 基础…

【TAROT学习日记】韦特体系塔罗牌学习(7)——恋人 THE LOVERS VI

韦特体系塔罗牌学习&#xff08;7&#xff09;——恋人 THE LOVERS VI 目录 韦特体系塔罗牌学习&#xff08;7&#xff09;——恋人 THE LOVERS VI牌面分析1. 基础信息2. 图片元素 正位牌意1. 关键词/句2.爱情婚姻3. 学业事业4. 人际财富5. 其他象征意 逆位牌意1. 关键词/句2. …

MS17-010漏洞复现+利用

1、 漏洞简述 漏洞名称&#xff1a;“永恒之蓝”漏洞 漏洞编号&#xff1a;MS17-010&#xff0c;CVE-2017-0143/0144/0145/0146/0147/0148 漏洞类型&#xff1a;缓冲区溢出漏洞 漏洞影响&#xff1a;信息泄露 CVSS评分&#xff1a;9.3&#xff08;High&#xff09; 利用难…

食家巷擀面皮:一口惊艳的传统美味

在美食的世界里&#xff0c;总有一些经典让人难以忘怀&#xff0c;食家巷擀面皮便是其中之一。食家巷擀面皮&#xff0c;那一张张薄而有劲道的面皮&#xff0c;宛如艺术品般细腻。它的外观晶莹剔透&#xff0c;散发着诱人的光泽&#xff0c;让人看一眼就忍不住想要品尝。制作擀…

Vue使用FullCalendar实现日历/周历/月历

Vue使用FullCalendar实现日历/周历/月历 需求背景&#xff1a;项目上遇到新需求&#xff0c;要求实现工单以日/周/月历形式展示。而且要求不同工单根据状态显示不同颜色&#xff0c;一个工单内部&#xff0c;需要以不同颜色显示三个阶段。 效果图 日历 周历 月历 安装插件…

MySQL学习——影响选项文件处理的命令行选项

大多数支持选项文件的MySQL程序都处理以下选项。因为这些选项会影响选项文件处理&#xff0c;所以必须在命令行上给出&#xff0c;而不是在选项文件中给出。为了正常工作&#xff0c;这些选项中的每一个都必须在其他选项之前给出&#xff0c;但以下情况除外&#xff1a; 打印默…

力扣第二十五题——K个一组反转链表

内容介绍 给你链表的头节点 head &#xff0c;每 k 个节点一组进行翻转&#xff0c;请你返回修改后的链表。 k 是一个正整数&#xff0c;它的值小于或等于链表的长度。如果节点总数不是 k 的整数倍&#xff0c;那么请将最后剩余的节点保持原有顺序。 你不能只是单纯的改变节点内…

1万6千多传统文化之古代地名大全ACCESS\EXCEL数据库

继续采集传统文化数据&#xff0c;之前采集过《传统文化之非物质文化大全ACCESS数据库》、《名人大全古今人物ACCESS数据库》、《传统文化之民俗文化大全ACCESS数据库》&#xff0c;今天的是古代地名查询&#xff1a; 截图下方有显示“共有记录数”&#xff0c;截图包含了表的所…

IP协议和路由转发

文章目录 IP协议IP报头网段划分特殊的IP私有IP和公有IP IP分片 路由 IP协议 IP协议提供了一种能力&#xff0c;将数据报从A主机送到B主机&#xff0c;TCP可以保证可靠性&#xff0c;所以TCP/IP协议可以将数据可靠的从A主机送到B主机。 IP报头 4位版本号(version): 指定IP协议…

Unity Shader - 2024 工具篇

目录 IDE 工具建议 IDE工具 Sublime 3 大势所趋&#xff0c;但是Sublime 使用插件还是相当的不习惯 代码跳转 Go to definite IDE 工具建议 () what is the best ide for coding shaderlab - #4 by DaveAstator - Unity Engine - Unity Discussions​​​​​​​I IDE工…

修复SteamUI.dll加载失败的指南,快速修复failed to load steamui.dll

在使用Steam平台进行游戏下载、安装和运行时&#xff0c;可能会遇到一些系统错误&#xff0c;比如“failed to load steamui.dll”。这个错误通常意味着Steam的用户界面库文件steamui.dll出现了问题。本文将详细介绍steamui.dll文件的相关信息以及如何修复这一问题。 一.什么是…

邮件安全篇:如何防止邮件泄密?

本文主要讨论组织内部用户违反保密规定通过邮件泄密的场景。其他场景导致邮箱泄密的问题&#xff08;如账号被盗、邮件系统存在安全漏洞等&#xff09;不在本文的讨论范围。本文主要从邮件系架构设计、邮件数据防泄漏系统、建立健全规章制度、安全意识培训等方面分别探讨。 1. …

Java响应式编程库Reactor的介绍和基本使用

关于响应式编程的概念和介绍可以参考: 响应式编程(Reactive Programming)是什么? Java语言中,RxJava和Reactor是实现响应式编程的两个最流行的库,因为 Spring 5 及更高版本中,Reactor 是 Spring WebFlux 的底层实现框架,用于构建响应式 Web 应用,所以相比而言,Reactor…

充电桩浪涌保护方案—保障充电设施安全稳定运行的关键

在当今新能源汽车蓬勃发展的时代&#xff0c;充电桩作为电动汽车的“加油站”&#xff0c;其重要性不言而喻。然而&#xff0c;由于其复杂的电气环境和暴露于户外的特点&#xff0c;充电桩容易受到浪涌的影响。浪涌可能来自雷电、电网故障、大功率设备的启停等&#xff0c;对充…