数据库的基本是概念名词解释：
元组：可以理解为表的每一行就是一个元组
候选码：若关系中的某一属性组的值能够唯一标识一个元组，而其子集不能，则称该属性组为候选码
主码：若一个关系中有多个候选码，选择其中一个作为主码；候选码中各种属性称为主属性，不包含在任何候选码中的属性称为非主属性 或 非码属性
主键：若某一个属性组（注意是组）能唯一标识一条记录，该属性组就是一个主键。主键不能重复，且只能有一个，也不允许为空。定义主键主要是为了维护关系数据库的完整性。
外键: 外键用于与另一张表的关联，是能确定另一张表记录的字段。外键是另一个表的主键，可以重复，可以有多个，也可以是空值。定义外键主要是为了保持数据的一致性。
1.事务四大特性（ACID），数据库隔离级别，每个级别会引发什么问题，mysql默认是哪个级别
参考：数据库事务的四大特性以及事务的隔离级别 - fjdingsd - 博客园
事务：指逻辑上的一组操作，组成这组操作的各个单元，要不全部成功，要不全部不成功。
四大特性：
（1）原子性（Atomicity）：原子性是指一个操作是不可中断的，事务包含的所有操作要么全部成功，要么全部失败回滚
（2）一致性（Consistency）：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
（3）隔离性（Isolation）：隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
数据库隔离级别：
MySQL数据库为我们提供的四种隔离级别：
① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。(最高级别，级别越高执行效率越低)
② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。（ MySQL数据库默认的级别 ）
③ Read committed (读已提交)：可避免脏读的发生。
④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
(注释：a. 脏读 : 指在一个事务处理过程里读取了另一个未提交的事务中的数据
b. 不可重复读 :不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。
c. 虚读(幻读) : 幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。简单来说，幻读是由插入或者删除数据引起的)
.一般解决幻读的方法是增加范围锁RangeS，锁定检锁范围为只读，这样就避免了幻读
（4）持久性（Durability）：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
2.MYSQL的两种存储引擎区别（事务、锁级别等等），各自的适用场景
Mysql在V5.1之前默认存储引擎是MyISAM；在此之后默认存储引擎是InnoDB
MyISAM：（MyISAM表不太适合于有大量更新操作和查询操作应用，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。这种情况有时可能会变得非常糟糕！）
（1）不支持事务，但是每次查询都是原子的；
（2）支持表级锁，即每次操作是对整个表加锁；
（3）存储表的总行数；
（4）一个MYISAM表有三个文件：索引文件、表结构文件、数据文件；
（5）采用非聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性。
InnoDb：（提供了具有提交、回滚和崩溃恢复能力的事务安全，但是写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。）
InnoDB中主键索引 使用的是 B+Tree，而 非主键索引（辅助索引）使用的是 B-Tree 数据结构
（1）支持ACID的事务：支持事务的四种隔离级别；
（2）支持行级锁及外键约束：因此可以支持写并发；
（3）不存储总行数；
（4）一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；
（5）主键索引采用聚集索引（索引的数据域存储数据文件本身，按照每张表的主键构造一棵B+树，树中的叶子节点存放着表中的行记录数据）；辅索引也是一颗B+树，只不过树中的叶子节点存放着主键的值和一个书签号，这个书签用来告诉InnoDB引擎从哪里可以找到与索引相对应的行数据；innodb表必须指定主键，建议使用自增数字，防止插入数据时，为维持B+树结构，文件的大调整。
MySQL的InnoDB索引原理详解 - jimshi - 博客园
3.数据库的优化（从sql语句优化和索引两个部分回答）
MYSQL学习笔记——sql语句优化之索引 - Tim-Tom - 博客园
一. SQL语句优化
二.索引的优化（建立索引的原则）
（1）表的主键、外键必须有索引；（ 两张表要想有着某种联系，需要设定主键和外键两个属性；外键特点：从表 外键的值是对主表 键的引用，从表外键类型，必须与主表主键类型一致 ）
（2）数据量超过300的表应该有索引；
（3）经常与其他表进行连接的表，在连接字段上应该建立索引；
（4）经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
（5）尽量选择区分度高的列作为索引，（例如像男，女这种区分度很少的字段不适合）区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少
（6）索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；例如，对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。
（7）复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替
（8）多列字段索引时，采用最左前缀匹配原则（ 所谓最左前缀原则就是在多列字段做索引时候（例如：state，city，zipCode），想要索引生效的话先要看第一列state，在第一列满足的条件下再看左边第二列city，以此类推。其他方式（如city，city/ipCode），则索引不会生效 ）
索引的理解
4.索引有B+索引和hash索引，各自的区别
（1）如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
（2）如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
（3） 同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
（4）哈希索引也不支持多列联合索引的最左匹配规则；
（5）B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。
5.B+索引数据结构，和B树的区别
参考：【经典数据结构】B树与B+树 - vincently - 博客园
（1）B 树可以看作是对2-3查找树的一种扩展
一个 m 阶的B树满足以下条件：
1）每个结点至多拥有m棵子树；
2）根结点至少拥有两颗子树（存在子树的情况下）；
3）除了根结点以外，其余每个分支结点至少拥有 m/2 棵子树；
4）所有的叶结点都在同一层上；
5）有 k 棵子树的分支结点则存在 k-1 个关键码，关键码按照递增次序进行排列；（还剩那一个码位表示关键码的个数n）
6）关键字数量n需要满足【m/2】-1 <= n <= m-1； 【m/2】表示不小于m/2的整数
（2）B+树是对B树的一种变形树，以一个m阶树为例：
1）根结点只有一个，分支数量范围为[2，m]；
2）分支结点，每个结点包含分支数范围为【 [m/2] , m 】；
3）分支结点的关键字数量等于其子分支的数量减一，关键字的数量范围为【 [(m/2)-1] , m-1 】，关键字顺序递增；所有分支节点都可以看成是索引，节点中仅含有其子树中最大或最小的关键字。
4）所有叶子结点都在同一层；树的所有叶结点构成一个有序链表，可以按照关键码排序的次序遍历全部记录。
为什么要B+树？
由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引，而B树则常用于文件索引。
B树和B+树的区别
这都是由于B+树和B具有这不同的存储结构所造成的区别，以一个m阶树为例。
（1）关键字的数量不同；B+树中有 k 棵子树的分支结点则存在 k个关键码，关键码按照递增次序进行排列；其关键码只是起到了一个索引的作用，但是B树有 k 棵子树的分支结点则存在 k-1 个关键码，关键码按照递增次序进行排列；
（2）存储的位置不同；B+树中的数据都存储在叶子结点上，也就是其所有叶子结点的数据组合起来就是完整的数据，但是B树的数据存储在每一个结点中，并不仅仅存储在叶子结点上。
（3）分支结点的构造不同；B+树的分支结点仅仅存储着关键字信息和儿子的指针（这里的指针指的是磁盘块的偏移量），也就是说内部结点仅仅包含着索引信息。
（4）查询不同；B树在找到具体的数值以后，则结束，而B+树则需要通过索引找到叶子结点中的数据才结束，也就是说B+树的搜索过程中走了一条从根结点到叶子结点的路径。
6.索引的分类（主键索引、唯一索引），最左前缀原则，哪些情况索引会失效
索引只要创建了，就会自动调用；order by即distinc或是like等，都不会使用索引。也就是说，索引对于他们是无效的
MySQL目前主要有以下几种索引类型：MySQL索引类型 - 成九 - 博客园
（1）聚集索引：指数据行中数据的物理顺序与索引的逻辑顺序相同。一个表只能有一个聚集索引，因为一个表的物理顺序只有一种情况，所以，对应的聚集索引只能有一个
（2）非聚集索引：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。（非聚集索引包括 普通索引，唯一索引，全文索引）
1）普通索引：这是最基本的索引，它没有任何限制，
2）唯一索引：索引的每一个索引值只对应唯一的数据记录；索引列的值必须唯一，但允许有空值（注意和主键不同）（ create unique index stusno on Student(Sno) ,建立唯一索引stusno）
3）全文索引：主要用来查找文本中的关键字，而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用，而不是一般的where语句加like。
（3）组合索引（最左前缀）：指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合
所谓最左前缀原则就是在多列字段做索引时候（例如：state，city，zipCode），想要索引生效的话先要看第一列state，在第一列满足的条件下再看左边第二列city，以此类推。其他方式（如city，city/ipCode），则索引不会生效
（4）B+树索引：将索引属性组织成B+树的形式
（5）哈希索引：建立若干个桶，将索引属性按照其散列函数值映射到相应的桶中去，桶中存放索引属性值和相应的元组指针，查找速度很快。
7.聚集索引和非聚集索引区别
两者的根本区别是 表记录的排列顺序 与 索引的排列顺序 是否一致。
（1）聚集（clustered）索引：表记录的排列顺序和索引的排列顺序一致，一个表中只能拥有一个聚集索引。
聚集索引就像是字典的拼音目录，对应的A-Z的字顺序 和 字典实际存储的字的顺序A-Z也是一样的，
而 非聚集（unclustered）索引: 表记录的排列顺序和索引的排列顺序不一致，一个表中可以拥有多个非聚集索引。 非聚集索引就像新华字典的偏旁字典，它的结构顺序与实际存放顺序不一定一致。
（3）聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续。
（4）聚集索引查询数据速度快，插入数据速度慢；非聚集索引反之。
8.有哪些锁（乐观锁悲观锁），select时怎么加排它锁
乐观锁和悲观锁。乐观锁即乐观并发控制，悲观锁即悲观并发控制，他们是处理并发控制时主要采用的技术手段。其中，悲观锁正是数据库本身提供的锁机制实现的。
(1) 悲观锁（Pessimistic Concurrency Control）缩写为PCC--------就是每次当前事务去读取数据的时候都认为别的事务可能会对数据进行修改，所以每次在读取数据的时候都会上锁，这样别的事务想拿这个数据就会进入阻塞状态，直到它拿到锁。在传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这对于长事务来讲，可能会严重影响系统的并发处理能力
(2) 乐观锁(Optimistic Concurrency Control)缩写为OCC，从字面意义上理解，每次当前事务去读取数据的时候都认为别的事务不会对数据进行修改，所以不会上锁，只在数据进行提交更新的时候，才会正式对数据是否被改变进行检测，如果发现被改变了，则宣告失败进行回滚，否则就更新数据。相对于悲观锁，乐观锁在处理数据库时，不会使用数据库提供的锁机制，一般事项乐观锁的的方式就是记录数据版本。这就要求避免使用长事务和锁机制，以免导致系统并发处理能力降低，保障系统生产效率。
select如何加排它锁：
用法： select … for update;
例如：select * from goods where id = 1 for update;
9.关系型数据库和非关系型数据库区别
（1）关系型数据库通过外键关联来建立表与表之间的关系，
（2）非关系型数据库通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定
（3）非关系型数据库中，我们查询一条数据，结果出来一个数组，关系型数据库中，查询一条数据结果是一个对象。
10.了解nosql
指的是非关系型的数据库，是对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
（1）键值(Key-Value)存储数据库，这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据
（2）列存储数据库，这部分数据库通常是用来应对分布式存储的海量数据
（3）文档型数据库，该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储
（4）图形(Graph)数据库，它是使用灵活的图形模型，并且能够扩展到多个服务器上
总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
11.数据库三范式
（1）第一范式（1NF）：确保每一列的原子性，如果每一列都是不可再分的最小数据单元，则满足第一范式。
（2）第二范式（2NF）:在1NF基础上，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
（3）第三范式（3NF）：在2NF基础上，非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。（在2NF基础上消除传递依赖）
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。
（4）BCNF 巴斯-科德范式 ：任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）
巴斯-科德范式（BCNF）是第三范式（3NF）的一个子集，即满足巴斯-科德范式（BCNF）必须满足第三范式（3NF）
12.数据库的主从复制
简单的总结就是：主服务器将数据变动写入到一个二进制日志中去，从服务器通过I/O线程读取主服务器的二进制日志写入到从服务器的中继日志中，再读取中继日志中的数据放入自己的数据库中。
13.使用explain优化sql和索引
Explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，Explain可以用来查看SQL语句的执行效 果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。 使用 explain 关键字可以模拟优化器执行 sql 查询语句，从而得知 MySQL 是如何处理 sql 语句。
使用方法： explain + 待执行的sql
14.设置long_query_time的值无效的原因及解决方法
15.（连接查询）------- 内连接、外连接、交叉连接、笛卡儿积等
(1) 内连接(INNER JOIN)： join默认的连接
分为三种：
等值连接 : 在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结果中列出被连接表中的所有列，包括其中的重复列。
非等值连接 : 在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括 >、>=、<=、<、!>、!<和<>。
自然连接 : 在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选择列表指出查询结果集合中所包括的列，并删除连接表中的重复列。
(2) 外连接(OUTER JOIN)：
分为三种：
左外连接(LEFT OUTER JOIN或LEFT JOIN) :左向外联接的结果集包括 LEFT OUTER子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值。
右外连接(RIGHT OUTER JOIN或RIGHT JOIN) ：右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。
全外连接(FULL OUTER JOIN或FULL JOIN) ：返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。
(3) 交叉连接(CROSS JOIN)： 交叉联接返回左表中的所有行，左表中的每一行与右表中的所有行组合。交叉联接也称作笛卡尔积。 没有WHERE 子句，它返回连接表中所有数据行的笛卡尔积
16.MVCC机制
MVCC是一种多版本并发控制机制，MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销. 在MVCC协议下，每个读操作会看到一个一致性的snapshot，并且可以实现非阻塞的读（读取时非阻塞是目的，因为一般情况下为了保证数据在并行读取时候的一致性，读操作会被写操作阻塞，影响效率）。
实现：InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，每开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.
17.根据具体场景，说明版本控制机制 数据库开发中的版本控制_风过无痕_新浪博客
为什么要把数据库版本控制起来？
一、最重要的就是，多人可以随便修改执行存储过程或者函数。（当前需要辅助以安全控制机制）
二、数据库版本化演进，如果已经上线的数据库，版本化就很重要，讲应用程序和数据库置于同一个版本控制之下，这样可以在开发中很容易追溯到已经发布的程序中出现的问题。
三、容易追踪人员对数据库的相关更改。
18.死锁产生的必要条件，死锁怎么解决
（1）互斥条件：某资源只能被一个进程使用，其他进程请求该资源时，只能等待，知道资源使用完毕后释放资源。
（2）占有并等待条件：程序已经保持了至少一个资源，但是又在等待另外一个资源，而这个资源被其他进程占用，自己占用资源却保持不放。
（3）不可抢占条件：进程已获得的资源没有使用完，不能被抢占。
（4）循环等待条件：存在了一个循环链。
解决死锁只需要破坏四个条件中的一个就行了
19. varchar和char的使用场景
Varchar：往往用来保存可变长度的字符串。简单的说，我们只是给其固定了一个最大值，然后系统会根据实际存储的数据量来分配合适的存储空间（VARCHAR数据类型会多用1个字节用来存储长度信息）
CHAR：采用的是固定长度的存储方式。简单的说，就是系统总为其分配最大的存储空间。当数据保存时，即使 其没有达到最大的长度，系统也会为其分配这么多的存储空间。
应用场景：char 固定长度，所以在处理速度上要比varchar快速很多，但是对费存储空间，所以对存储不大，但在速度上有要求的可以使用char类型，反之可以用varchar类型来实例。
20.mysql并发情况下怎么解决
通过事务、隔离级别、锁
21.Redis
Redis 总结精讲 看一篇成高手系统-4 - CSDN博客
为什么redis这么快？
(一)纯内存操作
(二)单线程操作，避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制
（1）redis数据结构有哪些
1）String： 可以是字符串，整数或者浮点数，对整个字符串或者字符串中的一部分执行操作，对整个整数或者浮点执行自增(increment)或者自减(decrement)操作。
2）list ：一个链表，链表上的每个节点都包含了一个字符串，虫链表的两端推入或者弹出元素，根据偏移量对链表进行修剪(trim)，读取单个或者多个元素，根据值查找或者移除元素。
3）set：包含字符串的无序收集器(unordered collection)、并且被包含的每个字符串都是独一无二的。添加，获取，移除单个元素，检查一个元素是否存在于集合中，计算交集，并集，差集，从集合里面随机获取元素。
4）hash：包含键值对无序散列表，添加，获取，移除当键值对，获取所有键值对。
5）zset：字符串成员(member)与浮点数分值(score)之间的有序映射，元素的排列顺序由分值的大小决定。添加，获取，删除单个元素，根据分值范围(range)或者成员来获取元素。
（2）redis队列应用场景
通过消息队列，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务，改善网站系统的性能。
（3）redis和Memcached的区别（支持数据持久化）
1）、Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等；
2）、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储；
3）、虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；
4）、过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10；
5）、分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从；
6）、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；
7）、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；
8）、Redis支持数据的备份，即master-slave模式的数据备份；
9）、应用场景不一样：Redis出来作为NoSQL数据库使用外，还能用做消息队列、数据堆栈和数据缓存等；Memcached适合于缓存SQL语句、数据集、用户临时性数据、延迟查询数据和session等。
22. join和union区别
join： 是两张表做交连后里面条件相同的部分记录产生一个记录集，
union：UNION 是将已经产生的两个记录集(字段要一样的)并在一起，成为一个新的记录集 。
23. 查看SQL执行计划 SQL：执行计划的几种方法 - CSDN博客
(1) set autotrace （需要执行sql)
(2) explain plan for
24. 有十万条数据, 写SQL语句查询其中某字段较大值的几条数据（没优化的）
select * from table where date = (select date from table order by date desc limit 10 ）
注释： ASC（升序） 或 DESC（降序）
25. 子查询与连接查询（关联查询）的区别
子查询是将一个查询语句嵌套在另外一个查询语句中，内层查询语句的查询结果，可以为外层查询语句提供查询条件。
（1）表连接都可以用子查询，但不是所有子查询都能用表连接替换，
（2）子查询比较灵活，方便，形式多样，适合用于作为查询的筛选条件，而表连接更适合与查看多表的数据；
（3）子查询不一定需要有关联字段，而连接查询必须有字段关联（所谓的主外键关系）
（4）连接查询的效率在大多数情况下要明显优于子查询
26.索引的作用及索引的数据结构
索引的作用及索引的数据结构 - Burning_Leaf - 博客园
（1）mysql索引的用途：
保持数据的完整性；
优化数据的访问性能
改进表的链接（join）操作
对结果进行排序
简化聚合数据操作
（2）索引的数据结构： B树、B+树、哈希表（散列表）、R-
索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是一种数据结构。
1）B树结构-------支持插入、控制操作以及通过管理一系列树根状结构的彼此联通的节点中来做选择。B-树结构中有两种节点类型：索引节点和叶子节点。叶子节点是存储数据的，而索引节点是用来告诉用户存储在叶子节点中的数据的顺序，并帮助用户找到数据。B-树不是二叉树，二叉树只是一种简单的节点层次结构的实现。（B树索引实现是一个专门为范围查询设计的，是用于磁盘级查找最流行的数据结构）
2）B+树--------是B-树结构的增强版，尽管B+树支持B-树的所有特性，他们之间最显著的不同点在于B+树中底层数据是按照提及的索引列进行排序的。B+树还通过在叶子节点之间附加引用来优化扫描的性能。 （MyISAM索引实现，和InnoDB索引实现都是B+树结构，但是实现方式完全不一样：（1）第一个重大区别是InnoDB的数据文件本身就是索引文件，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶结点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。（2）第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。）
3）哈希表（散列表）--------哈希表数据结构是一个简单的概念，他将一种算法应用到给定值中以在底层数据存储系统中返回一个唯一的指针或位置。哈希表的优点是始终以线性时间复杂度找到需要读取的行的位置，而不想B-树那样需要跨越多层节点来确定位置。（散列实现对直接查找方式能提供最优的性能，但对一定范围的查找却效率底下）
4）通信R-树------R-树数据结构支持基于数据类型对集合数据进行管理。目前只有MyIsam使用R-树支持空间索引。使用空间索引也有很多限制，比如只支持唯一的NOT NULL 列等。空间索引并不常用。
27. 数据库高并发访问方法
大数据量高并发的数据库优化详解(MSSQL) - 洛晨随风 - 博客园
28. 为什么要把数据库版本控制起来？
一、最重要的就是，多人可以随便修改执行存储过程或者函数。（当前需要辅助以安全控制机制）
二、数据库版本化演进，如果已经上线的数据库，版本化就很重要，讲应用程序和数据库置于同一个版本控制之下，这样可以在开发中很容易追溯到已经发布的程序中出现的问题。
三、容易追踪人员对数据库的相关更改。
29. 常用数据库语句
（1）创建数据库：Create DATABASE database-name
（2）删除数据库： drop database dbname
（3）备份 sql server--- 创建 备份数据的 device USE master
EXEC sp_addumpdevice 'disk', 'testBack', 'c:\mssql7backup\MyNwind_1.dat'
--- 开始 备份 BACKUP DATABASE pubs TO testBack
（4）创建新表：create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
根据已有的表创建新表：
A ： create table tab_new like tab_old ( 使用旧表创建新表 )
B ： create table tab_new as select col1,col2 … from tab_old definition only
（5）删除新表 drop table tabname
（6）增加一个列：Alter table tabname add column col type
注：列增加后将不能删除。 DB2 中列加上后数据类型也不能改变，唯一能改变的是增加 varchar 类型的长度。
（7）添加主键： Alter table tabname add primary key(col)
删除主键： Alter table tabname drop primary key(col)
（8）创建索引： create [unique] index idxname on tabname(col … .)
删除索引： drop index idxname
注：索引是不可更改的，想更改必须删除重新建。
（9）创建视图： create view viewname as select statement
删除视图： drop view viewname
（10）几个简单的基本的 sql 语句
选择： select * from table1 where 范围
插入： insert into table1(field1,field2) values(value1,value2)
删除： delete from table1 where 范围
更新： update table1 set field1=value1 where 范围
查找 ： select * from table1 where field1 like ’ %value1% ’ ---like 的语法很精妙，查资料 !
排序： select * from table1 order by field1,field2 [desc]
总数： select count * as totalcount from table1
求和： select sum(field1) as sumvalue from table1
平均： select avg(field1) as avgvalue from table1
最大： select max(field1) as maxvalue from table1
最小： select min(field1) as minvalue from table1
30. 数据库分库分表思路
一. 数据切分------将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。
数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分
1. 垂直切分----常见有 垂直分库 和 垂直分表 两种。
（1）垂直分库----就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库
垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中
2、水平（横向）切分
水平切分-------分为 库内分表 和 分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果；
库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决
31.delete,truncate,drop的区别
32.事务两阶段提交
33. 数据库三级模式结构：外模式、内模式、模式 及其两级映像/映射
模式也称为逻辑模式或概念模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图(全局视图)。一个数据库只有一个模式，模式位于三级结构的中间层。
模式又称概念模式或逻辑模式，对应于概念级。它是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(DDL)来描述、定义的，体现、反映了数据库系统的整体观。
外模式也称为用户模式，它是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。外模式是模式的子集，一个数据库可以有多个外模式。
外模式又称子模式，对应于用户级。它是某个或某几个用户所看到的数据库的数据视图，是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集，包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式)，也可以利用数据操纵语言(DML)对这些数据记录进行。外模式反映了数据库的用户观。 （外模式保证了数据与程序的逻辑独立性）
内模式也称为存储模式，一个数据库只有一个内模式，它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式
内模式又称存储模式，对应于物理级，它是数据库中全体数据的内部表示或底层描述，是数据库最低一级的逻辑描述，它描述了数据在存储介质上的存储方式的物理结构，对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义，它是数据库的存储观。
三级模式之间的映射
数据库管理系统在三级模式之间提供了两层映射，分别为外模式/模式映射、模式/内模式映射。
对于同一个模式可以有任意多个外模式。对于每一个外模式，数据库系统都有一个外模式/模式映射。当模式被改变时，数据库管理员对各个外模式/模式映射做相应的改变，可以使外模式保持不变。这样，依据数据外模式编写的应用程序就不用修改，保证了数据与程序的逻辑独立性。
数据库中只有一个模式和一个内模式，所以模式/内模式的映射是唯一的，它定义了数据库的全局逻辑结构与存储结构之间的对应关系。当数据库的存储结构被改变时，数据库管理员对模式/内模式映射做相应的改变，可以使模式保持不变，应用程序相应地也不做变动。这样，保证了数据与程序的物理独立性。
34.数据库锁的类型（三种锁）
锁的类型有三种：
共享（S)锁：多个事务可封锁一个共享页；任何事务都不能修改该页； 通常是该页被读取完毕，S锁立即被释放。
排它（X)锁：仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。
更新（U)锁：用来预定要对此页施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的页将要被更新时，则升级为X锁；U锁一直到事务结束时才能被释放。
