【SQL】MySQL进阶1:索引

mysql索引详解 MySQL的存储引擎架构将查询处理与数据的存储/提取相分离 阅读详情

1. 索引的类型

存储结构视角下:B+Tree索引,Hash索引,R-tree索引,Full-text索引
SQL语法视角下:主键索引(PRIMARY,创建主键约束时自动创建,只能一个),唯一索引(UNIQUE,可以多个),常规索引,全文索引(FULLTEXT)
InnoDB视角下:聚集索引(索引和数据放在一起,必须有且只能有一个),二级索引(索引和数据分开存放,可以有多个)
• 如果表未指定主键而指定了唯一约束,则对唯一约束列建立聚集索引。如果未指定主键,未指定唯一约束,则对默认的rowid列建立聚集索引。如果指定的主键,则对主键建立聚集索引。除了聚集索引外的索引是二级索引,二级索引叶子结点存放key和建立聚集索引的key值(一般是主键)。
• 查询过程:从二级索引查出主键,用主键在聚集索引中查出整行数据,这称为回表查询。
• 指针大小6byte,主键类型tinyint占8byte,一页大小16KB。设索引使用n阶B+tree,则一个索引页的情况是:8*(n-1)+6n=161024 --> n约为1171。只有一个索引页时B+tree深度为2,索引1171行数据(18736KB)。
在这里插入图片描述
存储引擎所支持的索引

存储引擎B+ treeHashR treeFull text
InnoDB支持不支持不支持支持(>=5.6)
MyISAM支持不支持支持支持
Memory支持支持不支持不支持

2. B+tree索引

2.1 前置概念

二叉树:根结点,左子树,右子树
二叉查找树/二叉搜索树/二叉排序树:二叉树,要求左孩子 <= 根 <= 右孩子
平衡查找二叉树/平衡二叉搜索树:二叉搜索树,要求左子树深度和右子树之差的绝对值小于2。AVL树,红黑树都是平衡查找二叉树。

2.2 使用B+tree的理由

非平衡二叉排序树作为索引的结构:平均情况O(logn),边界情况O(n)。
红黑树作为索引的结构:一种平衡二叉树,每个结点只有一个数据,数据量大时,深度依然大。
Btree作为索引的结构:一种多路平衡查找二叉树。对于n阶Btree,结点最多存放n-1个key,最多有n个子结点。结点存储key和数据,树的深度进一步降低。仅支持等值查找。
Btree

B+tree作为索引的结构:Btree的叶子结点加链(范围查找)。内部结点存储只存储key(索引存放集中,查询效率高),叶子结点存储key和数据,一个叶子结点对应一个数据。
B+tree
Hash表作为索引的存储结构:hashValue = hashMap(key),只支持等值查找,不支持范围查找。当不同key经过hash函数映射到相同的hash值,则产生冲突,称之为hash碰撞。碰撞的解决办法:拉链法,开放地址法(线性探测,二次探测),多重哈希,建立溢出公共区。

3. 索引的语法

-- 创建索引
CREATE [UNIQUE|FULLTEXT] INDEX index_name ON table_name(col0, col1);

-- 查看索引
SHOW INDEX FROM table_name;

-- 删除索引
DROP INDEX index_name ON table_name;

4. 查看SQL语句执行性能

4.1 查看增删改查操作频次

为何需要关心操作频次:如果对数据的更新,插入删除操作居多,则不适合建立索引来进行优化;如果查询数据居多,则应该考虑使用索引进行优化。

SHOW [GLOABL|SESSION] STATUS LIKE 'Com%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_binlog    | 0     |
| Com_commit    | 0     |
| Com_delete    | 0     |
| Com_import    | 0     |
| Com_insert    | 0     |
| Com_repair    | 0     |
| Com_revoke    | 0     |
| Com_select    | 1     |
| Com_signal    | 0     |
| Com_update    | 0     |
| Com_xa_end    | 0     |
+---------------+-------+

4.2 查看执行耗时

4.2.1 达到指定时限的查询:慢查询

-- 查看慢查询是否开启(默认关闭)
SHOW VARIABLES LIKE "slow_query_log";

-- 开启慢查询, my.cnf
[mysqld]
show_query_log = 1
long_query_time = 2  # 超过2s算慢查询

-- 查看慢查询日志:/var/lib/mysql/localhost-slow.log

4.2.2 未达到指定时限的查询:profile

-- 版本号大于或等于 5.0.37,理论支持
-- 查看profile设置
SELECT @@@profiling;
SHOW VARIABLES LIKE 'profiling';

-- 开启profile功能
SET [global] profiling = 1;

-- 查看当前会话执行的操作的耗时
SHOW PROFILES;

-- 查看指定查询的具体耗时情况
SHOW PROFILE FOR QUERY <queryID>;
-- 查看CPU计算耗时
SHOW PROFILE CPU FOR QUERY <queryID>;

-- 支持查询的类型
type: {
    ALL
  | BLOCK IO
  | CONTEXT SWITCHES
  | CPU
  | IPC
  | MEMORY
  | PAGE FAULTS
  | SOURCE
  | SWAPS
}

4.3 查看执行计划

-- 语法
EXPLAIN SELECT col FROM table_name WHERE condition;

-- case1: 多表连接查询的执行计划
EXPLAIN SELECT c.cust_id, c.cust_name, o.order_num FROM Customers AS c LEFT OUTER JOIN Orders AS o ON c.cust_id = o.cust_id;
+----+-------------+-------+------------+------+---------------------+---------------------+---------+----------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys       | key                 | key_len | ref            | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------------+---------------------+---------+----------------+------+----------+-------------+
|  1 | SIMPLE      | c     | NULL       | ALL  | NULL                | NULL                | NULL    | NULL           |    5 |   100.00 | NULL        |
|  1 | SIMPLE      | o     | NULL       | ref  | FK_Orders_Customers | FK_Orders_Customers | 40      | test.c.cust_id |    1 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------------+---------------------+---------+----------------+------+----------+-------------+

case2:子查询的执行计划
SELECT * FROM Customers AS cust WHERE cust.cust_id IN (
    SELECT o.cust_id FROM Orders AS o WHERE o.order_num IN (
        SELECT oi.order_num FROM OrderItems AS oi WHERE oi.quantity = 50
    )
);
+----+--------------+-------------+------------+--------+-----------------------------+---------------------+---------+---------------------+------+----------+-------------+
| id | select_type  | table       | partitions | type   | possible_keys               | key                 | key_len | ref                 | rows | filtered | Extra       |
+----+--------------+-------------+------------+--------+-----------------------------+---------------------+---------+---------------------+------+----------+-------------+
|  1 | SIMPLE       | <subquery2> | NULL       | ALL    | NULL                        | NULL                | NULL    | NULL                | NULL |     0.00 | NULL        |
|  1 | SIMPLE       | cust        | NULL       | eq_ref | PRIMARY                     | PRIMARY             | 40      | <subquery2>.cust_id |    1 |   100.00 | NULL        |
|  2 | MATERIALIZED | o           | NULL       | index  | PRIMARY,FK_Orders_Customers | FK_Orders_Customers | 40      | NULL                |    5 |   100.00 | Using index |
|  2 | MATERIALIZED | oi          | NULL       | ref    | PRIMARY                     | PRIMARY             | 4       | test.o.order_num    |    1 |    10.00 | Using where |
+----+--------------+-------------+------------+--------+-----------------------------+---------------------+---------+---------------------+------+----------+-------------+
/* 返回结果含义
id: 标记用到的表在执行中的次序,如果id相同,则从上到下执行(先执行关于表c的第一行,再执行关于表o的第二行),若id不同则id大的先执行。
select_type:  查询类型,SIMPLE,SUBQUERY,PRIMARY,UNION
type:NULL(不涉及任何表的查询,如SELECT VERSION();),system,const,eq_ref,ref,range,index,all。从左到右性能依次递减。
possible_key:可以使用的索引
key:实际使用的索引
key_len:索引长度。长度越短效率越高。可能使用字段值的部分建立索引。
ref:和索引匹配的关键字所属的列或者常量
rows:扫描的行数,估计值
filtered:WHERE过滤后的行占总行数的百分比
*/ 

5. 联合索引

5.1 索引使用的最左前缀法则

• 使用多字段联合索引是,筛选条件必须包含最左索引列
• 为查询选取筛选列时,要从索引列中从左往右连续地选取。
• 不要求筛选条件的顺序和索引列顺序保持一致。
• 如果筛选列包含索引最左列,而缺失索引列次左列,则联合索引只能生效关于最左列的部分,就即时其他索引列也出现在筛选条件中。
• 如果筛选条件包含的那些符合最左前缀原则的索引列,某列出现范围查找,则该列右侧的索引列失效。

-- case1: 最左前缀原则
-- 创建联合字段索引,索引列从左到右顺序为:cust_name, cust_address, cust_city
CREATE INDEX cust_idx_name_addr_city ON Customers(cust_name, cust_address, cust_city);

-- 筛选条件不包含索引最左侧列cust_name,不走索引。key_len=NULL
EXPLAIN SELECT * FROM Customers WHERE cust_address='1 Sunny Place' AND cust_city = 'Muncie';


-- 筛选条件包含索引最左列cust_name,走索引。筛选条件中cust_name的位置不影响索引使用。筛选条件包含所有索引列(cust_name,cust_address, cust_city),查询完整地使用索引,key_len=602
EXPLAIN SELECT * FROM Customers WHERE cust_city = 'Muncie' AND cust_name = 'Fun4All' AND cust_address='1 Sunny Place';
+----+-------------+-----------+------------+------+-------------------------+-------------------------+---------+-------------------+------+----------+-------+
| id | select_type | table     | partitions | type | possible_keys           | key                     | key_len | ref               | rows | filtered | Extra |
+----+-------------+-----------+------------+------+-------------------------+-------------------------+---------+-------------------+------+----------+-------+
|  1 | SIMPLE      | Customers | NULL       | ref  | cust_idx_name_addr_city | cust_idx_name_addr_city | 602     | const,const,const |    1 |   100.00 | NULL  |
+----+-------------+-----------+------------+------+-------------------------+-------------------------+---------+-------------------+------+----------+-------+


-- 筛选条件包含索引最左列cust_name,走索引。筛选条件包含索引最左的2列,查询部分地使用索引(cust_name, cust_address),key_len=401
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All' AND cust_address='1 Sunny Place';

-- 筛选条件包含索引最左列,不包含索引次左列,包含其他索引列,则索引只生效关于最左列的部分(cust_name)
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All' AND cust_city = 'Muncie';  -- key_len = 200
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All';  -- key_len = 200


-- case2:范围查找,右侧失效
-- 创建索引
CREATE INDEX oi_idx_prod_quantity_price ON OrderItems(prod_id, quantity, item_price);
-- 完整使用索引,key_len=48
EXPLAIN SELECT * FROM OrderItems WHERE prod_id = 'BNBG01' AND quantity = 100 AND item_price = '2.99';

-- 中间索引列(quantity)使用范围查询,导致右侧索引(item_price)列失效。
EXPLAIN SELECT * FROM OrderItems WHERE prod_id = 'BNBG01' AND quantity > 50 AND item_price = '2.99';  -- key=44
EXPLAIN SELECT * FROM OrderItems WHERE prod_id = 'BNBG01' AND quantity = 100;  -- key_len = 44

-- 使用>=则可以避免右侧索引列失效,key_len = 48
EXPLAIN SELECT * FROM OrderItems WHERE prod_id = 'BNBG01' AND quantity >= 50 AND item_price = '2.99';  -- key=44

5.2 索引覆盖

索引覆盖指的是在数据库查询过程中,查询所需要的所有数据都可以直接从索引中获取,而无需再回到数据表中去查找对应的数据行(称为回表)。查询计划中Extra=NULL,意味着有回表;Extra为Using Index,意味着直接使用索引就得到所需列,没有回表。

-- cust_name为索引列,cust_email不是索引列
CREATE INDEX idx_cust_name ON Customers(cust_name);
-- 查询使用二级索引idx_cust_name,该索引根据cust_name建立,根据索引查到匹配的cust_name值及其对应主键值,还需要根据主键值查聚集索引,找到匹配行,从匹配行中取出cust_email值。
EXPLAIN SELECT cust_name, cust_email FROM Customers WHERE cust_name = 'Fun4All';  -- Extra=NULL
EXPLAIN SELECT cust_id, cust_name FROM Customers WHERE cust_name = 'Fun4All';  -- Extra=Using index

5.3 单列索引和联合索引比较

为多列单独建立索引,筛选条件包含这些索引列,则MySQL会使用最高效率的那一个索引列,不用其他索引列。而为多列建立联合索引,筛选条件包含这些索引列,MySQL只会使用这个联合索引。建议优先使用联合索引,利用索引覆盖避免回表。同时索引数量更少,DBMS要维护的索引个数也就更少。

-- 为cust_name, cust_address单独建立索引,查询只会使用其中一个索引
CREATE INDEX idx_cust_name ON Customers(cust_name);
CREATE INDEX idx_cust_address ON Customers(cust_address);
-- possible_key=idx_cust_name,idx_cust_address; key=idx_cust_address
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All' AND cust_address = '1 Sunny Place';

-- 为cust_name, cust_address建立联合索引
CREATE INDEX idx_cust_name_addr ON Customers(cust_name,. cust_address);
-- possible_key=idx_cust_name_addr; key=idx_cust_name_addr
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All' AND cust_address = '1 Sunny Place';

索引失效的情况
-- case1: 对索引列使用函数
CREATE INDEX csut_idx_name ON Customers(cust_name);
-- 对索引列使用函数(有两条cust_name=’Fun4All‘的数据),索引失效。possible_key=NULL
EXPLAIN SELECT * FROM Customers WHERE substring(cust_name, 5, 3) = 'All';


-- case2:字符串类型列保存数值数据时,查询时可以不用单引号,但是这会导致索引失效(MySQL需要对索引列进行数据类型转换)
CREATE INDEX cust_idx_zip ON Customers(cust_zip);  -- cust_zip char(10), eg: cust_zip=44444
EXPLAIN SELECT * FROM Customers WHERE cust_zip = 44444;  -- possible_key = cust_idx_zip,key=NULL
EXPLAIN SELECT * FROM Customers WHERE cust_zip = '44444';  -- key_len = 41


--- case3: 模糊查询中,对索引字段头部使用通配符导致索引失效,对索引字段尾部使用通配符不会导致索引失效。
-- cust_name = Fun4All
-- 对索引列值头部使用通配符, possible_key=NULL
EXPLAIN SELECT * FROM Customers WHERE cust_name LIKE '%All';
-- 对索引列值尾部使用通配符,key_len=200
EXPLAIN SELECT * FROM Customers WHERE cust_name LIKE 'Fun';


-- case4: OR逻辑中,只有所有条件都涉及索引列,索引才生效
-- cust_id有主键索引,cust_city无索引,possible_key=NULL
EXPLAIN SELECT * FROM Customers WHERE cust_id = '1000000001' OR cust_city = 'Chicago';
-- cust_id有主键索引(PRIMARY),cust_name有单列的索引(csut_idx_name)。key_len=40,200(索引长度分别为40和200)
EXPLAIN SELECT * FROM Customers WHERE cust_id = '1000000001' OR cust_name = 'Fun4All';

6. 使用指定索引

-- 一个字段上创建多个索引
CREATE INDEX idx_cust_name ON Customers(cust_name);
CREATE INDEX idx_cust_name_addr ON Customers(cust_name, cust_address);

-- MySQL自己决定使用哪个索引: possible_key=idx_cust_name_addr,idx_cust_name; key=idx_cust_name
EXPLAIN SELECT * FROM Customers WHERE cust_name = 'Fun4All';

-- 建议MySQL使用指定索引,possible_key=idx_cust_name_addr; key=idx_cust_name_addr
EXPLAIN SELECT * FROM Customers USE INDEX(idx_cust_name_addr) WHERE cust_name = 'Fun4All';

-- 强制MySQL使用指定索引
EXPLAIN SELECT * FROM Customers FORCE INDEX(idx_cust_name_addr) WHERE cust_name = 'Fun4All';

-- 忽略指定索引,possible_key=idx_cust_name; key=idx_cust_name
EXPLAIN SELECT * FROM Customers IGNORE INDEX(idx_cust_name_addr) WHERE cust_name = 'Fun4All';

7. 前缀索引

索引可选择性:不重复索引值占总记录数的比值。可选择性越高,索引查询效率越高,同时可能前缀越长(占用空间大)。在创建前缀索引时,要在可选择性和前缀长度之间权衡。

-- 计算整个字段值可计算型
SELECT COUNT(DISTINCT cust_email) / COUNT(*) FROM Customers;

-- 计算前缀可选择性
SELECT COUNT(DISTINCT substring(cust_email, 1, 10)) / COUNT(*) FROM Customers;

-- 创建前缀索引
CREATE INDEX idx_cust_email ON TABLE(cust_email(10));

8. 索引小结

8.1 对什么表考虑使用索引

• 数据量大(百万记录数),查询多,更新删除少。

8.2 对那些字段考虑使用索引

• 出现在WHERE子句,GROUP BY子句,ORDER BY子句中的字段。
• 区分度高的字段作为索引(宜:身份证号,电话号码等,忌:状态等)。
• 字符串/文本类型的字段考虑使用前缀索引

8.3 创建索引考虑什么

• 尽量使用联合索引(注意最左前缀法则),而不是单列索引。
• 必要时建立索引(索引数量多,维护开销大)
• 如果希望索引列不包含NULL值,应该在建表时指定NOT NULL约束(便于优化选择效率最高的索引)。

8.4 补充

如果全表扫描比索引快,则MySQL可能不使用索引,这主要由数据的分布决定。

9. 参考

视频教程:https://www.bilibili.com/video/BV1Kr4y1i7ru/
数据结构演示网站:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

晶闸管选型参数,结构原理,工艺与注意问题总结 闸管(Thyristor)是一种半导体开关器件,也被称为可控硅整流器(SCR, Silicon Controlled Rectifier)。它可以在高电压和大电流条件下工作,常被用于交流电的控制和整流。本文对晶闸管的工作原理,结构特点,工艺流程,选型参数及设计注意事项进行总结。 阅读详情

相关推荐

计算机组成原理实验logisim(四)之运算器实验

注意,上半张图中所有连入32位宽多路选择器的器件和的“数据位宽”都是32,而中间部分连入1位多路选择器的器件的“数据位宽”皆为1(除了连向“32位加法器”的那一个非门,是32位)。第二到第五个实验的测试,具体怎么测试好吧我也不太清楚,听室友说就是让你分析各种亮灯的原理,比如你点这个,那个为什么颜色要变等等,我就不粘图了,恩大家加油。连图如下,需要在连线之前格外注意“异或门”和“与门”的位宽,将16改为1,不然数据无法通行。关于学术问题,为何这样连什么的,就别问我了,我也没有搞的那么透彻。

qq_54422132的博客 2万+

MySQL进阶篇之二:索引

介绍索引(index)是帮助MySQL高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引。演示查找语句:select * from user whereage=45;无索引:在无索引的情况下,我们需要对整张表从第一个指针位开始,依次查找表中的所有字段,就算有一个字段的age=45,我们仍然需要查下去,因为后面的地址中可能还会存在age=45的字段。有索引。

喜欢喝椰奶的博客 318

Anaconda+清华源加速PyTorch GPU环境安装与CUDA版本匹配指南

深度学习环境管理常面临依赖冲突与下载缓慢问题,通过虚拟环境隔离与镜像源加速可显著提升效率。Anaconda利用conda机制创建独立Python环境,避免包版本冲突;清华源通过国内镜像同步大幅提高下载速度。GPU版PyTorch安装需严格匹配CUDA、cuDNN与显卡驱动版本,否则易出现CUDA不可用错误。该方案适用于图像分割、目标检测等需多版本PyTorch并存的场景,能快速搭建稳定GPU训练环境。本文详解Anaconda安装、清华源配置及PyTorch GPU版安装全流程。

weixin_30522983的博客 236

MySQL数据库中的索引(含SQL语句)

为什么要用索引 假设有一张表,表中有100万条数据,这100万条数据在硬盘上是存储在数据页上的,一页数据大小为16k。存储100万条数据那么就需要数据页,假设其中有一条数据是“id为7900”的,那么如果要查询这条数据,其中SQL是SELECT * FROM 表名 WHERE id = 7900。在执行这条SQL语句的时候,MySQL需要扫描全表来查询id = 7900的记录。 全表扫描就是从“数据页1”开始,向后逐页查询。对于少量数据来说,查询的速度会很快,但是,当随着数据量的增加,性能会急剧下降....

古城的博客 1万+

STM32与SD卡SPI接口硬件设计:从原理图到调试的完整指南

SPI(串行外设接口)作为一种广泛应用的同步串行通信协议,以其接线简单、驱动成熟的特点,成为连接微控制器与各类外设的经典方案。其工作原理基于主从架构,通过时钟、数据线和片选信号实现全双工通信,在嵌入式系统中具有极高的技术价值,常用于连接传感器、存储设备和显示模块等。在数据存储场景中,SD卡凭借其大容量和便携性成为首选,而通过SPI模式驱动SD卡,则平衡了性能与设计复杂度。本文聚焦于使用Altium Designer进行硬件设计的工程实践,详细解析了STM32微控制器与SD卡通过SPI通信时,电源管理、上拉电

weixin_34101784的博客 555

华为CCA架构软件栈VehicleStack解析:3层服务化设计与AOS/VOS双核OS

本文深入解析华为CCA架构下的VehicleStack软件平台,重点介绍其三层服务化设计(硬件抽象层、服务框架层、应用层)与AOS/VOS双核操作系统协同机制。该架构通过计算与通信的深度融合,推动汽车电子电气架构向集中式发展,为智能汽车提供灵活、高效的软件定义汽车解决方案。

weixin_33491377的博客 324

mysql添加索引的方法(Navicat可视化加索引和sql语句加索引)

mysql添加索引的方法(Navicat可视化加索引和sql语句加索引)

h1403635700的博客 3万+

【搭建实战】全国天气预报看板搭建

不仅如此,码匠还一站式提供了企业内部系统常用的租户管理、细粒度的权限控制、审计日志等功能,让您快速搭建后台应用的同时,也为您的企业信息安全保驾护航。是一款国内研发的开发者友好的低代码平台,您无需了解React/Vue等框架的开发、部署等各种细节,就可以快速打通前后端,连接RESTAPI、MySQL、MongoDB等多种数据源,然后通过一套开箱即用的组件,轻松搭建功能完善的数据看板、数据洞察、Admin管理后台等多种应用。天气预报对我们的各项活动有很大的帮助,可以让我们合理安排自己的出行等活动。...

weixin_39545889的博客 429

MySQL -- 索引

当表中的数据量过大时,SQL查询所花费的时间会很长,导致业务超时出错,此时就需要用索引来加速SQL查询。

Afison的博客 1608

学习STM32的CAN总线通信

在配置时,确保您启用了CAN总线功能。CAN节点是CAN总线上的一个设备,每个节点都有唯一的标识符。在CAN总线中,有两种类型的节点:CAN控制器和CAN外设。步骤2:配置CAN总线 在STM32CubeMX中,选择CAN总线模块并进行必要的配置。在CAN总线中,有两个重要的概念:CAN节点和CAN帧。步骤5:测试CAN总线通信 在成功编译和烧录代码后,您可以使用串口调试助手或其他CAN总线工具来测试CAN总线通信。步骤3:编写CAN总线通信代码 在项目的主代码文件中,我们将编写CAN总线通信的示例代码。

2401_85258012的博客 496

程序员应用AI大模型创业实现财务自由的100种赚钱方案原理与实战指南

成功的 AI 创业者都遵循着 “技术 + 需求 + 变现” 的铁三角法则。记住:不是要做 “全能大模型”,而是成为某个垂直领域的 “AI 解决方案专家”。现在就开始行动:用周末 2 小时完成第一个 MVP,下周启动种子用户测试,三个月内找到可复制的盈利模式。当你实现第一个 10 万用户时,会发现财务自由的密码藏在持续迭代的每个 0.1 版本更新中。延伸思考:你的技术背景适合切入哪个细分领域?

AI天才研究院 1380

【MySQL数据库】如何指定SQL查询使用特定的索引?

在MySQL中,我们可以使用USE INDEX或FORCE INDEX语句来指定SQL查询使用特定的索引。这两个语句都可以让我们覆盖MySQL查询优化器的决策,强制它使用我们指定的索引。

tr6666的博客 2047

Android性能分析——hprof文件分析(一)

hprof  文件是 Java 堆转储文件(Heap Dump File)的标准格式,用于保存 Java 虚拟机(JVM)在某个时间点的内存快照。这种文件对于分析内存泄漏、内存使用情况和对象分配模式非常有用。

小旭的专栏 1880

MySQL 进阶篇1.0 索引 SQL优化 视图 锁

03存储引擎-简介查询建表语句--默认存储引擎:InnoDB查询当前数据库支持的存储引擎;开关为"ON":表示每个innodb引擎的表都有一个idb表共享文件红黑树和二叉树都存在问题:大数据量情况,层级较深,检索速度慢;最大度数:n每个节点最多存储n-1个keyn个指针;分裂的时候中间向上左右继续插入元素,数据结构可视化网站编辑视图会在操作的时候检查是否满足where条件并递归继续检查上面(依赖)的v2带cascaded的where。

我亦无他,唯手熟尔 6387

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

SQL进阶(1)——MySQL元数据与索引

文章目录1.mysql-基础操作篇 1.mysql-基础操作篇

zzhou——blog 1089

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

MySQL进阶之索引(1)索引结构分类语法和SQL性能分析

学习索引的结构分类语法和SQL性能分析

xrkhy的博客 1018

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

Mysql进阶篇1-存储引擎、索引、SQL性能分析指令

本文介绍了MySQL存储引擎和索引的核心知识。存储引擎方面,重点分析了InnoDB和MyISAM的特点:InnoDB支持事务、行级锁和外键,适合高并发场景;MyISAM支持表级锁和全文索引,适合读多写少场景。索引部分详细讲解了B+Tree结构优于二叉树和B树的原因,包括层级更少、范围查询高效等优势。同时介绍了索引分类(主键、唯一、常规、全文索引)和聚集索引与二级索引的区别,其中聚集索引叶子节点存储数据,二级索引存储主键值。最后提到索引使用的最左前缀法则,强调联合索引查询必须包含最左字段。全文为MySQL性能

y_k_j_c的博客 967

【第12天】MYSQL进阶-索引的组合索引(SQL 小虚竹)_sql 组合索引(1)

今天是学习SQL打卡的第12天,每天我会提供一篇文章供群成员阅读(不需要订阅付钱希望大家先自己思考,如果实在没有想法,再看下。

2401_84689346的博客 407

MySQL进阶篇1(存储引擎|索引|SQL优化|视图)

全表扫描。

weixin_64260427的博客 825

MySQL进阶_1 (体系结构、存储引擎、SQL优化、索引使用)

文章目录MySQL体系结构术语浅解一些缩写Mysql系统自带的数据库元数据MySQL数据库文件存储引擎Mysql存储引擎的特性概览MyISAMInnoDBMEMORYMERGE存储引擎怎么选SQL优化步骤查询SQL的执行效率定位低效率的SQLexplain命令分析执行计划show profile的使用优化器trace工具的使用索引使用准备工作避免索引失效查看索引的使用情况SQL优化批量插入数据的优化insert语句的优化order by优化group by 优化子查询优化or优化limit优化索引提示 My

Dean_xiu的博客 1281

sql怎么select中位数_SQL 进阶技巧(下)

上文我们简述了 SQL 的一些进阶技巧,一些朋友觉得不过瘾,我们继续来下篇,再送你 10 个技巧 一、 使用延迟查询优化 limit [offset], [rows]经常出现类似以下的 SQL 语句:SELECT offset 特别大!这是我司出现很多慢 SQL 的主要原因之一,尤其是在跑任务需要分页执行时,经常跑着跑着 offset 就跑到几十万了,导致任务越跑越慢。LIMIT 能很好地解决分页...

weixin_39929153的博客 219

【MySQL进阶教程】SQL优化

本文为 【MySQL进阶教程】SQL优化相关知识,下边将对主键优化,order by优化,group by优化,limit优化,count优化,update优化等进行详尽介绍~

小新要变强的博客 4152

【MySQL进阶篇】索引

索引(Index)是帮助MySQL高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引。

2401_83283514的博客 2394

MySQL进阶-----SQL提示与覆盖索引

MySQL进阶篇的索引部分基本上要结束了,这里就剩下SQL提示、覆盖索引、前缀索引以及单例联合索引的内容。那本期的话我们就先讲解SQL提示和覆盖索引先,剩下的内容就下一期作为完结篇讲解。

m0_73633088的博客 1260

MySQL 索引及SQL优化

MySQL 索引设计及失效情况,SQL优化

青竹暖回阳的博客 2322

MySQL进阶之索引

索引:是帮助MySQL高效获取数据的数据结构(有序的)。在数据之外,数据库系统嗨维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引。哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上2. 特点Hash索引只能用于对等比较,不支持范围查询;无法利用索引完成排序操作:查询效率高,通知只需要一次检索就可以了,效率通常高于B+tree索引。

jiuxiandd的博客 1690
上一篇: 【SQL】MySQL基础1:对表的DQL,DML,DDL
下一篇: 【SQL】MySQL进阶2:优化
南隅。
博客等级 码龄8年 279粉丝 31原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值