索引模块
++为什么要使用索引
++什么样的信息能成为索引
++索引的数据结构
++密集索引和稀疏索引的区别
一、为什么要使用索引
++可以避免全表扫描去查询数据,提高查询效率(类似于字典)
二、什么样的信息能成为索引
++主键、唯一键及普通键等
**
三、索引的数据结构
++生成索引,建立二叉查找树进行二分查找
++生成索引,建立B-Tree结构进行查找
++生成索引,建立B±Tree结构进行查找
++生成索引,建立Hash结构进行查找
定义:
++根节点至少包括两个孩子
++书中每个节点最多包含m个孩子(m>=2)
++除根节点和叶节点外,其他每个节点至少有ceil(m/2)个孩子
++所有叶子节点都位于同一层
B+Tree
**B+树是B树的变体,其定义基本于B树相同,除了
++非叶子节点的子树指针与关键字个数相同
++非叶子节点的子树指针P[i],指向关键字值【k[i],k[i+1]】的子树
++非叶子节点仅用来索引,数据都保存在叶子节点中
++所有叶子节点均有一个链指针指向下一个节点**
B+Tree更适合用来做存储索引
++B+树的磁盘读写代价更低
++B+树的查询效率更加稳定
++B+树更有利于对数据库的扫描
Hash索引的缺点:
++仅仅能满足 ”=“,”IN",不能使用范围查询
++无法被用来避免数据的排序操作
++不能利用部分索引键查询
++不能避免表扫描
++遇到大量Hash值相等的时候性能并不一定就会比B-Tree索引高
密集索引和稀疏索引的区别
++密集索引文件中的每个搜索码值都对应一个索引键
++稀疏索引文件只为索引码的某些值建立索引项
衍生出来的问题,以Mysql为例
++如何定位并优化慢查询Sql
++联合索引的最左匹配原则
++索引是建立越多越好么
如何定位并优化慢查询Sql
具体场景具体分析,只是提出大致思路
++根据慢日志定位慢查询sql
++使用explain等工具分析sql
++修改sql或者尽量让sql走索引
根据慢日志定位慢查询sql
SHOW VARIABLES LIKE '%quer%'
SHOW STATUS LIKE ‘%slow_queries%’;
打开慢查询日志
SET GLOBAL slow_query_log = ON;
//设置查询时间为一秒钟,如果超过一秒的就给记录到慢查询日志中
SET GLOBAL slow_query_log = 1;
联合索引的最左匹配原则的成因
锁模块之MyISAM与InooDB关于锁方面的区别
锁分为共享锁和排它锁
++MyISAM默认用的时表级锁,不支持行级锁不支持事务
++InnoDB默认用的是行级锁,也支持表级锁支持事务
++Mysql默认自动提交事务
X:排它锁
S:共享锁
1.脏读(Dirty Read)——一个事务读取到了另外一个事务没有提交的数据。
详细解释:当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是脏数据,依据脏数据所做的操作可能是不正确的。
事务T1:更新一条数据
–>事务T2:读取事务T1更新的记录
事务T1:调用commit进行提交
此时事务T2读取到的数据是保存在数据库内存中的数据,称为脏数据,这个过程称为脏读。
脏读发生在一个事务A读取了被另一个事务B修改,但是还未提交的数据。假如B回退,则事务A读取的是无效的数据。这跟不可重复读类似,但是第二个事务不需要执行提交。
解决脏读问题:修改时加排他锁,直到事务提交后才释放,读取时加共享锁,读取完释放事务1读取数据时加上共享锁后(这样在事务1读取数据的过程中,其他事务就不会修改该数据),不允许任何事务操作该数据,只能读取,之后1如果有更新操作,那么会转换为排他锁,其他事务更无权参与进来读写,这样就防止了脏读问题。但是当事务1读取数据过程中,有可能其他事务也读取了该数据,读取完毕后共享锁释放,此时事务1修改数据,修改完毕提交事务,其他事务再次读取数据时候发现数据不一致,就会出现不可重复读问题,所以这样不能够避免不可重复读问题。
2.幻读(Phantom)——同一事务中,用同样的操作读取两次,得到的记录数不相同。
详细解释:幻读是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。
事务T1:查询表中所有记录
–>事务T2:插入一条记录
–>事务T2:调用commit进行提交
事务T1:再次查询表中所有记录
此时事务T1两次查询到的记录是不一样的,称为幻读。
注意:幻读重点在新增或删除。
幻读发生在当两个完全相同的查询执行时,第二次查询所返回的结果集跟第一个查询不相同。
发生的情况:没有范围锁。
如何避免:实行序列化隔离模式,在任何一个低级别的隔离中都可能会发生。
解决幻读问题:采用的是范围锁RangeS RangeS_S模式,锁定检索范围为只读,这样就避免了幻读问题。
3.不可重复读(Nonrepeatable Read)——在同一事务中,两次读取同一数据,得到内容不同。
事务T1:查询一条记录
–>事务T2:更新事务T1查询的记录
–>事务T2:调用commit进行提交
事务T1:再次查询上次的记录
此时事务T1对同一数据查询了两次,可得到的内容不同,称为不可重复读。
注意:不可重复读重点在修改。
在基于锁的并行控制方法中,如果在执行select时不添加读锁,就会发生不可重复读问题。
在多版本并行控制机制中,当一个遇到提交冲突的事务需要回退但却被释放时,会发生不可重复读问题。
有两个策略可以防止这个问题的发生:
(1) 推迟事务2的执行,直至事务1提交或者回退。这种策略在使用锁时应用。
(2) 而在多版本并行控制中,事务2可以被先提交,而事务1继续执行在旧版本的数据上。当事务1终于尝试提交时,数据库会检验它的结果是否和事务1、事务2顺序执行时一样。如果是,则事务1提交成功;如果不是,事务1会被回退。
解决不可重复读问题:读取数据时加共享锁,写数据时加排他锁,都是事务提交才释放锁。读取时候不允许其他事物修改该数据,不管数据在事务过程中读取多少次,数据都是一致的,避免了不可重复读问题。
4.丢失更新(Lost Update)
事务T1读取了数据,并执行了一些操作,然后更新数据。事务T2也做相同的事,则T1和T2更新数据时可能会覆盖对方的更新,从而引起错误。
5.处理以上隔离级别的问题,采用如下方法:
事务隔离五种级别:
(1)TRANSACTION_NONE 不使用事务。
(2)TRANSACTION_READ_UNCOMMITTED 允许脏读。
(3)TRANSACTION_READ_COMMITTED 防止脏读,最常用的隔离级别,并且是大多数数据库的默认隔离级别。
(4)TRANSACTION_REPEATABLE_READ 可以防止脏读和不可重复读。
(5)TRANSACTION_SERIALIZABLE 可以防止脏读,不可重复读取和幻读,(事务串行化)会降低数据库的效率。
以上的五个事务隔离级别都是在Connection接口中定义的静态常量,使用setTransactionIsolation(int level) 方法可以设置事务隔离级别。
如:con.setTransactionIsolation(Connection.REPEATABLE_READ)。
注意:事务的隔离级别受数据库的限制,不同的数据库支持的的隔离级别不一定相同。