MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。在Java企业级开发中非常常用，因为 MySQL 是开源免费的，并且方便扩展。
你知道MySQL索引吗？数据库索引是一种单独的、物理的 对数据库表中一列或多列的值进行排序的一种存储结构，
你可以认为它类似于一本书的目录，你可以通过目录轻易的找到你所要的内容。
主键索引: 数据列不允许重复，不允许为NULL，一个表只能有一个主键。
唯一索引: 数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。
可以通过 ALTER TABLE table_name ADD UNIQUE (column); 创建唯一索引可以通过 ALTER TABLE table_name ADD UNIQUE (column1,column2); 创建唯一组合索引
普通索引: 基本的索引类型，没有唯一性的限制，允许为NULL值。
可以通过ALTER TABLE table_name ADD INDEX index_name (column);创建普通索引可以通过ALTER TABLE table_name ADD INDEX index_name(column1, column2,
column3);创建组合索引
全文索引： 是目前搜索引擎使用的一种关键技术。
可以通过ALTER TABLE table_name ADD FULLTEXT (column);创建全文索引 你平时是怎么创建索引的？
索引虽好，但也不是无限制的使用，最好符合一下几个原则
- 最左前缀匹配原则，组合索引非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。较频繁作为查询条件的字段才去创建索引索引字段越小越好，数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大效率越高。更新频繁字段不适合创建索引若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。定义有外键的数据列一定要建立索引。对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。对于定义为text、image和bit的数据类型的列不要建立索引。
我们想要删除百万数据的时候可以先删除索引（此时大概耗时三分多钟）然后删除其中无用数据（此过程需要不到两分钟）删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分钟左右。与直接删除相比绝对是要快速很多，更别说万一删除中断,一切删除会回滚。那更是坑了。 什么是最左前缀原则？
B+树的节点存储索引顺序是从左向右存储，在匹配的时候自然也要满足从左向右匹配；通常我们在建立联合索引的时候，也就是对多个字段建立索引，相信建立过索引的同学们会发现，无论是Oracle还是 MySQL 都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，a、b、c,或者是b、a、c 或者是c、a、b等顺序。
在我们开发中经常会遇到明明这个字段建了联合索引，但是SQL查询该字段时却不会使用索引的问题。比如索引abc_index:(a,b,c)是a，b，c三个字段的联合索引，下列sql执行时都无法命中索引abc_index的；
select * from table where c = '1'; select * from table where b ='1' and c ='2';
以下三种情况却会走索引:
select * from table where a = '1'; select * from table where a = '1' and b = '2'; select * from table where a = '1' and b = '2' and c='3';
最左前缀：顾名思义，就是最左优先，上例中我们创建了a_b_c多列索引，相当于创建了(a)单列索引，(a,b)组合索引以及(a,b,c)组合索引。
说说B树和B+树的区别B+树内节点不存储数据，所有 data 存储在叶节点导致查询时间复杂度固定为 log n。而B-树查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1)。B+树叶节点两两相连可大大增加区间访问性，可使用在范围查询等，而B-树每个节点 key 和 data 在一起，则无法区间查找。B+树更适合外部存储。由于内节点无 data 域，每个节点能索引的范围更大更精确
什么是数据库事务？事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位，其执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。事务是逻辑上的一组操作，要么都执行，要么都不执行。
事务最经典也经常被拿出来说例子就是转账了。
假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。
事物的四大特性(ACID)介绍一下?原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；一致性： 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；隔离性： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；持久性： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
什么是脏读？幻读？不可重复读？脏读(DrityRead)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。不可重复读(Non-repeatableread):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。幻读(PhantomRead):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 什么是事务的隔离级别？MySQL的默认隔离级别是什么？
READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
Mysql 默认采用的 REPEATABLE_READ 可重复读 隔离级别
Oracle 默认采用的 READ_COMMITTED 读取已提交 隔离级别
锁表产生的原因是：A程序执行了对 table 的 insert ，并还未 commite时，B程序也对table 进行insert 则此时会发生资源正忙的异常，锁表常发生于并发中；
解决：
--查询被锁住的表 SELECt request_session_id as spid,OBJECT_NAME(resource_associated_entity_id) as tableName FROM sys.dm_tran_locks WHERe resource_type='OBJECT' --解表（解锁） declare @spid int set @spid = 锁表进程 declare @sql varchar(1000) set @sql='kill '+cast(@spid as varchar) exec(@sql)UNIOn与UNIOn ALL的区别？
Union：对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
Union All：对两个结果集进行并集操作，包括重复行，不进行排序；
创建的索引有没有被使用到?怎么才可以知道这条语句运行很慢的原因？分析mysql慢查询日志 ,利用explain关键字可以模拟优化器执行SQL查询语句，来分析sql慢查询语句
mysql> EXPLAIN SELECt * from admin_user where app_name like '%熊%' ; +----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | 1 | SIMPLE | admin_user | NULL | ALL | NULL | NULL | NULL | NULL | 1377809 | 11.11 | Using where | +----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+ 1 row in set, 1 warning (0.00 sec)
各列属性的简介：
id:SELECT的查询序列号，体现执行优先级，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行select_type:表示查询的类型。table:输出结果集的表，如设置了别名，也会显示partitions:匹配的分区type:对表的访问方式possible_keys:表示查询时，可能使用的索引key:表示实际使用的索引key_len:索引字段的长度ref:列与索引的比较rows:扫描出的行数(估算的行数)filtered:按表条件过滤的行百分比Extra:执行情况的描述和说明
标粗的就是我们常用的 老板说了，线上再出现慢查询，开发就滚蛋！ 详细学习请参考链接
什么时候会索引失效？- 尽量避免在字段开头模糊查询，会导致数据库引擎放弃索引进行全表扫描；尽量避免使用in 和not in，会导致引擎走全表扫描；尽量避免使用 or，会导致数据库引擎放弃索引进行全表扫描；尽量避免进行null值的判断，会导致数据库引擎放弃索引进行全表扫描；尽量避免在where条件中等号的左侧进行表达式、函数操作，会导致数据库引擎放弃索引进行全表扫描；当数据量大时，避免使用where 1=1的条件；查询条件不能用 <> 或者 !=；order by 条件要与where中条件一致，否则order by不会利用索引进行排序。
对于MySQL层优化我一般遵从五个原则：
- 减少数据访问： 设置合理的字段类型，启用压缩，通过索引访问等减少磁盘IO返回更少的数据： 只返回需要的字段和数据分页处理 减少磁盘io及网络io减少交互次数： 批量DML操作，函数存储等减少数据连接次数减少服务器CPU开销： 尽量减少数据库排序操作以及全表查询，减少cpu 内存占用利用更多资源： 使用表分区，可以增加并行操作，更大限度利用cpu资源
