【MySQL索引特性】

news2024/11/25 11:40:11

目录：

  • 前言
  • 引入
  • 认识磁盘
    • MySQL与存储
  • 索引的理解
    • 理解单个Page
    • 理解多个Page
    • 引入B+树结构
    • 聚簇索引 VS 非聚簇索引
  • 索引操作
    • 创建主键索引
    • 唯一索引的创建
    • 普通索引的创建
    • 查看索引
    • 删除索引
  • 总结

前言

剑指offer：一年又10天

引入

索引，是用来提高查询效率的，下面我们通过一个书本目录和一个实际查询示例来初步认识一下它。

场景1：我想要看条款49的内容。

因为我并不知道条款49在那一页，如果一页一页翻的话需要翻240页（也就是遍历），肯定能找到但是显而易见效率不高（如果条款49在820页呢）

但是如果我们从目录里面找只需要2，3页就可以涵盖全书的内容，因此可以十分快速地确认条款49的位置（240页），这里的目录就是各个条款的索引。

场景2：在八百万个员工中查询编号为778899的员工信息。

-- 构造表结构
mysql> CREATE TABLE  EMP(
    ->    empid  int(6) unsigned zerofill DEFAULT NULL,  -- 员工id
    ->    ename  varchar(20) DEFAULT NULL,              -- 员工姓名
    ->    job  varchar(20) DEFAULT NULL,                -- 工作
    ->    mgr  int(6) unsigned zerofill DEFAULT NULL,   -- 上司
    ->    hiredate  datetime DEFAULT NULL,              -- 入职日期
    ->    sal  float(8,2) DEFAULT NULL,                 -- 工资
    ->    bonus  float(8,2) DEFAULT NULL,               -- 奖金
    ->    deptid  int(11) DEFAULT NULL                  -- 部门id
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.05 sec)


--构建一个8000000条记录的数据
--构建的海量表数据需要有差异性，所以使用存储过程来创建， 拷贝下面代码就可以了，暂时不用理解

-- 产生随机字符串
delimiter $$
create function rand_string(n INT)
returns varchar(255)
begin
declare chars_str varchar(100) default
'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
declare return_str varchar(255) default '';
declare i int default 0;
while i < n do
set return_str =concat(return_str,substring(chars_str,floor(1+rand()*52),1));
set i = i + 1;
end while;
return return_str;
end $$
delimiter ;
--产生随机数字
delimiter $$
create function rand_num()
returns int(5)
begin
declare i int default 0;
set i = floor(10+rand()*500);
return i;
end $$
delimiter ;
--创建存储过程，向雇员表添加海量数据
delimiter $$
create procedure insert_emp(in start int(10),in max_num int(10))
begin
declare i int default 0;
set autocommit = 0;
repeat
set i = i + 1;
insert into EMP values ((start+i)
,rand_string(6),'SALESMAN',0001,curdate(),2000,400,rand_num());
until i = max_num
end repeat;
commit;
end $$
delimiter ;
-- 执行存储过程，添加8000000条记录
call insert_emp(100001, 8000000);
-- 要好长好长时间...（5min）

-- 查看一下记录插入情况，数据量太大，我们只看前十条
mysql> select * from EMP limit 0, 10;
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| empid  | ename  | job      | mgr    | hiredate            | sal     | bonus  | deptid |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| 100002 | NRUZlg | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    504 |
| 100003 | DSDpOb | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    407 |
| 100004 | TbynUK | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    414 |
| 100005 | XrQeXC | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    430 |
| 100006 | EtfxXt | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    508 |
| 100007 | TvvPQI | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    431 |
| 100008 | mIJhSP | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    232 |
| 100009 | QPAjvx | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |     28 |
| 100010 | RdSbDN | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |     48 |
| 100011 | gtAxKh | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    318 |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
10 rows in set (0.00 sec)
-- 查看一下 empid=778899的员工信息， 用时4.8秒
mysql> select * from EMP where empid = 778899;
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| empid  | ename  | job      | mgr    | hiredate            | sal     | bonus  | deptid |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| 778899 | pzEvtJ | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    486 |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
1 row in set (4.80 sec)
-- 再查一次，4.74秒
mysql> select * from EMP where empid = 778899;
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| empid  | ename  | job      | mgr    | hiredate            | sal     | bonus  | deptid |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| 778899 | pzEvtJ | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    486 |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
1 row in set (4.74 sec)


-- 给EMP表添加主键
mysql> alter table EMP add primary key(empid);
Query OK, 0 rows affected (1 min 1.24 sec)
Records: 0  Duplicates: 0  Warnings: 0
-- 再次查找empid = 778899的员工信息，耗时0.00秒（小于1微秒）
mysql> select * from EMP where empid = 778899;
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| empid  | ename  | job      | mgr    | hiredate            | sal     | bonus  | deptid |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| 778899 | pzEvtJ | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    486 |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
1 row in set (0.00 sec)
-- 再找一次，耗时0.00秒
mysql> select * from EMP where empid = 778899;
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| empid  | ename  | job      | mgr    | hiredate            | sal     | bonus  | deptid |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
| 778899 | pzEvtJ | SALESMAN | 000001 | 2023-12-05 00:00:00 | 2000.00 | 400.00 |    486 |
+--------+--------+----------+--------+---------------------+---------+--------+--------+
1 row in set (0.00 sec)

通过测试我们发现，添加了主键后，查找的效率提升了至少1000倍。（主键就是索引的一种）

认识磁盘

MySQL与存储

MySQL是用来存储的，存储的都是数据，而数据都保存在磁盘中，因此当我们需要访问数据时都需要先将数据都磁盘中拷贝到内存，也就是需要访问磁盘，而磁盘是计算机中的外设，属于机械设备，因此访问速度是很慢的，所以为了提高MySQL处理速度，减少磁盘访问次数是很有必要的且有效的。

在往下进行之前我们要先建立一些共识：

  1. 磁盘中最小存储单位为扇区，一个扇区存储大小为512B；
  2. 内存IO的基本单位为块（也可以叫page），一个块存储大小为4KB（从磁盘中读取数据到内存，一次最少读取8个扇区）；
  3. MySQL进行IO的基本单位为page，一个page存储大小为16KB（4块，与内存中的page区分）；

为什么内存最小存储单位不采用扇区，甚至是需要多少数据就读取多少数据？
答：为了减少对磁盘的访问次数，提高访问效率，由于计算机的空间局部性原理（如果一个内存位置被访问，那么它附近的内存位置也有可能在近期内被访问。这通常是由于程序的数据结构和算法导致某些数据项在内存中聚集在一起），因此一次将它周围的数据一起IO到内存，以达到减少磁盘IO次数，提高效率的目的。

而MySQL 作为一款应用软件，可以想象成一种特殊的文件系统。它有着更高的IO场景，所以，为了提高基本的IO效率， MySQL 进行IO的基本单位是 16KB (后面统一使用 InnoDB 存储引擎讲解)。

-- 查看InnoDB存储引擎的page大小
mysql> show global status like'innodb_page_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Innodb_page_size | 16384 | -- 16384 / 1024 = 16
+------------------+-------+
1 row in set (0.05 sec)

共识：

  1. MySQL 中的数据文件，是以page为单位保存在磁盘当中的。
  2. MySQL 的 CURD操作，都需要通过计算，找到对应的插入位置，或者找到对应要修改或者查询的数据。
  3. 而只要涉及计算，就需要CPU参与，而为了便于CPU参与，一定要能够先将数据移动到内存当中。所以在特定时间内，数据一定是磁盘中有，内存中也有。后续操作完内存数据之后，以特定的刷新策略，刷新到磁盘。而这时，就涉及到磁盘和内存的数据交互，也就是IO了。而此时IO的基本单位就是Page。
  4. 为了更好的进行上面的操作， MySQL 服务器在内存中运行的时候，在服务器内部，就申请了被称为 Buffer Pool的的大内存空间，来进行各种缓存。其实就是很大的内存空间，来和磁盘数据进行IO交互。
  5. 为何更高的效率，一定要尽可能的减少系统和磁盘IO的次数。

索引的理解

-- 建立测试表
mysql> create table if not exists user (
    -> id int primary key,   -- 一定要设置id为主键，否则观察不出效果
    -> age int not null,
    -> name varchar(16) not null
    -> );
Query OK, 0 rows affected (0.03 sec)

mysql> show create table user\G
*************************** 1. row ***************************
       Table: user
Create Table: CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  `name` varchar(16) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8  -- 默认存储引擎就是 InnoDB
1 row in set (0.00 sec)


-- 插入测试数据
mysql> insert into user (id, age, name) values(3, 18, '杨过');
Query OK, 1 row affected (0.00 sec)

mysql> insert into user (id, age, name) values(4, 16, '小龙女');
Query OK, 1 row affected (0.00 sec)

mysql> insert into user (id, age, name) values(2, 26, '黄蓉');
Query OK, 1 row affected (0.00 sec)

mysql> insert into user (id, age, name) values(5, 36, '郭靖');
Query OK, 1 row affected (0.00 sec)

mysql> insert into user (id, age, name) values(1, 56, '欧阳锋');
Query OK, 1 row affected (0.00 sec)

mysql> select * from user;
+----+-----+-----------+
| id | age | name      |
+----+-----+-----------+
|  1 |  56 | 欧阳锋    |
|  2 |  26 | 黄蓉      |
|  3 |  18 | 杨过      |
|  4 |  16 | 小龙女    |
|  5 |  36 | 郭靖      |
+----+-----+-----------+
5 rows in set (0.00 sec)

我们插入数据时id是乱序的，但是查看时却发现id按照升序排好了序，是谁排的序？为什么要排序？

理解单个Page

MySQL要管理很多数据表，这些数据表在Linux下的表现就是文件，一个page也需要被OS所管理，通过"先描述再组织"，在OS内维护对应的page结构，一个page16KB，一个文件有个十几二十MB却很正常，也就是说一个张表可以拥有多个page，不同的 Page ，在 MySQL 中，都是 16KB ，使用 prev 和 next 构成双向链表
因为有主键的问题， MySQL 会默认按照主键给我们的数据进行排序，从上面的Page内数据记录可以看出，数据是有序且彼此关联的。

还记得我们最开始举的书本目录的例子吗，为什么通过目录查到条款49的页码为240就可以快速找到条款49，为什么呢？因为我们知道页码小于240的都不是，240一定在它们后面；如果240前面不是239，而是350，240后面不是241而是300，也就是说如果页码是无序的，那么目录也就失去了它快速定位的意义，所以为了能够快速定位，我们需要保证数据的有序性。

上表由于有主键id，mysql服务器在我们插入数据时就根据id的大小进行排序（如何排序的后面再说），方便后序的查找。
有了有序页表（根据id排序），下面就需要一个目录来帮助我们快速定位。

理解多个Page

多个page通过前后指针链接为双向链表。

通过上面的分析，我们知道，上面页模式中，只有一个功能，就是在查询某条数据的时候直接将一整页的数据加载到内存中，以减少硬盘IO次数，从而提高性能。但是，我们也可以看到，现在的页模式内部，实际上是采用了链表的结构，前一条数据指向后一条数据，本质上还是通过数据的逐条比较来取出特定的数据。
如果有1千万条数据，一定需要多个Page来保存1千万条数据，多个Page彼此使用双链表链接起来，而且每个Page内部的数据也是基于链表的。那么，查找特定一条记录，也一定是线性查找。这效率也太低了。

引入B+树结构

在InnoDB中，实际上是使用B+树来维护一个数据表的page结构。

B+树的特点：
1.平衡的多路搜索树；
2.只有叶子节点存储数据，分支节点只存储关键字索引信息；
3.叶子节点通过指针连接为单链表；

根据B+树的特性，我们给page带上索引。

每次访问新的page都需要进行磁盘IO，为了减少磁盘IO的次数，在page的目录中只存储page索引和地址的映射而不存储数据，这样一个page目录页就可以存储更多的page地址，减少查找次数也就减少磁盘IO次数，数据只存储在最下一层的page中。

可是，我们每次检索数据的时候，该从哪里开始呢？虽然顶层的目录页少了，但是还要遍历啊？不用担心，可以再加目录页。

复盘一下：

  1. Page分为目录页和数据页。目录页只放各个下级Page的最小键值；
  2. 查找的时候，自顶向下找，只需要加载部分目录页到内存，即可完成算法的整个查找过程，大大减少了IO次数；
  3. B+树的叶子节点连接为单链表而InnoDB中使用双链表（方便快速找到临近节点的数据）；
  4. 上面的两个图的第二层不一样但是并没有画错，倒数第一个由于有Page目录因此可以通过目录找到需要的Page，倒数第二个则需要遍历Page来查找，因此需要互相连接（倒数第二个属于推导的中间过程图，实际不存在，不用关注）。

为什么采用B+树而不是数组、红黑树以及B树和hash表呢？
数组、链表等不用说；
红黑树到底还是二叉树，当数据量很大时这棵红黑树是又高又细的，那么在查找时就需要查找更多的page目录，因此效率并不高；
B树则是中间节点也存储数据，那么中间节点存储的目录索引就变少，查找过程中遍历的page目录就变多了，没有B+树效率高；
hash表也有其优势，MySQL中也提供了hash表结构只是InnoDB没有采用，感兴趣的朋友可以之后自行了解。

这里的BTREE是B+树

聚簇索引 VS 非聚簇索引

MyISAM存储引擎同样使用B+树作为索引结果，叶节点的data域存放的是数据记录的地址，下图为MyISAM表的主索引，col1为主键。

其中MyISAM最大的特点是，将索引Page和数据Page分离，也就是叶子结点没有数据，只有对应数据的地址。
相较于InnoDB索引，InnoDB是将索引和数据放在一起的。

 -- 创建测试表 mtest
mysql> create table mtest(
    ->  id int primary key,
    -> name varchar(11) not null
    -> )engine=MyISAM;             -- 使用MyISAM存储引擎
Query OK, 0 rows affected (0.01 sec)

在这里插入图片描述
.frm文件是所有存储引擎都有的，用来存储表结构；
.MYD文件和.MYI文件是MyISAM存储引擎独有的，D就是data，用来存储数据，I就是index，用来存储索引。

其中，MyISAM这种用户数据与索引数据分离的索引方案，叫做非聚簇索引。

-- 创建测试表 itest
mysql> create table itest(
    -> id int primary key,
    -> name varchar(11) not null
    -> )engine=InnoDB;             -- 使用InnoDB存储引擎
Query OK, 0 rows affected (0.03 sec)

在这里插入图片描述
.ibd文件是InnoDB存储引擎独有的，存储表的索引和数据。

其中，InnoDB这种用户数据与索引数据放在一起的索引方案，叫做聚簇索引。

当然，MySQL除了默认会建立主键索引（默认建立的我们无法直接使用）外，我们用户也有可能建立按照其他列信息建立的索引，一般这种索引可以叫做辅助（普通）索引。 对于MyISAM，建立辅助（普通）索引和主键索引没有差别，无非就是主键不能重复，而非主键可重复。

下图就是基于 MyISAM 的 Col2 建立的索引，和主键索引没有差别：

同样， InnoDB 除了主键索引，用户也会建立辅助（普通）索引，我们以上表中的 Col3 建立对应的辅助索引如下图：

可以看到， InnoDB 的非主键索引中叶子节点并没有数据，而只有对应记录的key值。
所以通过辅助（普通）索引，找到目标记录，需要两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。这种过程，就叫做回表查询。
为何 InnoDB 针对这种辅助（普通）索引的场景，不给叶子节点也附上数据呢？原因就是太浪费空间了。

什么是默认主键索引？为何MySQL要默认建立主键索引？
当MySQL在创建表时，如果没有明确声明主键，系统会自动创建一个名为"PRIMARY"的默认主键索引。这个索引不是给用户直接使用的，而是创建普通索引时作为普通索引回表查询时的主键；如果用户声明了 primary key，MySQL就不会创建默认主键索引。

总结：

  • InnoDB 主键索引和普通索引
  • MyISAM 主键索引和普通索引
  • 其他数据结构为何不能作为索引结构，尤其是B+和B
  • 聚簇索引 VS 非聚簇索引

索引操作

创建主键索引

方法一：

-- 在创建表的时候，直接在字段名后指定 primary key
create table p_tb1(id int primary key, name varchar(20));

方法二：

-- 在创建表的最后，指定某列或某几列为主键索引
create table p_tb2(id int, name varchar(20), primary key(id));

方法三：

create table p_tb3(id int, name varchar(20));
-- 创建表以后再添加主键
alter table p_tb3 add primary key(id);

主键索引的特点：

  1. 一个表中，最多有一个主键索引，当然可以使复合主键；
  2. 主键索引的效率高（主键不可重复）；
  3. 创建主键索引的列，它的值不能为null，且不能重复；
  4. 主键索引的列基本都是int。

唯一索引的创建

方法一：

-- 在创建表的时候，直接在字段名后指定 unique key
create table u_tb1(id int unique key, name varchar(20));

方法二：

-- 在创建表的最后，指定某列或某几列为唯一键索引
create table u_tb2(id int, name varchar(20), unique key(id));

方法三：

create table u_tb3(id int, name varchar(20));
-- 创建表以后再添加唯一键
alter table u_tb3 add unique key(id);

唯一索引的特点：

  1. 一个表中，可以有多个唯一索引；
  2. 查询效率高；
  3. 如果在某一列建立唯一索引，必须保证这列不能有重复数据；
  4. 如果一个唯一索引上指定not null，等价于主键索引。

普通索引的创建

方法一：

-- 在创建表的最后指定某列或某几列为索引
create table i_tb1(id int, name varchar(20), index(id));

方法二：

create table i_tb2(id int, name varchar(20));
-- 创建表以后再添加索引
alter table i_tb2 add index(id);

方法三：

create table i_tb3(id int, name varchar(20));
-- 创建一个索引名为 idx_id 的索引
create index idx_id on i_tb3(id);

普通索引的特点：

  1. 一个表中可以有多个普通索引，普通索引在实际开发中用的比较多；
  2. 如果某列需要创建索引，但是该列有重复的值，那么我们就应该使用普通索引。

查看索引

方法一：

SHOW KEYS FROM table_name;

mysql> show keys from p_tb1\G
*************************** 1. row ***************************
        Table: p_tb1         --  表名
   Non_unique: 0
     Key_name: PRIMARY       -- 索引名
 Seq_in_index: 1             -- 主键在索引中的位置（复合索引中，越小越先比较）
  Column_name: id            -- 列名，索引所在的列
    Collation: A
  Cardinality: 0
     Sub_part: NULL
       Packed: NULL
         Null: 
   Index_type: BTREE        -- 索引类型：B+树
      Comment: 
Index_comment: 
1 row in set (0.03 sec)

方法二：

SHOW INDEX FROM table_name;  -- 结果同方法一一样

方法三：

DESC table_name; -- 只能简单查看索引信息

mysql> desc p_tb1;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | NO   | PRI | NULL    |       |  -- 主键索引
| name  | varchar(20) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> desc i_tb1;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | YES  | MUL | NULL    |       | -- 普通索引
| name  | varchar(20) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

删除索引

方法一：

alter table p_tb1 drop primary key;   -- 由于主键索引只有一个，因此不需要特意指明

方法二：

-- 删除普通索引
ALTER TABLE table_name DROP INDEX index_name;

mysql> show keys from u_tb1\G
*************************** 1. row ***************************
        Table: u_tb1
   Non_unique: 0
     Key_name: id      -- 查看索引名为 id
	   ...
	   ...


alter table u_tb1 drop index id;  -- 唯一键索引也是普通索引

方法三：

DROP INDEX index_name on table_name;

mysql> show keys from i_tb1\G
*************************** 1. row ***************************
        Table: i_tb1
   Non_unique: 1
     Key_name: id  -- 索引名为 id
		...
		...

drop index id on i_tb1;

索引创建原则

  • 比较频繁作为查询条件的字段应该创建索引
  • 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件
  • 更新非常频繁的字段不适合作创建索引
  • 不会出现在where子句中的字段不该创建索引

总结

一个索引对应一个B+树，一张表可以有多个索引就可以有多个B+树；
如果一张表没有主键，mysqld也会使用默认自增长主键创建B+树，目的是方便之后普通索引的建立。

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【python】python课设 天气预测数据分析及可视化(完整源码）

【python】python课设 天气预测数据分析及可视化(完整源码）

目录 1. 前言2. 项目结构3. 详细介绍3.1 main.py3.2 GetModel.py3.3 GetData.py3.4 ProcessData.py3.5天气网.html 4. 成果展示 1. 前言 本文介绍了天气预测数据分析及可视化的实现过程使用joblib导入模型和自定义模块GetModel获取模型&#xff0c;输出模型的MAE。使用pyechart…
阅读更多...
ansible的控制语句

ansible的控制语句

本章内容主要介绍 playbook 中的控制语句 使用when判断语句block-rescue判断循环语句 一个play中可以包含多个task&#xff0c;如果不想所有的task全部执行&#xff0c;可以设置只有满足某个条件才执行这个task&#xff0c;不满足条件则不执行此task。本章主要讲解when 和 blo…
阅读更多...
Linux安装及管理程序

Linux安装及管理程序

一、Linux应用程序管理 1、应用程序与系统命令的关系 1.对比系统命令和应用程序的不同 位置&#xff1a; Linux中一切皆为文件 演示内部命令和外部命令 位置 应用程序位置 用途&#xff1a; 命令主要处理系统的基本操作&#xff08;复制&#xff0c;配置&#xff09; 应用程…
阅读更多...
大模型工具_Langchain-Chatchat

大模型工具_Langchain-Chatchat

https://github.com/chatchat-space/Langchain-Chatchat 原Langchain-ChatGLM 1 功能 整体功能&#xff0c;想解决什么问题 基于 Langchain 与 ChatGLM 等LLM模型&#xff0c;搭建一套针对中文场景与开源模型&#xff0c;界面友好、可离线运行的知识库问答解决方案。 当前解决…
阅读更多...
米勒电容与米勒效应

米勒电容与米勒效应

米勒电容与米勒效应 米勒效应米勒效应的形成原理及分析米勒效应的危害和改进 米勒效应 Ciss CGE CGC 输入电容 Coss CGC CEC 输出电容 Crss CGC 米勒电容 下面我们以MOS中的米勒效应来展开说明&#xff1a; 米勒效应在MOS驱动中臭名昭著&#xff0c;它是由MOS管的米勒电容引发…
阅读更多...
运行时和编译时使用的so库不同是否影响可执行文件执行

运行时和编译时使用的so库不同是否影响可执行文件执行

引子 近日遇到如下问题: 1.如果可执行文件依赖的so库在编译和执行阶段使用的名字一样&#xff0c;但是内容不一样&#xff0c;比如运行时相比于编译时在so库里增加了几个api定义&#xff0c;so库还可以正常使用吗&#xff1f; 2.如果可执行文件依赖的so库在编译和执行阶段使用的…
阅读更多...
buuctf-Misc 题目解答分解94-96

buuctf-Misc 题目解答分解94-96

94.[SUCTF 2019]Game 在源码包里面 有一个静态页面和一些样式表 在index,html 中看到了flag base32 解码 得到flag suctf{hAHaha_Fak3_F1ag} 但是显示不对 还有一张图片 进行数据提取发现base64 U2FsdGVkX1zHjSBeYPtWQVSwXzcVFZLu6Qm0To/KeuHg8vKAxFrVQ 解密后发现是Sal…
阅读更多...
编译原理--词法分析C++

编译原理--词法分析C++

一、实验项目要求 1.实验目的 通过设计编制调试一个具体的词法分析程序&#xff0c;加深对词法分析原理的理解。并掌握在对程序设计语言源程序进行扫描过程中将其分解为各类单词的词法分析方法。 编制一个读单词过程&#xff0c;从输入的源程序中&#xff0c;识别出各个具有…
阅读更多...
XUbuntu22.04之跨平台容器格式工具:MKVToolNix(二百零三)

XUbuntu22.04之跨平台容器格式工具:MKVToolNix(二百零三)

简介&#xff1a; CSDN博客专家&#xff0c;专注Android/Linux系统&#xff0c;分享多mic语音方案、音视频、编解码等技术&#xff0c;与大家一起成长&#xff01; 优质专栏&#xff1a;Audio工程师进阶系列【原创干货持续更新中……】&#x1f680; 优质专栏&#xff1a;多媒…
阅读更多...
29.Java程序设计-基于Springboot的幼儿园管理系统的设计与实现

29.Java程序设计-基于Springboot的幼儿园管理系统的设计与实现

1. 引言 背景介绍&#xff1a;幼儿园管理系统的必要性和重要性。研究目的&#xff1a;设计一个基于Spring Boot的系统以优化幼儿园管理流程。论文结构概览。 2. 需求分析 用户需求&#xff1a;不同用户&#xff08;管理员、老师、家长&#xff09;的需求分析。功能需求&…
阅读更多...
多次触发FastJson漏洞的AutoType机制，你了解吗？

多次触发FastJson漏洞的AutoType机制，你了解吗？

一个反序列化问题 在一次日志巡检过程中&#xff0c;发现线上业务出现报错。线上业务场景是&#xff1a;调用三方restful接口&#xff0c;根据接口返回json字符串内容&#xff0c;进行反序列化处理&#xff0c;业务中使用的json处理工具是FastJson(v1.2.71)。 报错是使用fast…
阅读更多...
【Linux系统编程二十三】：(信号2)--信号的保存

【Linux系统编程二十三】：(信号2)--信号的保存

【Linux系统编程二十三】&#xff1a;信号的保存 一.信号的保存1.阻塞信号2.sigset_t类型(位图)3.block表4.handler表5.pending表 二.实验验证三.信号的其他概念 一.信号的保存 信号发送本质上是操作系统发送信号&#xff0c;而进程PCB内部有一个位图用来表示是否接收到信号。…
阅读更多...
T-Dongle-S3开发笔记——创建工程

T-Dongle-S3开发笔记——创建工程

创建Hello world工程 打开命令面板 方法1&#xff1a;查看->命令面板 方法2&#xff1a;按F1 选择ESP-IDF:展示示例项目 创建helloworld 选择串口 选择芯片 至此可以编译下载运行了 运行后打印的信息显示flash只有2M。但是板子上电flash是W25Q32 4MB的吗 16M-bit
阅读更多...
高级RGA(二)：父文档检索器

高级RGA(二)：父文档检索器

在我之前写的<<使用langchain与你自己的数据对话>>系列博客中&#xff0c;我们介绍了利用大型语言模型LLM来检索文档时的过程和步骤&#xff0c;如下图所示&#xff1a; 我们在检索文档之前&#xff0c;通常需要对文档进行切割&#xff0c;然后将其存入向量数据库如…
阅读更多...
用友时空KSOA UploadImage任意文件上传漏洞

用友时空KSOA UploadImage任意文件上传漏洞

漏洞描述 用友时空 KSOA 是根据流通企业前沿的IT需求推出的统的IT基础架构&#xff0c;它可以让流通企业各个时期建立的 IT 系统之间彼此轻松对话。由于用友时空设备开放了文件上传功能&#xff0c;但未鉴权且上传的文件类型、大小、格式、路径等方面进行严格的限制和过滤&…
阅读更多...
企业知识库在跨地域团队协作中的价值

企业知识库在跨地域团队协作中的价值

随着全球化进程的不断加速&#xff0c;越来越多的企业开始面临跨地域协作的挑战。在这种背景下&#xff0c;企业知识库作为一种重要的知识管理工具&#xff0c;对于提高团队协作效率、促进知识共享与创新具有不可替代的价值。接下来就说一下知识库在跨地域团队协作中的重要性及…
阅读更多...
JVM简单学习

JVM简单学习

jvm与字节码 jvm只需关注字节码文件 jvm由哪些部分构成 1.类加载子系统&#xff0c;将磁盘中的字节码文件加载到方法区的内存空间中 类加载器分两种&#xff1a;引导类加载器是jvm底层中用C和C语言写的 各个默认的类加载器的不同区别在于 各自默认负责要加载的类的目录不一…
阅读更多...
web前端游戏项目-辨色大比拼【附源码】

web前端游戏项目-辨色大比拼【附源码】

web前端游戏项目-辨色大比拼【附源码】 《辨色大比拼》是一个旨在测试和提升玩家颜色识别能力的在线游戏。在游戏中&#xff0c;玩家将通过辨识颜色来解谜并推进游戏进程。辨色大比拼也是一个寓教于乐的游戏&#xff0c;它不仅提供了一个有趣的辨色挑战&#xff0c;还能帮助玩…
阅读更多...
通过 Higress Wasm 插件 3 倍性能实现 Spring-cloud-gateway 功能

通过 Higress Wasm 插件 3 倍性能实现 Spring-cloud-gateway 功能

作者&#xff1a;韦鑫&#xff0c;Higress Committer&#xff0c;来自南京航空航天大学分布式系统实验室 导读&#xff1a;本文将和大家一同回顾 Spring Cloud Gateway 是如何满足 HTTP 请求/响应转换需求场景的&#xff0c;并为大家介绍在这种场景下使用 Higress 云原生网关的…
阅读更多...
【Linux】Linux常见指令解析上

【Linux】Linux常见指令解析上

目录 1. 前言2. ls指令3. pwd指令4. cd指令3.1 cd常见快捷指令 4. touch指令5. mkdir指令6. rmdir指令 && rm指令 &#xff08;重要&#xff09;6.1 rmdir指令6.2 rm指令 7. man指令 1. 前言 这篇文章我们将详细介绍一下Linux下常见的基本指令。 2. ls指令 语法: ls [选…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023