索引失效场景/索引种类/全文索引用法/sql执行顺序/死锁如何解决/什么是回表/大表如何优化/推荐用b+树的原因

【【【Mysql数据库中,什么情况下设置了索引但⽆法使⽤?
1. 没有符合最左前缀原则d
2. 字段进⾏了隐式数据类型转化【数据库是varchar,但是传参是int的不行,反之是可以的】
3. ⾛索引没有全表扫描效率⾼

【【【索引种类有哪些
system:系统表中只有一条记录,或者对于一个返回单条记录的衍生表进行主查询。这种类型非常快,但实际开发中很少遇到。
const:当索引列是主键或唯一键,并且查询条件完全匹配这个值时,可以到达这个级别。例如,SELECT * FROM table WHERE id = 1;,其中id是主键或唯一索引。
eq_ref:对于每个索引键的查询,返回匹配唯一行数据。这通常发生在使用主键或唯一索引进行查询时。
【普通索引】ref:非唯一性索引,对于每个索引键的查询,返回匹配的所有行(可以是0,或多个)。
range:检索指定范围的行,查找一个范围内的数据,例如使用BETWEEN, IN, <, >等操作符的查询。
index:索引全表扫描,比ALL快,因为索引文件通常比数据文件小,并且索引是按顺序存储的。
ALL:全表扫描,这是最不高效的类型,因为没有使用索引,数据库需要扫描整个表来查找匹配的行
MySQL 索引类型有哪些?
主键索引
索引列中的值必须是唯一的,不允许有空值。
普通索引
MySQL中基本索引类型,没有什么限制,允许在定义索引的列中插入重复值和空值。
唯一索引
索引列中的值必须是唯一的,但是允许为空值。
全文索引
只能在文本类型CHAR,VARCHAR,TEXT类型字段上创建全文索引。字段长度比较大时,如果创建普
通索引,在进行like模糊查询时效率比较低,这时可以创建全文索引。MyISAM和InnoDB中都可以
使用全文索引。
空间索引
MySQL在5.7之后的版本支持了空间索引,而且支持OpenGIS几何数据模型。MySQL在空间索引这
方面遵循OpenGIS几何数据模型规则。
前缀索引
在文本类型如CHAR,VARCHAR,TEXT类列上创建索引时,可以指定索引列的长度,但是数值类型不
能指定。
阿里内部资料
其他(按照索引列数量分类)
1. 单列索引
2. 组合索引
组合索引的使用,需要遵循最左前缀匹配原则(最左匹配原则)。一般情况下在条件允许的情
况下使用组合索引替代多个单列索引使用。
【【【全文索引的用法
#查看长度是多少
SHOW VARIABLES LIKE 'ft_min_word_len';
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';

#1-编辑配置文件
vim /etc/my.cnf
#添加以下内容
    [mysqld]
    ft_min_word_len = 1
    innodb_ft_min_token_size = 1
#2-并且重启mysql服务
sudo systemctl restart mysqld
#3-删除之前创建的全文索引字段并且重新创建
#4-查询写法
SELECT * FROM user WHERE MATCH(name) AGAINST(concat('+', 'c', '*') IN BOOLEAN MODE);

说说在 MySQL 中一条查询 SQL 是如何执行的?
比如下面这条SQL语句:
1. 取得链接,使用使用到 MySQL 中的连接器。
select name from t_user where id=1
阿里内部资料
2. 查询缓存,key 为 SQL 语句,value 为查询结果,如果查到就直接返回。不建议使用次缓存,
在 MySQL 8.0 版本已经将查询缓存删除,也就是说 MySQL 8.0 版本后不存在此功能。
3. 分析器,分为词法分析和语法分析。此阶段只是做一些 SQL 解析,语法校验。所以一般语法错
误在此阶段。
4. 优化器,是在表里有多个索引的时候,决定使用哪个索引;或者一个语句中存在多表关联的时
候(join),决定各个表的连接顺序。
5. 执行器,通过分析器让 SQL 知道你要干啥,通过优化器知道该怎么做,于是开始执行语句。执
行语句的时候还要判断是否具备此权限,没有权限就直接返回提示没有权限的错误;有权限则
打开表,根据表的引擎定义,去使用这个引擎提供的接口,获取这个表的第一行,判断 id 是都
等于 1。如果是,直接返回;如果不是继续调用引擎接口去下一行,重复相同的判断,直到取
到这个表的最后一行,最后返回。

【【【oracle查询锁定的表和对应会话:
SELECT
    o.object_name,
    s.sid,
    s.serial#,
    p.spid,
    s.username,
    s.program
FROM
    v$locked_object l
JOIN dba_objects o ON l.object_id = o.object_id
JOIN v$session s ON l.session_id = s.sid
LEFT JOIN v$process p ON p.addr = s.paddr;

ALTER SYSTEM KILL SESSION 'sid,serial#';

【【【mysql查找死锁和主动杀死方法
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
kill trx_mysql_thread_id;

【【【回表可以举个sql例子嘛
当然可以。以MySQL数据库为例,假设我们有一个名为employees的表,其中包含以下列:
sql
CREATE TABLE employees (
    id INT NOT NULL AUTO_INCREMENT,
    firstName VARCHAR(50),
    lastName VARCHAR(50),
    department VARCHAR(50),
    salary DECIMAL(10, 2),
    PRIMARY KEY (id),
    KEY idx_department (department)
) ENGINE=InnoDB;
在这个表中,id是主键,而department是一个普通索引。
不需要回表的情况:
如果我们的查询只涉及department字段,并且这个字段被索引覆盖,那么就不需要回表:
sql
SELECT department FROM employees WHERE department = 'Sales';
在这个查询中,MySQL可以直接使用idx_department索引来获取所有在销售部门的记录,不需要访问主键索引。
需要回表的情况:
如果查询涉及到不在索引中的字段,比如salary,那么就需要回表:
sql
SELECT firstName, salary FROM employees WHERE department = 'Sales';
在这个查询中,MySQL首先会使用idx_department索引来找到所有在销售部门的记录的id,然后它需要使用这些id去主键索引中查找每一行的firstName和salary字段,因为这些字段不在idx_department索引中。这个过程就是回表。
避免回表的优化:
为了优化查询性能并避免回表,我们可以创建一个覆盖索引,这个索引包含查询中需要的所有字段:
sql
CREATE INDEX idx_department_salary ON employees (department, salary);
现在,如果我们使用新的索引进行查询:
sql
SELECT department, salary FROM employees WHERE department = 'Sales';
MySQL可以直接使用idx_department_salary索引来获取所需的数据,而不需要回表,因为索引中已经包含了department和salary字段。这就是所谓的覆盖索引,它覆盖了查询所需的全部数据,从而提高了查询效率。
【【【大表如何优化?
当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下:
1. 限定数据的范围
务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们
可以控制在一个月的范围内;
2. 读/写分离
经典的数据库拆分方案,主库负责写,从库负责读;
3. 垂直分区
根据数据库里面数据表的相关性进行拆分。 例如,用户表中既有用户的登录信息又有用户的基本信
息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。
简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。 如下图所示,这样来
说大家应该就更容易理解了。
1583307481617
垂直拆分的优点: 可以使得列数据变小,在查询时减少读取的Block数,减少I/O次数。此外,
垂直分区可以简化表的结构,易于维护。
垂直拆分的缺点: 主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层
进行Join来解决。此外,垂直分区会让事务变得更加复杂;
B树和B+树的区别,为什么Mysql使⽤B+树
B树的特点:
1. 节点排序
2. ⼀个节点了可以存多个元素,多个元素也排序了
B+树的特点:
1. 拥有B树的特点
2. 叶⼦节点之间有指针
3. ⾮叶⼦节点上的元素在叶⼦节点上都冗余了,也就是叶⼦节点中存储了所有的元素,并且排好顺序
Mysql索引使⽤的是B+树,因为索引是⽤来加快查询的,⽽B+树通过对数据进⾏排序所以是可以提⾼查询
速度的,然后通过⼀个节点中可以存储多个元素,从⽽可以使得B+树的⾼度不会太⾼,在Mysql中⼀个
Innodb⻚就是⼀个B+树节点,⼀个Innodb⻚默认16kb,所以⼀般情况下⼀颗两层的B+树可以存2000万
⾏左右的数据,然后通过利⽤B+树叶⼦节点存储了所有数据并且进⾏了排序,并且叶⼦节点之间有指针,
可以很好的⽀持全表扫描,范围查找等SQL语句。
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 220,884评论 6 513
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,212评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 167,351评论 0 360
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,412评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,438评论 6 397
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,127评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,714评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,636评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,173评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,264评论 3 339
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,402评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 36,073评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,763评论 3 332
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,253评论 0 23
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,382评论 1 271
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,749评论 3 375
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,403评论 2 358

推荐阅读更多精彩内容