工做的的缘由，还有本身不努力学习（哈哈哈）尽可能引导面试官问ssm的框架
文章是对我 这个星期，5天面试的总结
先说mysql
html
mysql：原文的地址
1.引擎
2.索引
3.隔离级别
4.锁
mysql
1.存储引擎
一 Innodb（mysql默认引擎）
支持事务，是事务安全的，提供行级锁与外键约束，有缓冲池，用于缓冲数据和索引
适用场景：用于事务处理，具备ACID事物支持，应用于执行大量的insert和update操做的表
二 MyISAM
不支持事务，不支持外键约束，不支持行级锁，操做时须要锁定整张表，不过会保存表的行数，因此当执行select count(*) from tablename时执行特别快
适用场景：用于管理非事务表，提供高速检索及全文检索能力，适用于有大量的select操做的表，如 日志表
三 MEMORY
使用存在于内存中的内容建立表，每个memory只实际对应一个磁盘文件。该引擎使用hash索引，能够一次定位，不须要像B树同样从根节点查找到支节点，因此精确查询时访问速度特别快，可是非精确查找时，好比like，这种范围查找，hash就起不到做用了。
适用场景：主要用于内容变化不频繁的表，或者做为中间的查找表。对表的更新要谨慎由于数据没有被写入到磁盘中，服务关闭前要考虑好数据的存储
四 MERGE
MERGE存储引擎把一组MyISAM数据表当作一个逻辑单元来对待，让咱们能够同时对他们进行查询。构成一个MERGE数据表结构的各成员MyISAM数据表必须具备彻底同样的结构。每个成员数据表的数据列必须按照一样的顺序定义一样的名字和类型，索引也必须按照一样的顺序和一样的方式定义。
面试
2、索引种类
普通索引：仅加速查询
惟一索引：加速查询 + 列值惟一（能够有null）
主键索引：加速查询 + 列值惟一（不能够有null）+ 表中只有一个
组合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并
建立索引的时机：
MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引
索引不生效的状况:
一、使用like关键字模糊查询时，第一个位置是任意字符
三、OR先后的两个条件中的列都是索引时，索引才会生效。
四、尽可能避免在where子句中使用!=或<>操做符，不然全表扫描。
五、在 where 子句中对字段进行表达式 , 函数操做，不然全表扫描。
六、order by 索引 ，不起做用的问题（除了主键索引以外）：
一、 若是select 只查询索引字段，order by 索引字段会用到索引，要否则就是全表排列；
二、若是有where 条件，好比where vtype=1 order by vtype asc . 这样order by 也会用到索引！
组合索引？在哪些场景中，组合索引会失效:
一、组合索引字段不管顺序如何改变都会用到索引，前提是全部字段都在where条件上
二、若是想要使用一个或者两个字段在where条件上，必须有组合索引里的第一个字段，可是与顺序无关，例如a,c或c,a，这种场景是能够命中索引的。可是，b,c或c,b这种是不会命中索引的。。
三、order by 只能使用a，才能用到索引
mysql的优化方法：
建立表考虑的问题：
一、选择最合适的字段属性
二、尽可能把字段设置为NOT NULL
3 使用链接(JOIN)来代替子查询
4.链接查询推荐：inner join（内链接）
5.建立合适的索引
sql
优化SQL的查询语句
1 不使用子查询
2 避免函数索引
3 用IN来替换OR
4 LIKE第一个位置是任意字符没法使用到索引
6 避免数据类型不一致
7 分组统计能够禁止排序
8 禁止没必要要的ORDER BY排序
9 批量INSERT插入
数据库
为何子查询比链接查询（LEFT JOIN）效率低：
执行子查询时，MYSQL须要建立临时表，查询完毕后再删除这些临时表，因此，子查询的速度会受到必定的影响，这里多了一个建立和销毁临时表的过程
安全
事务：
原子性：一个事物(transaction)中的全部操做，要么所有完成，要么所有不完成，不会结束在中间某个环节。事务在执行过程当中发生错误，会被回滚(Rollback)到事务开始的状态，就像这个事务历来没有执行过同样。
一致性：在事务开始以前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须彻底符合全部的预设规则，这包含资料的精确度、串联性以及后续数据库能够自发性地完成预约的工做。
隔离性：数据库容许多个事务同时对其数据进行读写和修改的能力，隔离性能够防止多个事务并发执行时因为交叉执行而致使数据的不一致。事务隔离分为不一样的级别，包括读未提交(Read uncommitted)、读已提交(Read committed)、可重复读(repeateable read)和串行化(Serializable).
持久性：事务处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失。
并发
事务隔离级别
读未提交
读已提交
可重复读
串行化
产生的问题：
一、脏读：事务A读取了事务B更新的数据，而后B回滚操做，那么A读取到的数据就是脏数据
二、不可重复读：事务A屡次读取同一事物，事务B在事务A屡次读取的过程当中，对数据作了更新并提交，致使事务A屡次读取同一数据时，结果不一致。
三、幻读：系统管理员A将数据库中的全部学生的成绩从具体分数改成ABCDE等级，可是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉同样，这就叫幻读。
框架
锁
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。而且该索引不能失效，不然都会从行锁升级为表锁函数
行锁
行锁的劣势：开销大；加锁慢；会出现死锁
行锁的优点：锁的粒度小，发生锁冲突的几率低；处理并发的能力强
加锁的方式：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；固然咱们也能够显示的加锁：
共享锁：select * from tableName where … + lock in share more
排他锁：select * from tableName where … + for update
排他锁
排他锁，也称写锁，独占锁，当前写操做没有完成前，它会阻断其余写锁和读锁。
共享锁
共享锁，也称读锁，多用于判断数据是否存在，多个读操做能够同时进行而不会互相影响。当若是事务对读锁进行修改操做，极可能会形成死锁。
高并发
分析行锁定
经过检查InnoDB_row_lock 状态变量分析系统上的行锁的争夺状况
innodb_row_lock_current_waits: 当前正在等待锁定的数量
innodb_row_lock_time: 从系统启动到如今锁定总时间长度；很是重要的参数，
innodb_row_lock_time_avg: 每次等待所花平均时间；很是重要的参数，
innodb_row_lock_time_max: 从系统启动到如今等待最常的一次所花的时间；
innodb_row_lock_waits: 系统启动后到如今总共等待的次数；很是重要的参数。直接决定优化的方向和策略
行锁优化
1 尽量让全部数据检索都经过索引来完成，避免无索引行或索引失效致使行锁升级为表锁。
2 尽量避免间隙锁带来的性能降低，减小或使用合理的检索范围。
3 尽量减小事务的粒度，好比控制事务大小，而从减小锁定资源量和时间长度，从而减小锁的竞争等，提供性能。
4 尽量低级别事务隔离，隔离级别越高，并发的处理能力越低。
表锁
表锁的优点：开销小；加锁快；无死锁
表锁的劣势：锁粒度大，发生锁冲突的几率高，并发处理能力低
加锁的方式：自动加锁。查询操做（SELECT），会自动给涉及的全部表加读锁，更新操做（UPDATE、DELETE、INSERT），会自动给涉及的表加写锁。也能够显示加锁：
共享读锁：lock table tableName read;
独占写锁：lock table tableName write;
批量解锁：unlock tables;
共享读锁
对MyISAM表的读操做（加读锁），不会阻塞其余进程对同一表的读操做，但会阻塞对同一表的写操做。只有当读锁释放后，才能执行其余进程的写操做。在锁释放前不能取其余表。
独占写锁
对MyISAM表的写操做（加写锁），会阻塞其余进程对同一表的读和写操做，只有当写锁释放后，才会执行其余进程的读写操做。在锁释放前不能写其余表。
什么场景下用表锁 InnoDB默认采用行锁，在未使用索引字段查询时升级为表锁。 第一种状况：全表更新。 第二种状况：多表查询。 总结 1 InnoDB 支持表锁和行锁，使用索引做为检索条件修改数据时采用行锁，不然采用表锁。 2 InnoDB 自动给修改操做加锁，给查询操做不自动加锁 3 行锁可能由于未使用索引而升级为表锁，因此除了检查索引是否建立的同时，也须要经过explain执行计划查询索引是否被实际使用。 4 行锁相对于表锁来讲，优点在于高并发场景下表现更突出，毕竟锁的粒度小。 5 当表的大部分数据须要被修改，或者是多表复杂关联查询时，建议使用表锁优于行锁。 6 为了保证数据的一致完整性，任何一个数据库都存在锁定机制。锁定机制的优劣直接影响到一个数据库的并发处理能力和性能。