MySQL6：索引使用原则，联合索引，联合主键/复合主键，覆盖索引、什么是回表？索引条件下推，索引的创建与使用，索引的创建与使用，索引失效

news2024/10/6 18:29:59

MySQL6：索引使用原则，联合索引，联合主键/复合主键，覆盖索引、什么是回表？索引条件下推，索引的创建与使用，索引的创建与使用，索引失效

  • 索引使用原则
    • 列的离散(sdn)度
  • 联合索引
    • 创建联合索引
    • 联合索引最左匹配
      • 建立联合索引之后，联合索引的最左字段还要再建普通索引吗？
    • 联合索引使用场景
    • 什么时候能用到联合索引
  • 联合主键/复合主键
  • 覆盖索引
    • 什么是回表？
    • 什么是覆盖索引？
    • 如何判断是覆盖索引
  • 索引条件下推(Index Condition Pushdown)
    • 判断使用索引条件下推
  • 索引的创建与使用
    • 索引的创建
  • 索引失效
  • MySQL合集

索引使用原则

我们容易有以一个误区，就是在经常使用的查询条件上都建立索引，索引越多越好，那到底是不是这样呢?
并不是越多越好，索引好占用磁盘空间的，你的表200M，你的索引可能就是4G，如果搞很多索引，磁盘空间浪费会很大，因此只在必要的字段上建立索引。那么什么样的字段适合建立索引呢，一般选择列的离散度高的列建立索引。

列的离散(sdn)度

列的离散度的公式：

## 列的全部不同值和所有数据行的比例
SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;

数据行数相同的情况下，分子越大，列的离散度就越高。简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。

如果在B+Tree里面的重复值太多(比如性别建立索引)，MySQL的优化器发现走索引跟使用全表扫描差不了多少的时候，就算建了索引，也不一定会走索引。

联合索引

前面我们说的都是针对单列创建的索引，但有的时候我们的多条件査询的时候，也会建立联合索引。单列索引可以看成是特殊的联合索引。

创建联合索引

CREATE TABLE `stu_innodb` (
	`id` INT(11) NOT NULL,
	`name` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`sex` INT(11) NULL DEFAULT NULL,
	`age` INT(11) NULL DEFAULT NULL,
	`card_id` VARCHAR(10) NOT NULL COLLATE 'utf8mb4_unicode_ci'
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
;

比如我们在stu_innodb表上面，给card_id和name建立了一个联合索引。

## 删除索引
ALTER TABLE stu_innodb DROP INDEX idx_cardid_name;
## 创建联合索引
ALTER TABLE stu_innodb ADD INDEX idx_cardid_name (card_id,name);
## 查看索引
show index from stu_innodb;

在这里插入图片描述

联合索引最左匹配

联合索引在B+Tree中是复合的数据结构，它是按照索引的顺序从左到右的顺序来建立搜索树的，比如联合索引idx_cardid_name (card_id,name)就是card_id在左边，name在右边。
在这里插入图片描述
如图，card_id是有序的，name是无序的。当card_id相等的时候， name才是有序的。

这个时候我们使用where card_id='stu006' and name='Blue'去査询数据的时候，B+Tree会优先比较card_id来确定下一步应该搜索的方向，往左还是往右。如果card_id相同的时候再比较name，但是如果查询条件没有card_id，就不知道第一步应该查哪个节点，因为建立搜索树的时候card_id是第一个比较因子，所以用不到索引。

建立联合索引之后，联合索引的最左字段还要再建普通索引吗？

CREATE INDEX idx_cardid on user_innodb(card_id);
CREATE INDEX idx_cardid_name on user_innodb(card_id,name);

当我们创建一个联合索引的时候，按照最左匹配原则，用左边的字段card_id去査询的时候，也能用到索引，所以第一个索引完全没必要。因为联合索引(card_id,name)相当于建立了两个索引(card_id)，(card_id,name)。

如果我们创建三个字段的索引index(a,b,c)，相当于创建三个索引：

  • index(a)
  • index(a,b)
  • index(a,b,c)

同理根据最左原则：

  • where a=?：可以
  • where a=? and b=?：可以
  • where a=? and b=? and c=?：可以
  • where a=? and c=?：可以用到a的索引，不可以用到c的，因为中断(跳过)b
  • where b=?：不可以
  • where b=? and c=?：不可以

在不含最左的a的where条件中，是不能使用到联合索引的，且中断(跳过)不能使用到联合索引的。

联合索引使用场景

根据联合索引的特性，什么时候会用到联合索引呢？
那肯定是查询条件覆盖了联合索引的列。
比如查询高考成绩，必须输入考生姓名和学生的身份证号，那么这种场景，就可以对二者建立联合索引。

什么时候能用到联合索引

  • 顺序使用两个字段，用到联合索引： 
    • ## 顺序使用两个字段，用到联合索引：
explain select * from stu_innodb where card_id='stu006' and name='Blue';
      在这里插入图片描述
  • 乱序使两个字段，用到联合索引(查询优化器的功劳)： 
    • ## 乱序使两个字段，用到联合索引：
explain select * from stu_innodb where name='Blue' and card_id='stu006';
      在这里插入图片描述
  • 使用左边的索引字段，用到联合索引： 
    • ## 使用左边的索引字段，用到联合索引：
explain select * from stu_innodb where card_id='stu006';
      在这里插入图片描述
  • 不使用左边的索引字段，无法使用索引，全表扫描： 
    • ## 不使用左边的索引字段，无法使用索引，全表扫描：
explain select * from stu_innodb where name='Blue';
      在这里插入图片描述
      所以，我们在建立联合索引的时候，一定要把最常用的列放在最左边，查询条件必须由第一个索引字段开始，不能中断(跳过)。

联合主键/复合主键

主键有唯一的约束。当多个字段组合成唯一标识的时候，创建复合主键。
比如一个学生表中，学生卡号、姓名、学院是一条记录的唯一标识，那么就可以建立复合主键，通过定义复合主键，减少了表的数量，不是一个college(学院)一张表。

CREATE TABLE `stu_innodb` (
	`name` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`sex` INT(11) NULL DEFAULT NULL,
	`age` INT(11) NULL DEFAULT NULL,
	`card_id` VARCHAR(10) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`college` VARCHAR(10) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	PRIMARY KEY (`card_id`, `name`, `college`) USING BTREE
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
;

复合主键的特点：

  1. 因为复合主键需要存储多个字段的值，相对于单列主键来说要消耗更多的存储空间
  2. 联合主键包含多个列的时候，不允许所有的字段都相同。因为判断是否重复更复杂(代码中重写hashCode和equals也是)
    • 举例：一张表有a、b、c三个字段，不允许a、b、c三个字段的值都相同，可以有部分的值都相同，例如
      • record1：1 2 3
      • record1：2 3 4
      • record1：1 1 3
      • record1：1 1 3 不允许
  3. 表结构修改或者数据迁移会更加困难
  4. 如果目的是限制唯一性，可以直接拼接两个字段的内容，比如CAIJING1001，CHUANMEI1001，或者用唯一索引UNIQUE KEY也可以实现
  5. 如果目的不是为了限制唯一性，或者有其它检查唯一性的方法，用自增ID之类的无业务意义的字段作为主键更合适。自增ID在插入数据时，引起的页分裂和合并更少

MBG(MyBatis Generator，MBG 在配置中为每个表简单的CRUD操作生成 SQL)对复合主键，会生成两个实体类

覆盖索引

什么是回表？

回表：非主键索引，我们先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。

当我们用name索引查询一条记录，它会在二级索引的叶子节点找到name=Susan，拿到主键值，也就是id = 3，然后再到主键索引的叶子节点拿到数据。
在这里插入图片描述

什么是覆盖索引？

覆盖索引：在二级索引里面，不管是单列索引还是联合索引，如果select的数据列只用从索引中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索索引，这样就避免了回表。。比如上图select name from tbl_xxx where name=? ，因为二级索引的叶子节点上就已经存储了name的数据，因此不需要回表，性能就会高点。

如何判断是覆盖索引

覆盖索引并不是索引的一种类型，而是使用索引产生的一种情况。Explain中的Extra列里面值为'Using index'代表属于覆盖索引的情况。

在联合索引idx_cardid_name (card_id,name)中

这三个查询语句属于覆盖索引：

  • ①使用联合索引②select的所有列已经包含在了用到的索引中： 
    •   explain select name,card_id from stu_innodb where card_id='stu006' and name='Blue';
      属于覆盖索引在这里插入图片描述
  • ①使用联合索引②select的所有列已经包含在了用到的索引中： 
    •   explain select name from stu_innodb where card_id='stu006';
      用到了索引，属于覆盖索引，因为联合索引的创建，使得当前的B+Tree存储了card_id,name的数据，因此不需要回表
      在这里插入图片描述
  • ①不使用联合索引②select的所有列已经包含在了用到的索引中： 
    •   explain select name from stu_innodb where name='Blue';
      还是用到了索引，并且属于覆盖索引，查询优化器优化了，优化器觉得用索引更快，所以还是用到了索引在这里插入图片描述

覆盖索引减少了I/O次数，减少了数据的访问量，可以大大地提升查询效率。

索引条件下推(Index Condition Pushdown)

MySQL架构是分层的，可以分为连接层、服务层、存储引擎层。
不同的索引是在存储引擎层中实现的。如果where条件包含索引，那么是可以在存储引擎层完成数据过滤的。如果用不到索引过滤数据，就需要去Server层。那么如何优化呢？
如果返回了一大堆数据都不是就客户端需要的，那么能不能把这个过滤的动作先在存储引擎层做完，即使查询条件用不到索引，也先在存储引擎中过滤一遍，这个动作，就叫做索引条件下推。

索引条件下推(Index Condition Pushdown)，5.6以后完善的功能，不需要我们开启，是InnoDB自动开启，自动优化的。只适用于二级索引。ICP的目标是减少访问表的完整行的读数量从而减少I/O操作。这里说的下推，其实是意思是把过滤的动作在存储引擎做完，而不需要到Server层过滤，把原来存储引擎无法使用的过滤条件，还是先让他在存储引擎中先过滤。

我们建个表来深入理解一下，idx_college_cardid作为二级联合索引

-- 导出  表 test.stu_innodb 结构
-- 导出  表 test.stu_innodb 结构
CREATE TABLE IF NOT EXISTS `stu_innodb` (
  `id` int(11) NOT NULL,
  `name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,
  `sex` int(11) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `card_id` varchar(10) COLLATE utf8mb4_unicode_ci NOT NULL,
  `college` varchar(10) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_college_cardid` (`college`,`card_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 正在导出表  test.stu_innodb 的数据：~12 rows (大约)
INSERT INTO `stu_innodb` (`id`, `name`, `sex`, `age`, `card_id`, `college`) VALUES
	(2, 'Tom', 1, 23, 'stu001', '财经'),
	(4, 'Bill', 1, 30, 'stu002', '财经'),
	(5, 'Susan', 0, 27, 'stu003', '财经'),
	(6, 'Marry', 0, 28, 'stu004', '财经'),
	(7, 'Sky', 1, 19, 'stu005', '财经'),
	(8, 'Blue', 1, 22, 'stu006', '财经'),
	(12, 'Tom', 1, 23, 'stu001', '金融'),
	(14, 'Bill', 1, 30, 'stu002', '金融'),
	(15, 'Susan', 0, 27, 'stu003', '金融'),
	(16, 'Marry', 0, 28, 'stu004', '金融'),
	(17, 'Sky', 1, 19, 'stu005', '金融'),
	(18, 'Blue', 1, 22, 'stu006', '金融');

在这里插入图片描述
当我们执行SQL语句SELECT * FROM stu_innodb where college='金融' AND card_id LIKE '%stu002';，正常情况来说(也就是不适用索引条件下推的情况)，因为字符是从左往右排序的，当你把％加在前面的时候，是不能基于索引去比较的，所以只有college这个字段能够用于索引比较和过滤。

按有没有使用索引条件下推，查询过程分为两种情况：
在这里插入图片描述

  • 没有索引下推，查询过程是这样的：

    • ① 根据联合索引查出所有college='金融'的二级索引数据，在其叶子节点上得到对应的主键索引值(12，14，15，16，17，18)
    • ② 回表，到主键索引上查询全部复合条件的数据，6条数据
    • ③ 把这6条数据返回给Server层，在Server层对这6条数据，进行符合card_id LIKE '%stu002'条件的过滤

    注意：索引的比较是在存储引擎层进行的，数据记录的比较，是在Server层进行的。而当card_id LIKE '%stu002'条件不能用于索引过滤时，Server层不会把card_id LIKE '%stu002'条件传递给存储引擎，所以读取很多条没有必要的记录(Server层并不需要)。
    这时候，如果满足college='金融'的记录有10万条，就会有99999条没有必要读取的记录，而且都还要返回给Server层。所以，根据college字段过滤的动作，能不能在存储引擎层完成呢？就是下面的查询方法。

  • 使用索引下推，查询过程是这样的：

    • ① 根据联合索引查出所有college='金融'的二级索引数据，在其叶子节点上得到对应的主键索引值(12，14，15，16，17，18)
    • ② 然后从二级索引中筛选出card_id LIKE '%stu002'条件的索引，这下就只有一个了，(14)
    • ③ 回表，到逐渐索引上查询全部符合条件的数据(1条数据)，返回Server层

    先用college='金融'条件进行二级索引范围扫描，读取数据表记录；然后进行比较，检查是否符合card_id LIKE '%stu002'的条件。此时6条中只有1条符合条件。

判断使用索引条件下推

Extra是Using index condition就代表使用索引条件下推，全称其实就是Using index condition push down。

查询是否开启索引条件下推

show variables LIKE 'optimizer_switch';

可以看到，index_condition_pushdown=on，InnoDB中，默认开启索引条件下推

index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,duplicateweedout=on,subquery_materialization_cost_based=on,use_index_extensions=on,condition_fanout_filter=on,derived_merge=on

我们先把索引条件下推关闭

set optimizer_switch='index_condition_pushdown=off';

关闭之后，查看SQL执行计划，会发现Extra是Using where

explain SELECT * FROM stu_innodb where college='金融' AND card_id LIKE '%stu002';

在这里插入图片描述
Extra返回Using where，表示存储引擎返回的数据不全是Server层需要的，需要在Server层再做过滤

启用索引条件下推之后，再次查看SQL执行计划

set optimizer_switch='index_condition_pushdown=on';
explain SELECT * FROM stu_innodb where college='金融' AND card_id LIKE '%stu002';

会发现Extra变成了Using index condition，全称其实就是Using index condition push down。
在这里插入图片描述

索引的创建与使用

因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索弓I。

索引的创建

  1. 在用于where判断order排序和join的(on)、group by的字段上创建索引。

  2. 索引的个数不要过多。——浪费空间，更新变慢。

  3. 过长的字段，但是匹配只需要前面的内容(具体是几个字符在建立索引时指定)，建立前缀索引。

    alter table 表名 add index 索引名(列名(长度));

    注意：在前缀索引中B+Tree里保存的就不是完整的该字段的值，必须要回表才能拿到需要的数据。所以，用了前缀索引，就用不了覆盖索引了。

  4. 区分度低的字段，例如性别，不要建索引。——离散度太低，导致扫描行数过多。

  5. 频繁更新的值，不要作为主键或者索引。——造成页分裂和合并，引起B+Tree的结构调整，会浪费很大的性能

  6. 随机无序的值，不建议作为索引(例如身份证、UUID)。——无序，分裂

  7. 联合索引把散列性高(区分度高)的值放在前面。

  8. 创建复合索引，而不是修改单列索引。

索引失效

-- 导出  表 test.stu_innodb 结构
CREATE TABLE IF NOT EXISTS `stu_innodb` (
  `id` int(11) NOT NULL,
  `name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,
  `sex` int(11) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `card_id` varchar(10) COLLATE utf8mb4_unicode_ci NOT NULL,
  `college` varchar(10) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`card_id`,`name`,`college`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 正在导出表  test.stu_innodb 的数据：~6 rows (大约)
INSERT INTO `stu_innodb` (`id`, `name`, `sex`, `age`, `card_id`, `college`) VALUES
	(2, 'Tom', 1, 23, 'stu001', ''),
	(4, 'Bill', 1, 30, 'stu002', ''),
	(5, 'Susan', 0, 27, 'stu003', ''),
	(6, 'Marry', 0, 28, 'stu004', ''),
	(7, 'Sky', 1, 19, 'stu005', ''),
	(8, 'Blue', 1, 22, 'stu006', '');

在这里插入图片描述
以这个表为例，建立了复合主键
在这里插入图片描述

  1. 索引列上使用函数(replace\SUBSTR\CONCAT\sum count avg)、表达式计算('+'、'-'、'×'、'÷')。因为会得到一个不确定的结果，所以无法使用索引，宁愿计算出它的结果放在表达式的右边，都比函数计算要好

    explain SELECT * FROM stu_innodb where id+1 = 4;

    在这里插入图片描述

  2. 字符串不加引号，出现隐式转换

    explain SELECT * FROM stu_innodb where card_id = 11;

    在这里插入图片描述

  3. 索引的最左前缀原则，like条件中前面带％。where条件中LIKE '%001%'、LIKE '001%'、'%001'都用不到索引，为什么?

    explain SELECT * FROM stu_innodb where card_id LIKE '%001%';
explain SELECT * FROM stu_innodb where card_id LIKE '001%';
explain SELECT * FROM stu_innodb where card_id LIKE '%001';

    在这里插入图片描述
    过滤的开销太大。这个时候可以用全文索引。

  4. 负向查询：

    • NOT LIKE不能:
      explain SELECT * FROM stu_innodb where card_id NOT LIKE '001%';
      在这里插入图片描述
    • <>和NOT IN在某些情况下可以:
      explain SELECT * FROM stu_innodb where card_id <> 'stu001';
      在这里插入图片描述
      explain SELECT * FROM stu_innodb where card_id NOT LIKE '001%';
      在这里插入图片描述

其实，InnoDB到底用不用索引，最终都是优化器说了算。

优化器是基于什么的优化器？
基于cost开销(Cost Base Optimizer)，也叫基于成本的优化器，成本包括两方面，I/O，CPU。它不是基于规则(Rule-Based Optimizer)的优化器，也不是基于语义。怎么样开销小就怎么来。

比如你回家的路线有三条，那么两个优化器会怎么做：

  • 基于规则(Rule-Based Optimizer)的优化器：每次固定选择A路线
  • 基于成本(Cost Base Optimizer)的优化器：会看当前哪条路到家最快(基于成本考虑)，然后选择一条最合适的路线

也就是说，使用索引有基本原则，但是没有具体细则，没有什么情况一定用索引，什么情况一定不用索引的规则。

MySQL合集

MySQL1：MySQL发展史，MySQL流行分支及其对应存储引擎
MySQL2：MySQL中一条查询SQL是如何执行的？
MySQL3：MySQL中一条更新SQL是如何执行的？
MySQL4：索引是什么；索引类型；索引存储模型发展：1.二分查找，2.二叉查找树，3.平衡二叉树，4.多路平衡查找树，5. B+树，6.索引为什么不用红黑树？7.InnoDB的hash索引指什么？
MySQL5：MySQL数据存储文件；MylSAM中索引和数据是两个独立的文件，它是如何通过索引找到数据呢？聚集索引/聚簇索引，InnoDB中二级索引为什么不存地址而是存键值？row ID如何理解？
MySQL6：索引使用原则，联合索引，联合主键/复合主键，覆盖索引、什么是回表？索引条件下推，索引的创建与使用，索引的创建与使用，索引失效

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

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

相关文章

【C++初探：简单易懂的入门指南】二

【C++初探：简单易懂的入门指南】二

【C初探&#xff1a;简单易懂的入门指南】二 1.引用1.1引用做函数的参数1.2 引用做返回值1.2.1 关于引用做返回值的几点补充 1.3 多引用(对一个变量取多个别名)1.4 引用类型一致性原则以及权限的问题阐述1.5引用的效率问题1.6引用和指针的比较 2.auto关键字2.1 auto关键字的使用…
阅读更多...
BSTree二叉树讲解

BSTree二叉树讲解

二叉搜索树的概念&#xff1a; 二叉搜索树又称二叉排序树&#xff0c;它或者是一棵空树&#xff0c;或者是具有以下性质的二叉树: 若它的左子树不为空&#xff0c;则左子树上所有节点的值都小于根节点的值 若它的右子树不为空&#xff0c;则右子树上所有节点的值…
阅读更多...
重置 VCSA 6.7 root密码和SSO密码

重置 VCSA 6.7 root密码和SSO密码

原贴地址&#xff1a;https://www.cnblogs.com/airoot/p/16059033.html 问题描述 1、用root用户登录 VMware vCenter Server Appliance虚拟机失败&#xff0c;无法登录 2、vCenter Server Appliance 6.7 U1的root帐户错误尝试次数超过3次已锁定或帐户已过期 官方说明 在VC…
阅读更多...
【Spring Boot 源码学习】RedisAutoConfiguration 详解

【Spring Boot 源码学习】RedisAutoConfiguration 详解

Spring Boot 源码学习系列 RedisAutoConfiguration 详解 引言往期内容主要内容1. Spring Data Redis2. RedisAutoConfiguration2.1 加载自动配置组件2.2 过滤自动配置组件2.2.1 涉及注解2.2.2 redisTemplate 方法2.2.3 stringRedisTemplate 方法 总结 引言 上篇博文&#xff0…
阅读更多...
【C++基础入门】44.C++中对象模型分析（上）

【C++基础入门】44.C++中对象模型分析（上）

一、回归本质 class 是一种特殊的 struct 在内存中 class 依旧可以看作变量的集合class 与 struct 遵循相同的内存对齐规则class 中的成员函数与成员变量是分开存放的 每个对象有独立的成员变量所有对象共享类中的成员函数值得思考的问题 下面看一个对象内存布局的代码&#x…
阅读更多...
Go学习第十七章——Gin中间件与路由

Go学习第十七章——Gin中间件与路由

Go web框架——Gin中间件与路由 1 单独注册中间件1.1 入门案例1.2 多个中间件1.3 中间件拦截响应1.4 中间件放行 2 全局注册中间件3 自定义参数传递4 路由分组4.1 入门案例4.2 路由分组注册中间件4.3 综合使用 5 使用内置的中间件6 中间件案例权限验证耗时统计 1 单独注册中间件…
阅读更多...
Java项目之网络考试系统

Java项目之网络考试系统

视频教程&#xff1a; 01-创建数据库_哔哩哔哩_bilibili 源码下载&#xff1a;百度网盘 请输入提取码 准备工作 创建数据库配置IDEA后端导入前端 前言&#xff1a; 把代码掰开写进博客里&#xff0c;主要是让自己在整理笔记的过程中&#xff0c;多去思考完成这个功能的核心…
阅读更多...
基于深度学习的单图像人群计数研究:网络设计、损失函数和监控信号

基于深度学习的单图像人群计数研究:网络设计、损失函数和监控信号

摘要 https://arxiv.org/pdf/2012.15685v2.pdf 单图像人群计数是一个具有挑战性的计算机视觉问题，在公共安全、城市规划、交通管理等领域有着广泛的应用。近年来，随着深度学习技术的发展，人群计数引起了广泛的关注并取得了巨大的成功。通过系统地回顾和总结2015年以来基于深…
阅读更多...
rust学习——智能指针Rc

rust学习——智能指针Rc

文章目录 Rc 与 ArcRcRc::clone观察引用计数的变化不可变引用一个综合例子Rc 简单总结 多线程无力的 RcArcArc 的性能损耗 总结 Rc 与 Arc Rust 所有权机制要求一个值只能有一个所有者&#xff0c;在大多数情况下&#xff0c;都没有问题&#xff0c;但是考虑以下情况&#xff1…
阅读更多...
二维码智慧门牌管理系统升级解决方案：采集要素为智慧城市建设提供精准数据支持

二维码智慧门牌管理系统升级解决方案：采集要素为智慧城市建设提供精准数据支持

文章目录 前言一、二维码智慧门牌管理系统的升级需求二、采集要素在系统升级中的应用三、消防栓、井盖等采集要素的应用 前言 随着城市化进程的加速&#xff0c;智慧城市的建设已成为未来城市发展的必然趋势。其中&#xff0c;二维码智慧门牌管理系统作为智慧城市的重要组成部…
阅读更多...
基于Spring Boot的大学课程排课系统设计与实现

基于Spring Boot的大学课程排课系统设计与实现

摘 要 大学课程排课是现代教育管理中重要的一环。目前&#xff0c;传统的排课方式已经无法满足日益增长的课程需求和学生个性化的诉求。因此&#xff0c;研究一种基于遗传算法的大学课程排课系统是非常必要的。本研究旨在开发一种基于SpringBoot Vue的大学课程排课系统&#x…
阅读更多...
【Java 进阶篇】在Java Web应用中获取ServletContext对象详解

【Java 进阶篇】在Java Web应用中获取ServletContext对象详解

在Java Web应用开发中&#xff0c;ServletContext对象扮演着重要的角色&#xff0c;它允许你在整个Web应用程序中存储和共享数据。ServletContext对象是Servlet容器提供的一种用于管理Web应用程序的全局信息的方式。本文将详细探讨ServletContext对象的概念、用途以及如何在Jav…
阅读更多...
算法笔记【8】-合并排序算法

算法笔记【8】-合并排序算法

文章目录 一、前言二、合并排序算法基本原理三、实现步骤四、优缺点分析 一、前言 合并排序算法通过采用分治策略和递归思想&#xff0c;实现了高效、稳定的排序功能。本文将深入探讨合并排序算法的原理、实现步骤&#xff0c;并讨论其优缺点。 二、合并排序算法基本原理 合…
阅读更多...
AntDB数据库荣获 “2023年信创物联网优秀服务商”

AntDB数据库荣获 “2023年信创物联网优秀服务商”

日前&#xff0c;在2023世界数字经济大会暨第十三届智博会 2023京甬信创物联网产融对接会上&#xff0c;AntDB数据库再获殊荣&#xff0c;获评“2023年信创物联网优秀服务商”。 图1&#xff1a;2023年信创物联网优秀服务商颁奖现场 信创物联网是信息技术应用创新与物联网的结…
阅读更多...
网络爬虫入门导学

网络爬虫入门导学

一、内容组织 2、常用的python IDE工具 比较推荐以下几种&#xff1a; 其中IDLE是python自带的/默认的/常用的/入门级编写工具&#xff0c;包含交互式和文件式 适用于&#xff1a;简单直接/入门级/代码不超过300行 Sublime Text是专为程序员开发的第三方专用编程工具&#xff…
阅读更多...
OPNET ＜＜＜ Program Abort ＞＞＞ Standard function stack imbalance

OPNET ＜＜＜ Program Abort ＞＞＞ Standard function stack imbalance

OPNET <<< Program Abort >>> Standard function stack imbalance OPNET 问题原因及解决办法 OPNET 问题 OPNET仿真时遇到此问题&#xff1a; <<< Program Abort >>> Standard function stack imbalance 原因及解决办法 出现此问题是因…
阅读更多...
【逗老师的无线电】艾德克斯ITECH电源电子负载网口适配器

【逗老师的无线电】艾德克斯ITECH电源电子负载网口适配器

艾德克斯的产品还是不错的&#xff0c;但是ITECH的大部分中低端设备都不带网口&#xff0c;只带了一个串口&#xff0c;并且这个串口还是个完全非标定义的5V TTL串口&#xff0c;原装的适配器300多还只能转接成RS-232。 那么&#xff0c;这回咱们来整个骚活&#xff0c;直接给艾…
阅读更多...
Go-Python-Java-C-LeetCode高分解法-第十二周合集

Go-Python-Java-C-LeetCode高分解法-第十二周合集

前言 本题解Go语言部分基于 LeetCode-Go 其他部分基于本人实践学习 个人题解GitHub连接&#xff1a;LeetCode-Go-Python-Java-C 欢迎订阅CSDN专栏&#xff0c;每日一题&#xff0c;和博主一起进步 LeetCode专栏 我搜集到了50道精选题&#xff0c;适合速成概览大部分常用算法 突…
阅读更多...
简单明了！网关Gateway路由配置filters实现路径重写及对应正则表达式的解析

简单明了！网关Gateway路由配置filters实现路径重写及对应正则表达式的解析

问题背景&#xff1a; 前端需要发送一个这样的请求&#xff0c;但出现404 首先解析请求的变化&#xff1a; http://www.51xuecheng.cn/api/checkcode/pic 1.请求先打在nginx&#xff0c;www.51xuecheng.cn/api/checkcode/pic部分匹配到了之后会转发给网关进行处理变成localho…
阅读更多...
人工智能-线性回归的从零开始实现

人工智能-线性回归的从零开始实现

线性回归的从零开始实现 在了解线性回归的关键思想之后&#xff0c;我们可以开始通过代码来动手实现线性回归了。 在这一节中&#xff0c;我们将从零开始实现整个方法&#xff0c; 包括数据流水线、模型、损失函数和小批量随机梯度下降优化器。 虽然现代的深度学习框架几乎可以…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023