数据库基础知识

最新推荐文章于 2022-04-09 18:35:50 发布

shenlanse7626

最新推荐文章于 2022-04-09 18:35:50 发布

阅读量129

点赞数

分类专栏：基础知识

基础知识专栏收录该内容

7 篇文章 0 订阅

订阅专栏

[数据库] 数据库索引有哪些？分别介绍说明一下？

索引类型

Mysql目前主要有以下几种索引类型：FULLTEXT，HASH，BTREE，RTREE。MyIASM中默认的BTREE类型的索引。

FULLTEXT
即为全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不过目前只有 CHAR、VARCHAR ，TEXT 列上可以创建全文索引。

全文索引并不是和MyISAM一起诞生的，它的出现是为了解决WHERE name LIKE “%word%"这类针对文本的模糊查询效率较低的问题。

HASH
由于HASH的唯一（几乎100%的唯一）及类似键值对的形式，很适合作为索引。

HASH索引可以一次定位，不需要像树形索引那样逐层查找,因此具有极高的效率。但是，这种高效是有条件的，即只在“=”和“in”条件下高效，对于范围查询、排序及组合索引仍然效率不高。

BTREE
BTREE索引就是一种将索引值按一定的算法，存入一个树形的数据结构中（二叉树），每次查询都是从树的入口root开始，依次遍历node，获取leaf。这是MySQL里默认和最常用的索引类型。
RTREE
RTREE在MySQL很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有MyISAM、BDb、InnoDb、NDb、Archive几种。
相对于BTREE，RTREE的优势在于范围查找。

三、索引种类
普通索引：仅加速查询
唯一索引：加速查询 + 列值唯一（可以有null）
主键索引：加速查询 + 列值唯一（不可以有null）+ 表中只有一个
组合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并
全文索引：对文本的内容进行分词，进行搜索
ps.
索引合并，使用多个单列索引组合搜索
覆盖索引，select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖

[数据库] mysql 索引引擎种类？

InnoDB：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。
对于InnoDB表，自动增长列必须是索引。如果是组合索引，也必须是组合索引的第一列
InnoDB是事务型数据库的首选引擎，MySQL5.5以后默认使用InnoDB存储引擎
MySQL支持外键的存储引擎只有InnoDB
InnoDB将它的表和索引在一个逻辑表空间中
如果没有显示在表定义时指定主键，InnoDB会为每一行生成一个6字节的ROWID，并以此作为主键。

MyISAM：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比较低，也可以使用。
MyISAM拥有较高的插入、查询速度，但不支持事务，不支持外键。
全文索引，目前只有MyISAM引擎支持

MEMORY：所有的数据都在内存中，数据的处理速度快，但是安全性不高。如果需要很快的读写速度，对数据的安全性要求较低，可以选择MEMOEY。它对表的大小有要求，不能建立太大的表。所以，这类数据库只使用在相对较小的数据库表。
可以在一个MEMORY表中有非唯一键值。
MEMORY支持AUTO_INCREMENT列和对可包含NULL值的列的索引。
默认情况下，MEMORY数据表使用散列索引，利用这种索引进行“相等比较”非常快，但是对“范围比较”的速度就慢多了。因此，散列索引值适合使用在"=“和”<=>“的操作符中，不适合使用在”<“或”>“操作符中，也同样不适合用在order by字句里。如果确实要使用”<“或”>"或betwen操作符，可以使用btree索引来加快速度。
在这里插入图片描述

[数据库] 唯一索引和主键索引的区别？

1.唯一性索引列允许空值，而主键列不允许为空值。
2.一个表最多只能创建一个主键，但可以创建多个唯一索引。
主键更适合那些不容易更改的唯一标识，如自动递增列、身份证号等。

[数据库] 数据库索引失效情况？

1.使用like%模糊查询的时候，包括‘%aaa’和‘%aaa%’,则不会走索引，但是‘aaa%’可以走索引。
2.查询语句中使用了is not null 或者 <>不等于比较运算符也会导致索引失效；
3.对索引列使用了运算/函数的场合使得索引失效;如year(create_time)=‘2017’;

[数据库] 数据库调优？

物理上：
1.为索引创建单独的表空间。
2.为业务字段创建索引。
业务上优化：
1.避免返回大量数据，减少访问数据库次数。缓存数据。
sql上优化：
1.避免使用*，手动指定返回列。
2.避免在where子句中对字段进行null判断，否则放弃使用索引。可以设置字段默认值。
3.隐式转换导致不走索引。
4.避免使用！=，<>,or,否则不会使用索引。
5.使用表别名，并发返回列上加上表别名。减少解析时间，减少因为列名歧义引起的语法错误。
6.尽量使用join连接查询，避免子查询。
7.避免频繁创建和删除临时表，可以使用关联查询代替。
8.避免索引更多，一般不要超过6个。
9.避免在数据字段上使用函数和表达式运算，否则放弃索引，可以在参数上进行表达式计算。
10.主键尽量使用整形自增主键，便于存储引擎存储及比较运算。
11.选择最有效率的表名顺序。

按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。必须选择记录条数最少的表作为基础表。
例如:

表 TAB1 16,384 条记录

表 TAB2 1 条记录 

选择TAB2作为基础表 (最好的方法)

select count(*) from tab1,tab2 执行时间0.96秒 

选择TAB1作为基础表 (不佳的方法)

select count(*) from tab2,tab1 执行时间26.09秒

12.WHERE子句中的连接顺序。
采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前,那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。

[数据库] 数据库死锁及解决方法？

出现原因：
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。
解决方法：
这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理，必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

二. 并发修改同一记录
出现原因：
　用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁由于比较隐蔽，但在稍大点的项目中经常发生。
　一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。
解决方法：
a. 使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。
b. 使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。

[数据库] mysql主从原理及操作？

## [数据库] mysql常用操作？ 1.开启数据库，在命令行输入：net start mysql 2.关闭数据库，在命令行输入：net stop mysql 3.查看

[数据库] 事物特性ACID？

如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：
⑴ 原子性（Atomicity）
　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚
因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

⑵ 一致性（Consistency）
　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。

⑶ 隔离性（Isolation）
　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
　　关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。

⑷ 持久性（Durability）
　　持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
　　例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

https://blog.csdn.net/zh521zh/article/details/69400053

MySQL 存储引擎详细介绍

索引是基于表的，切换搜索引擎方式：navicat-设计表-引擎
MySQL的索引文件位置：mysql安装目录/data/库/表/
索引是帮助数据库高效获取数据的排序好的数据结构，索引存储在文件里。

概述
MySQL存储引擎有三种 InnoDB(5.5版本默认存储引擎)，Myisam，memory。InnoDB和MyISAM使用B+Tree树结构，MEMORY使用hash存储结构。接下来主要讲解B+Tree存储结构。
索引引擎数据存储结构比较
常用类型为二叉树，红黑树，BTREE，B+TREE。
二叉树缺点：在极端情况下容易造成单边增长。
红黑树：
概述：可以通过变色和选择实现自平衡。
缺点：但是当数据量大时，高度不可控。
B-Tree：
概述：B-Tree树节点横向变长，使高度变小。每个结点可以存储多个数据。数据存储在叶子每个叶子结点上。
度：就是结点可以存储多少个数据。超过15/16这个比值时就会自动分叉。
缺点：结点会存储数据，增加空间。
B+Tree（B-Tree变种）
概述：
非叶子结点不存储数据，只存储key，可以增加度。
叶子结点不存储指针
顺序访问指针，提高区间访问的性能。
B+Tree和B-Tree的区别就是B-Tree叶子结点存储数据，而B+Tree只有叶子结点存储数据，并且叶子结点存储向下的指针。
InnoDB存储引擎
a.主键存储引擎介绍
称为聚集索引，数据都存储在子叶子结点上。
InnoDB数据文件本身就是按照主键以B+Tree的形式进行存储结构。
InnoDB存储引擎必须有一个主键，如果不设置主键，会默认设置一个6位的ROWID主键。
文件存储结构：
表.frm:表结构文件。
表.idb:表数据和索引文件。
b.非主键存储引擎
和主键索引不同的是非主键索引叶子结点不存储数据，它存储主键索引的指针。
MyIsAM存储引擎(非聚集)
a.主键存储引擎
称为非聚集索引，子叶子不直接存储数据，而是存储数据的指针。
c.非主键存储引擎
非主键索引和主键索引区别是非主键索引的叶子结点存储的是数据的指针。