索引有哪些，用性别做联合索引有没有效果
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。
普通索引、唯一索引、主键索引、全文索引
1.索引加快数据库的检索速度
2.索引降低了插入、删除、修改等维护任务的速度
3.唯一索引可以确保每一行数据的唯一性
4.通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能
5.索引需要占物理和数据空间
什么是事务？
事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。
mysql底层实现原理
你能说一下数据库的主外关联吗？以及它有什么特性呢？
mysql锁机制
实践中如何优化MySQL
① SQL语句及索引的优化
② 数据库表结构的优化
③ 系统配置的优化
④ 硬件的优化
在MySQL中如何定为查询效率较慢的SQL语句
什么情况下设置了索引但无法使用
① 以“%”开头的LIKE语句，模糊匹配
② OR语句前后没有同时使用索引
③ 数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型）
MySQL的常见优化方式、定为慢查询
数据库在使用的时候是如何进行优化的
数据库 SQL 问题，写了几条联结查询的语句，然后分析索引的使用原理之类的
SQL语句的优化
order by要怎么处理
alter尽量将多次合并为一次
insert和delete也需要合并
等等
索引的底层实现原理和优化
B+树，经过优化的B+树
主要是在所有的叶子结点中增加了指向下一个叶子节点的指针，因此InnoDB建议为大部分表使用默认自增的主键作为主索引。
触发器是如何使用的，触发器有什么优点和缺点，通常有什么作用
数据库里面的视图
触发器和函数的区别是什么
说说数据库的索引在你项目里面是怎么使用的
有哪些索引，它们底层是采用什么数据结构去实现的
B树和B+树的区别在哪里
其实二者最主要的区别是:
(1) B+树改进了B树, 让内结点只作索引使用, 去掉了其中指向data record的指针, 使得每个结点中能够存放更多的key, 因此能有更大的出度. 这有什么用? 这样就意味着存放同样多的key, 树的层高能进一步被压缩, 使得检索的时间更短.
(2)当然了,由于底部的叶子结点是链表形式, 因此也可以实现更方便的顺序遍历, 但是这是比较次要的, 最主要的的还是第(1)点.
数据库中表与类的关系，如何存储对象
mysql架构（连接池、查询器、优化器、缓冲器等）
数据库引擎类型与差别
MyISAM是MySQL的默认存储引擎，基于传统的ISAM类型，支持全文搜索，但不是事务安全的，而且不支持外键。每张MyISAM表存放在三个文件中：frm 文件存放表格定义；数据文件是MYD (MYData)；索引文件是MYI (MYIndex)。
InnoDB是事务型引擎，支持回滚、崩溃恢复能力、多版本并发控制、ACID事务，支持行级锁定（InnoDB表的行锁不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，如like操作时的SQL语句），以及提供与Oracle类型一致的不加锁读取方式。InnoDB存储它的表和索引在一个表空间中，表空间可以包含数个文件。
主要区别：
MyISAM是非事务安全型的，而InnoDB是事务安全型的。
MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
MyISAM支持全文类型索引，而InnoDB不支持全文索引。
MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablename type=innodb）。
应用场景：
MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能
数据库索引类型
唯一索引和普通索引差别
数据库的隔离级别，MySQL默认用的哪一级
Mysql 存储引擎以及差别
Mysql索引实现原理
数据库索引什么时候出现失效
简单说一说drop、delete与truncate的区别
SQL中的drop、delete、truncate都表示删除，但是三者有一些差别
1、delete和truncate只删除表的数据不删除表的结构
2、速度,一般来说: drop> truncate >delete
3、delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;
如果有相应的trigger,执行的时候将被触发. truncate,drop是ddl, 操作立即生效,原数据不放到
rollback segment中,不能回滚. 操作不触发trigger.
Mysql ACID具体
ACID — 数据库事务正确执行的四个基本要素
ACID，指数据库事务正确执行的四个基本要素的缩写。
包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易。
原子性：一个事务（Transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的默认规则，这包含资料的精准度、串联新以及后续数据库可以自发性地完成预定的工作。
隔离性：当两个或者多个事务并发访问（此处访问指查询和修改的操作）数据库的同一数据时所表现出的互相关系。事务隔离分为不同的级别，包括读为提交（Read uncommitted）、读提交（Read committed）、可重复读（Repeatable read）和串行化（Serializable）。
持久性：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，而且是完全的。
数据库的隔离级别和传播行为
一、隔离级别
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
１. ISOLATION_READ_UNCOMMITTED：这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
这种隔离级别会产生脏读，不可重复读和幻像读。
２. ISOLATION_READ_COMMITTED：保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
３. ISOLATION_REPEATABLE_READ：这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
４. ISOLATION_SERIALIZABLE：这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
除了防止脏读，不可重复读外，还避免了幻像读。
第1级别：Read Uncommitted(读取未提交内容)
(1)所有事务都可以看到其他未提交事务的执行结果
(2)本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少
(3)该级别引发的问题是——脏读(Dirty Read)：读取到了未提交的数据
第2级别：Read Committed(读取提交内容)
(1)这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）
(2)它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变
(3)这种隔离级别出现的问题是——不可重复读(Nonrepeatable Read)：不可重复读意味着我们在同一个事务中执行完全相同的select语句时可能看到不一样的结果。
|——>导致这种情况的原因可能有：(1)有一个交叉的事务有新的commit，导致了数据的改变;(2)一个数据库被多个实例操作时,同一事务的其他实例在该实例处理其间可能会有新的commit
第3级别：Repeatable Read(可重读)
(1)这是MySQL的默认事务隔离级别
(2)它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行
(3)此级别可能出现的问题——幻读(Phantom Read)：当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行
(4)InnoDB和Falcon存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)机制解决了该问题
第4级别：Serializable(可串行化)
(1)这是最高的隔离级别
(2)它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。
(3)在这个级别，可能导致大量的超时现象和锁竞争
•脏读：一个事务读到另一事务未提交的更新数据。
•不可重复读：一个事务读到另一事务已提交的更新数据。
•幻读：一个事务读到另一事务已提交的新插入的数据。
事务具有ACID四种特性。
但是Isolation并发可能引起如下问题：
1.脏读
允许读取到未提交的脏数据。
2.不可重复读
如果你在时间点T1读取了一些记录，在T2时再想重新读取一次同样的这些记录时，这些记录可能已经被改变、或者消失不见。
3.幻读
解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据，本事务再更新时，就会“惊奇的”发现了这些新数据，貌似之前读到的数据是“鬼影”一样的幻觉。
由ANSI/ISO定义的SQL-92标准定义的四种隔离级别
1.Read Uncommitted
2.Read Committed
3.Repeatable Read
4.Serializable
二、传播行为
1、PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。
2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。‘
3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。
4、PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。
5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
6、PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。
隔离级别，隔离级别如何实现
MySQL有哪些索引
索引的优缺点 什么时候索引不起作用？ 在什么地方可以使用索引？
B+树索引与哈希索引有什么区别
innodb和myisam区别，B+树性质，多列索引及最左前缀原则和其他使用场景
MyISAM 和 InnoDB的适用场景
MyISAM适合：(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。
InnoDB适合：(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。
MyISAM 和 InnoDB的区别
1)MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持
2)myisam表不支持外键
3)在执行数据库写入的操作（insert,update,delete）的时候，myisam表会锁表，而innodb表会锁行
4)当你的数据库有大量的写入、更新操作而查询比较少或者数据完整性要求比较高的时候就选择innodb表。当你的数据库主要以查询为主，相比较而言更新和写 入比较少，并且业务方面数据完整性要求不那么严格，就选择myisam表。因为myisam表的查询操作效率和速度都比innodb要快。
两种存储引擎在索引以及锁机制上的实现方式的区别，limit offset优化，B+树及其查找过程
数据库基本知识（存取控制、触发器、存储过程（了解作用）、游标（了解作用）
并发控制（并发数据不一致性、事务隔离级别、乐观锁与悲观锁等）
说一下数据库事务的四个特性，为什么mysql事务能保证失败回滚
数据库的第一、第二、第三范式
1NF： 字段是最小的的单元不可再分
2NF：满足1NF,表中的字段必须完全依赖于全部主键而非部分主键 (一般我们都会做到)
3NF：满足2NF,非主键外的所有字段必须互不依赖（不能互相推导）
4NF：满足3NF,消除表中的多值依赖
冗余举个例子
mysql：索引，事务隔离级别，组合索引在什么情况下失效
mysql数据库的锁有多少种，怎么编写加锁的sql语句
mysql什么情况下会触发表锁
mysql中索引失效的情况
mysql 索引原理。为什么索引一部分放到内存，一部分放到硬盘上？
现在有一个很多个表进行关联查询的sql，子表的数据非常的多，那么请问你仅仅从sql的角度去进行sql语句的优化，不需要考虑索引、谓词
现在有10亿条数据的一张表，请你设计一种方案快速的将这些表中的数据搬迁到另一个数据库中
数据库同步你做过哪些方案，各有什么优缺点
现在有两张表（记不太清楚了），问怎么查询才能保证查询效率最高
页锁、乐观锁、悲观锁
数据库的悲观锁和乐观锁
悲观锁：对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系 统不会修改数据）。
乐观锁：大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。
乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
数据库设计，假如做一个通信录，每个用户可能有多个联系方式（比如有微信，qq，facebook，人人等，每个用户可能全有，可能也只有其中 一部分，后面也看新增类似字段）。如果每个字段给一列，这样活很浪费，问这么设计表。
方案有两种：
（1）另外单独设计一张表，外键关联到用户表，里面有一个类型字段标识是微信还是qq还是facebook等，第二个字段是账号内容
（2）直接放在用户表中，设计一个字段存放一个json数据，json格式为{“微信”：xxxx， qq：“xxx"....}
