数据库索引 锁 死锁

平衡多路查找树 树的左右两边的层级数相差不会大于1 非叶子节值大于左边子节点、小于右边子节点！！！
mysql索引存在硬盘上 b+树子节点才存数据（非叶结点仅具有索引作用），且是有序的（范围查找），层级也不高，减少io  B树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低！！！！！
m阶  中间节点都至少包含ceil(m/2)个孩子，最多有m个孩子  每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m
b+树插入是自下而上，当节点存储大于m-1就分裂，向上级扩展。  删除一样！！小于(m/2)就收缩   三层的B+树就可以存放2千万级别的数据！！！
树存储在硬盘中，每个节点的读取（或访问），都对应一次磁盘IO操作。树的高度就等于每次查询数据时磁盘IO操作的次数。
b+树节点存那些数据 非叶节点存关键字信息，a-z排序找到根节点具体的id，在查主键id索引树！！！

那些操作会锁表
for update 表锁，会锁表

事务

数据库插入过程  

整体过程

死锁 多个进程在运行过程中因争夺资源而造成的一种僵局  a b线程互相获得对方需要的锁 你等我 我等你
互斥条件：一个资源每次只能被一个进程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。！！
不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

超时放弃或有序获取
synchronized关键词提供的内置锁时，只要线程没有获得锁，那么就会永远等待下去
Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法  主动释放之前的锁！！！
Jstack和JConsole可以查看死锁

数据库
悲观锁 for update 和 for update nowait  
乐观锁 一开始假设不会造成冲突，提交的时候再进行数据冲突检测。
innoDB实现了以下两种类型的行锁。
共享锁（s）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。  lock in share  多个事务可以同时为一个对象加共享锁!!!
排他锁（Ｘ）：允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁。  for upadte  其他事务不能在加索
另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。
意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
LOCK tables orders read local,order_detail read local;
Unlock tables;

LOCK IN SHARE MODE

myisam和innodb都支持表级锁。
行级锁只有innodb支持，也是mysql中的最小粒度锁

表级锁
lock table student read;#读锁 unlock tables;#解锁 student表都只能读取 只能执行select操作
lock table balance write;#写锁  一个会话里面都能操作  如果是写锁没有解锁，新的 会话 读写 都处于被锁状态。

行级锁
select xxx lock in share mode;  只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！!!!
排它锁
select xxx for upadte;  打开了排它锁，其他会话依然不能修改数据。但是可以普通的读取

InnoDB 意向共享锁（IS）和意向排他锁（IX） 该事务可以需要锁定行的表上面添加一个合适的意向锁  意向锁是InnoDB自动加的，不需用户干预。
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。

MySQL索引分为普通索引、唯一索引、主键索引、组合索引、全文索引   create index index_name on table(column)；  unique  primary 
索引不会包含有null值的列
组合索引：在多个字段上创建索引，遵循最左前缀原则
MySQL每次查询只使用一个索引!!!  和全表扫描比起来，去分析两个索引B+树更加耗费时间
经常插入、删除、修改的表要减少索引

索引何时失效  explain语句
MySQL能估计出全表扫描比使用索引更快时，不使用索引 ！！！
组合索引未使用最左前缀 例如组合索引（A，B），where B=b不会使用索引；
like未使用最左前缀  以%开头;
搜索一个索引而在另一个索引上做order by，where A=a order by B，只使用A上的索引，因为查询只使用一个索引
or会使索引失效。如果查询字段相同，也可以使用索引。例如where A=a1 or A=a2（生效），where A=a or B=b（失效）！！！！！！！  有or必全有索引！！
在索引列上的操作，函数（upper()等）、or、！=(<>)、not in等；
需要类型转换
where中索引列有运算  where中索引列使用了函数