为什么要使用数据库
数据保存在内存
- 优点： 存取速度快
- 缺点： 数据不能永久保存
数据保存在文件
- 优点： 数据永久保存
- 缺点：1、速度比内存操作慢，频繁的IO操作。2、查询数据不方便
数据保存在数据库
- 数据永久保存
- 使用SQL语句，查询方便效率高。
- 管理数据方便
什么是SQL？
结构化查询语言(Structured Query Language)简称SQL，是一种数据库查询语言。
用于存取数据、查询、更新和管理关系数据库系统。
什么是MySQL?
MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。在Java企业级开发中非常常用，因为 MySQL 是开源免费的，并且方便扩展。
MySql, Oracle，Sql Service的区别
Sql Service只能在Windows上使用，而MySql和Oracle可以在其他系统上使用， 而且可以支持数据库不同系统之间的移植
MySql开源免费的，Sql Service和Oracle要钱。
我从小到大排序哈，MySql很小，Sql Service居中，Oracle最大
Oracle支持大并发量，大访问量，Sql Service还行，而MySql的话压力没这么大，因此现在的MySql的话最好是要使用集群或者缓存来搭配使用
Oracle支持多用户不同权限来进行操作，而MySql只要有登录权限就可操作全部数据库
安装所用的空间差别也是很大的，Mysql安装完后才几百M而Oracle有几G左右，且使用的时候Oracle占用特别大的内存空间和其他机器性能。
做分页的话，MySql使用Limit，Sql Service使用top，Oracle使用row
Oracle没有自动增长类型，Mysql和Sql Service一般使用自动增长类型
数据库三大范式
第一范式 (1st NF －列都是不可再分)
第一范式的目标是确保每列的原子性:如果每列都是不可再分的最小数据单元（也称为最小的原子 单元），则满足第一范式（1NF）
第二范式(2nd NF－每个表只描述一件事情)
首先满足第一范式，并且表中非主键列不存在对主键的部分依赖。 第二范式要求每个表只描述一
件事情。
第三范式(3rd NF－ 不存在对非主键列的传递依赖)
第三范式定义是，满足第二范式，并且表中的列不存在对非主键列的传递依赖。除了主键订单编
号外，顾客姓名依赖于非主键顾客编号。
Mysql有关权限的表都有哪几个
- user权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。
- db权限表：记录各个帐号在各个数据库上的操作权限。
- table_priv权限表：记录数据表级的操作权限。
- columns_priv权限表：记录数据列级的操作权限。
- host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。
Heap 表是什么？
- HEAP 表存在于内存中，用于临时高速存储。
- BLOB 或 TEXT 字段是不允许的
- 只能使用比较运算符=，<，>，=>，= <
- HEAP 表不支持 AUTO_INCREMENT
- 索引不可为 NULL
如何控制 HEAP 表的最大尺寸？
事务的四个特征（ACID）
- 原子性（ Atomicity ）。事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
- 一致性（ Consistency ）。事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
- 隔离性（ Isolation ）。一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
- 和持续性（ Durability ）。也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。
Mysql的四种隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻影读 |
|---|---|---|---|
| READ-UNCOMMITTED | √ | √ | √ |
| READ-COMMITTED | × | √ | √ |
| REPEATABLE-READ | × | × | √ |
| SERIALIZABLE | × | × | × |
SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
Read Uncommitted（读取未提交内容）：在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容）：这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重读）：这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
Serializable（可串行化）：这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
注意：
-
这里需要注意的是：Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别
-
事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC（多版本并发控制），通过保存修改的旧版本信息来支持并发一致性读和回滚等特性。
-
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):，但是你要知道的是InnoDB 存储引擎默认使用 **REPEATABLE-READ（可重读）**并不会有任何性能损失。
-
InnoDB 存储引擎在 分布式事务 的情况下一般会用到**SERIALIZABLE(可串行化)**隔离级别。
MYSQL 支持事务吗？
在缺省模式下，MYSQL 是 autocommit 模式的，所有的数据库更新操作都会即时提交，所
以在缺省情况下，mysql 是不支持事务的。
但是如果你的 MYSQL 表类型是使用 InnoDB Tables 或 BDB tables 的话，你的 MYSQL 就可以使用事务处理,使用 SET AUTOCOMMIT=0 就可以使 MYSQL 允许在非 autocommit 模式，在非autocommit 模式下，你必须使用 COMMIT 来提交你的更改，或者用 ROLLBACK 来回滚你的更改。
示例如下：
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;
COMMIT;
如何使用 Unix shell 登录 Mysql？
[mysql dir]/bin/mysql -h hostname -u
我们如何在 mysql 中运行批处理模式？
mysql;
mysql mysql.out
Mysql 数据类型
| 分类 | 类型名称 | 说明 |
|---|---|---|
| 整数类型 | tinyInt | 很小的整数(8位二进制) |
| 整数类型 | smallint | 小的整数(16位二进制) |
| 整数类型 | mediumint | 中等大小的整数(24位二进制) |
| 整数类型 | int(integer) | 普通大小的整数(32位二进制) |
| 小数类型 | float | 单精度浮点数 |
| 小数类型 | double | 双精度浮点数 |
| 小数类型 | decimal(m,d) | 压缩严格的定点数 |
| 日期类型 | year | YYYY 1901~2155 |
| 日期类型 | time | HH:MM:SS -838:59:59~838:59:59 |
| 日期类型 | date | YYYY-MM-DD 1000-01-01~9999-12-3 |
| 日期类型 | datetime | YYYY-MM-DD HH:MM:SS 1000-01-01 00:00:00~ 9999-12-31 23:59:59 |
| 日期类型 | timestamp | YYYY-MM-DD HH:MM:SS 19700101 00:00:01 UTC~2038-01-19 03:14:07UTC |
| 文本、二进制类型 | CHAR(M) | M为0~255之间的整数 |
| 文本、二进制类型 | VARCHAR(M) | M为0~65535之间的整数 |
| 文本、二进制类型 | TINYBLOB | 允许长度0~255字节 |
| 文本、二进制类型 | BLOB | 允许长度0~65535字节 |
| 文本、二进制类型 | MEDIUMBLOB | 允许长度0~167772150字节 |
| 文本、二进制类型 | LONGBLOB | 允许长度0~4294967295字节 |
| 文本、二进制类型 | TINYTEXT | 允许长度0~255字节 |
| 文本、二进制类型 | TEXT | 允许长度0~65535字节 |
| 文本、二进制类型 | MEDIUMTEXT | 允许长度0~167772150字节 |
| 文本、二进制类型 | LONGTEXT | 允许长度0~4294967295字节 |
| 文本、二进制类型 | VARBINARY(M) | 允许长度0~M个字节的变长字节字符串 |
| 文本、二进制类型 | BINARY(M) | 允许长度0~M个字节的定长字节字符串 |
varchar与char的区别
char的特点
-
char表示定长字符串，长度是固定的；
-
如果插入数据的长度小于char的固定长度时，则用空格填充；
-
因为长度固定，所以存取速度要比varchar快很多，甚至能快50%，但正因为其长度固定，所以会占据多余的空间，是空间换时间的做法；
-
对于char来说，最多能存放的字符个数为255，和编码无关
varchar的特点
-
varchar表示可变长字符串，长度是可变的；
-
插入的数据是多长，就按照多长来存储；
-
varchar在存取方面与char相反，它存取慢，因为长度不固定，但正因如此，不占据多余的空间，是时间换空间的做法；
-
对于varchar来说，最多能存放的字符个数为65532
总之，结合性能角度（char更快）和节省磁盘空间角度（varchar更小），具体情况还需具体来设计数据库才是妥当的做法。
varchar(50)中50的涵义
- 最多存放50个字符，varchar(50)和(200)存储hello所占空间一样，但后者在排序时会消耗更多内存，因为order by col采用fixed_length计算col长度(memory引擎也一样)。在早期 MySQL 版本中， 50 代表字节数，现在代表字符数。
int(20)中20的涵义
-
是指显示字符的长度。20表示最大显示宽度为20，但仍占4字节存储，存储范围不变；
-
不影响内部存储，只是影响带 zerofill 定义的 int 时，前面补多少个 0，易于报表展示
mysql中int(10)和char(10)以及varchar(10)的区别
-
int(10)的10表示显示的数据的长度，不是存储数据的大小；chart(10)和varchar(10)的10表示存储数据的大小，即表示存储多少个字符。
-
char(10)表示存储定长的10个字符，不足10个就用空格补齐，占用更多的存储空间
-
varchar(10)表示存储10个变长的字符，存储多少个就是多少个，空格也按一个字符存储，这一点是和char(10)的空格不同的，char(10)的空格表示占位不算一个字符
若一张表中只有一个字段 VARCHAR(N)类型，utf8 编码，则 N 最大值为多少(精确到数量级即可)?
由于 utf8 的每个字符最多占用 3 个字节。而 MySQL 定义行的长度不能超过65535，因此 N 的最大值计算方法为：(65535-1-2)/3。减去 1 的原因是实际存储从第二个字节开始，减去 2 的原因是因为要在列表长度存储实际的字符长度，除以 3 是因为 utf8 限制：每个字符最多占用 3 个字节。
FLOAT和DOUBLE的区别是什么？
- FLOAT类型数据可以存储至多8位十进制数，并在内存中占4字节。
- DOUBLE类型数据可以存储至多18位十进制数，并在内存中占8字节。
BLOB 和 TEXT 有什么区别？
BLOB 是一个二进制对象，可以容纳可变数量的数据。有四种类型的 BLOB ：
- TINYBLOB
- BLOB
- MEDIUMBLOB
- LONGBLOB
它们只能在所能容纳价值的最大长度上有所不同。
TEXT 是一个不区分大小写的 BLOB。四种 TEXT 类型：
- TINYTEXT
- TEXT
- MEDIUMTEXT
- LONGTEXT
它们对应于四种 BLOB 类型，并具有相同的最大长度和存储要求。
BLOB 和 TEXT 类型之间的唯一区别在于对 BLOB 值进行排序和比较时区分大小写，对 TEXT
值不区分大小写。
什么是非标准字符串类型？
- TINYTEXT
- TEXT
- MEDIUMTEXT
- LONGTEXT
mysql_fetch_array 和 mysql_fetch_object 的区别是什么？
mysql_fetch_array（） - 将结果行作为关联数组或来自数据库的常规数组返回。
mysql_fetch_object - 从数据库返回结果行作为对象
在 Mysql 中 ENUM 的用法是什么？
ENUM 是一个字符串对象，用于指定一组预定义的值，并可在创建表时使用。
Create table size(name ENUM('Smail,'Medium','Large');
Mysql 存储引擎
- Innodb引擎：Innodb引擎提供了对数据库ACID事务的支持，并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。
- MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。
- MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。
MyISAM与InnoDB区别
| 比较 | MyISAM | Innodb |
|---|---|---|
| 存储结构 | 每张表被存放在三个文件：frm-表格定义、MYD(MYData)-数据文件、MYI(MYIndex)-索引文件 | 所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB |
| 存储空间 | MyISAM可被压缩，存储空间较小 | InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引 |
| 可移植性、备份及恢复 | 由于MyISAM的数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作 | 免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了 |
| 文件格式 | 数据和索引是分别存储的，数据.MYD，索引.MYI | 数据和索引是集中存储的，.ibd |
| 记录存储顺序 | 按记录插入顺序保存 | 按主键大小有序插入 |
| 外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 锁支持（锁是避免资源争用的一个机制，MySQL锁对用户几乎是透明的） | 表级锁定 | 行级锁定、表级锁定，锁定力度小并发能力高 |
| SELECT | MyISAM更优 | -- |
| INSERT、UPDATE、DELETE | -- | InnoDB更优 |
| select count(*) | myisam更快，因为myisam内部维护了一个计数器，可以直接调取。 | |
| 索引的实现方式 | B+树索引，myisam 是堆表 | B+树索引，Innodb 是索引组织表 |
| 哈希索引 | 不支持 | 支持 |
| 全文索引 | 支持 | 不支持 |
MyISAM索引与InnoDB索引的区别？
- InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。
- InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。
- MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。
- InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。
MyISAM 表格将在哪里存储，并且还提供其存储格式？
每个 MyISAM 表格以三种格式存储在磁盘上：
·“.frm”文件存储表定义
·数据文件具有“.MYD”（MYData）扩展名
索引文件具有“.MYI”（MYIndex）扩展名
myisamchk 是用来做什么的？
它用来压缩 MyISAM 表，这减少了磁盘或内存使用。
InnoDB引擎的4大特性
- 插入缓冲（insert buffer)
- 二次写(double write)
- 自适应哈希索引(ahi)
- 预读(read ahead)
存储引擎选择
- 如果没有特别的需求，使用默认的Innodb即可。
- MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。
- Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。
什么是索引？
索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。
索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。
更通俗的说，索引就相当于目录。为了方便查找书中的内容，通过对内容建立索引形成目录。索引是一个文件，它是要占据物理空间的。
索引有哪些优缺点？
索引的优点
- 可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
- 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
- 唯一索引可以保证数据库列的一致性，可以确定表与表之间的连接
索引的缺点
- 时间方面：创建索引和维护索引要耗费时间，具体地，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增/改/删的执行效率；
- 空间方面：索引需要占物理空间。
索引 创建
create index depe_unique_ide on depe(dept_no) tablespace idx_
索引分类
逻辑分类：单列索引，复合索引，唯一索引，非唯一索引，函数索引
物理分类：B数索引，反向键索引，位图索引
简述有哪些索引和作用
- 索引的作用：通过索引可以大大的提高数据库的检索速度，改善数据库性能
- 唯一索引：不允许有俩行具有相同的值
- 主键索引：为了保持数据库表与表之间的关系
- 聚集索引：表中行的物理顺序与键值的逻辑（索引）顺序相同。
- 非聚集索引：聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致
- 复合索引：在创建索引时，并不是只能对一列进行创建索引，可以与主键一样，讲多个组合为索引
- 全文索引： 全文索引为在字符串数据中进行复杂的词搜索提供有效支持
应该创建索引的场景
- 主键应该创建主键索引
- 频繁作为查询条件的字段应该创建索引
- 查询中需要与其他表进行关联的字段应该创建索引
- 需要排序的字段应该创建索引
- 需要统计或分组的字段应该创建索引
- 优先考虑创建复合索引
不适合创建索引的场景
- 频繁更新的字段不适合创建索引
- 查询条件中用不到的字段不适合创建索引
不应创建索引的场景
- 数据记录较少的表
- 经常需要增删改操作的字段
- 数据记录重复较多且分布平均的字段（如性别、状态等）
- 索引的选择性是指索引列中不同值的数目与表中记录总数的比
- 索引的选择性越接近于1，创建索引的价值就越高。反之就越低
主键索引与唯一索引的区别
- 主键是一种约束，唯一索引是一种索引，两者在本质上是不同的。
- 主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键。
- 唯一性索引列允许空值，而主键列不允许为空值。
- 主键列在创建时，已经默认为空值 ++ 唯一索引了。
- 一个表最多只能创建一个主键，但可以创建多个唯一索引。
- 主键更适合那些不容易更改的唯一标识，如自动递增列、身份证号等。
- 主键可以被其他表引用为外键，而唯一索引不能。
主键和候选键有什么区别？
表格的每一行都由主键唯一标识,一个表只有一个主键。
主键也是候选键。按照惯例，候选键可以被指定为主键，并且可以用于任何外键引用。
索引有哪几种类型？
主键索引: 数据列不允许重复，不允许为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); 创建全文索引索引的数据结构（b树，hash）
索引的数据结构和具体存储引擎的实现有关，在MySQL中使用较多的索引有Hash索引，B+树索引等，而我们经常使用的InnoDB存储引擎的默认索引实现为：B+树索引。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。
B树索引
mysql通过存储引擎取数据，基本上90%的人用的就是InnoDB了，按照实现方式分，InnoDB的索引类型目前只有两种：BTREE（B树）索引和HASH索引。B树索引是Mysql数据库中使用最频繁的索引类型，基本所有存储引擎都支持BTree索引。通常我们说的索引不出意外指的就是（B树）索引（实际是用B+树实现的，因为在查看表索引时，mysql一律打印BTREE，所以简称为B树索引）
查询方式：
主键索引区:PI(关联保存的时数据的地址)按主键查询,
普通索引区:si(关联的id的地址,然后再到达上面的地址)。所以按主键查询,速度最快
B+tree性质
- n棵子tree的节点包含n个关键字，不用来保存数据而是保存数据的索引。
- 所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
- 所有的非终端结点可以看成是索引部分，结点中仅含其子树中的最大（或最小）关键字。
- B+ 树中，数据对象的插入和删除仅在叶节点上进行。
- B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。
哈希索引
简要说下，类似于数据结构中简单实现的HASH表（散列表）一样，当我们在mysql中用哈希索引时，主要就是通过Hash算法（常见的Hash算法有直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入Hash表的对应位置；如果发生Hash碰撞（两个不同关键字的Hash值相同），则在对应Hash键下以链表形式存储。当然这只是简略模拟图。
索引的基本原理
索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。
索引的原理很简单，就是把无序的数据变成有序的查询：
- 把创建了索引的列的内容进行排序
- 对排序结果生成倒排表
- 在倒排表内容上拼上数据地址链
- 在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据
索引算法有哪些？
索引算法有 BTree算法和Hash算法
BTree算法
BTree是最常用的mysql数据库索引算法，也是mysql默认的算法。因为它不仅可以被用在=,>,>=,<,<=和between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的常量， 例如：
-- 只要它的查询条件是一个不以通配符开头的常量
select * from user where name like 'jack%';
-- 如果一通配符开头，或者没有使用常量，则不会使用索引，例如：
select * from user where name like '%jack';Hash算法
Hash Hash索引只能用于对等比较，例如=,<=>（相当于=）操作符。由于是一次定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。
索引设计的原则
适合索引的列是出现在where子句中的列，或者连接子句中指定的列
基数较小的类，索引效果较差，没有必要在此列建立索引
使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间
不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。
创建索引的原则
- 最左前缀匹配原则，组合索引非常重要的原则，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的顺序可以任意调整。
- 较频繁作为查询条件的字段才去创建索引
- 更新频繁字段不适合创建索引
- 若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)
- 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
- 定义有外键的数据列一定要建立索引。
- 对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
- 对于定义为text、image和bit的数据类型的列不要建立索引。
创建索引的三种方式
第一种方式：在执行CREATE TABLE时创建索引
CREATE TABLE user_index2 (
id INT auto_increment PRIMARY KEY,
first_name VARCHAR (16),
last_name VARCHAR (16),
id_card VARCHAR (18),
information text,
KEY name (first_name, last_name),
FULLTEXT KEY (information),
UNIQUE KEY (id_card)
);第二种方式：使用ALTER TABLE命令去增加索引
ALTER TABLE table_name ADD INDEX index_name (column_list);第三种方式：使用CREATE INDEX命令创建
CREATE INDEX index_name ON table_name (column_list);可对表增加普通索引或UNIQUE索引。（但是，不能创建PRIMARY KEY索引）
如何删除索引
根据索引名删除普通索引、唯一索引、全文索引：
alter table 表名 drop KEY 索引名删除主键索引：alter table 表名 drop primary key（因为主键只有一个）。这里值得注意的是，如果主键自增长，那么不能直接执行此操作（自增长依赖于主键索引），需要取消自增长再行删除：
alter table user_index
-- 重新定义字段
MODIFY id int,
drop PRIMARY KEY创建索引时需要注意什么？
- 非空字段：应该指定列为NOT NULL，除非你想存储NULL。在mysql中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值；
- 取值离散大的字段：（变量各个取值之间的差异程度）的列放到联合索引的前面，可以通过count()函数查看字段的差异值，返回值越大说明字段的唯一值越多字段的离散程度高；
- 索引字段越小越好：数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大效率越高。
前缀索引
语法：index(field(10))，使用字段值的前10个字符建立索引，默认是使用字段的全部内容建立索引。
前提：前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相同。
实操的难度：在于前缀截取的长度。我们可以利用select count(*)/count(distinct left(password,prefixLen));，通过从调整prefixLen的值（从1自增）查看不同前缀长度的一个平均匹配度，接近1时就可以了（表示一个密码的前prefixLen个字符几乎能确定唯一一条记录）
什么是最左前缀原则？什么是最左匹配原则
顾名思义，就是最左优先，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。
最左前缀匹配原则，非常重要的原则，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的顺序可以任意调整。
=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
B树和B+树的区别
B+树的非叶子结点只包含导航信息，不包含实际的值，所有的叶子结点和相连的节点使用链表相连，便于区间查找和遍历。
B+ 树的优点在于：
- IO次数更少：由于B+树在内部节点上不包含数据信息，因此在内存页中能够存放更多的key。 数据存放的更加紧密，具有更好的空间局部性。因此访问叶子节点上关联的数据也具有更好的缓存命中率。
- 遍历更加方便：B+树的叶子结点都是相链的，因此对整棵树的遍历只需要一次线性遍历叶子结点即可。而且由于数据顺序排列并且相连，所以便于区间查找和搜索。而B树则需要进行每一层的递归遍历。相邻的元素可能在内存中不相邻，所以缓存命中性没有B+树好。
但是B树也有优点，其优点在于，由于B树的每一个节点都包含key和value，因此经常访问的元素可能离根节点更近，因此访问也更迅速。
使用B树的好处
B树可以在内部节点同时存储键和值，因此，把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。
使用B+树的好处
由于B+树的内部节点只存放键，不存放值，因此，一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。 B+树的叶节点由一条链相连，因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)时间找到最小的一个节点，然后通过链进行O(N)的顺序遍历即可。而B树则需要对树的每一层进行遍历，这会需要更多的内存置换次数，因此也就需要花费更多的时间
为什么MySQL选择B+树做索引
1、 B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。
2、B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
3、B+树更便于遍历：由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。
4、B+树更适合基于范围的查询：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。
Hash索引和B+树所有有什么区别
1、在查询速度上，如果是等值查询，那么Hash索引明显有绝对优势，因为只需要经过一次 Hash 算法即可找到相应的键值，复杂度为O(1)；当然了，这个前提是键值都是唯一的。如果键值不是唯一(或存在Hash冲突)，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据，这时候复杂度会变成O(n)，降低了Hash索引的查找效率。所以，Hash 索引通常不会用到重复值多的列上，比如列为性别、年龄的情况等（当然B+tree索引也不适合这种离散型低的字段上）；
2、Hash 索引是无序的，如果是范围查询检索，这时候 Hash 索引就无法起到作用，即使原先是有序的键值，经过 Hash 算法后，也会变成不连续的了。因此
①、Hash 索引只支持等值比较查询、无法索成范围查询检索，B+tree索引的叶子节点形成有序链表，便于范围查询。
②、Hash 索引无法做 like ‘xxx%’ 这样的部分模糊查询，因为需要对 完整 key 做 Hash 计算，定位bucket。而 B+tree 索引具有最左前缀匹配，可以进行部分模糊查询。
③、Hash索引中存放的是经过Hash计算之后的Hash值，而且Hash值的大小关系并不一定和Hash运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算。B+tree 索引的叶子节点形成有序链表，可用于排序。
3、Hash 索引不支持多列联合索引，对于联合索引来说，Hash 索引在计算 Hash 值的时候是将索引键合并后再一起计算 Hash 值，不会针对每个索引单独计算 Hash 值。因此如果用到联合索引的一个或者几个索引时，联合索引无法被利用；
4、因为存在哈希碰撞问题，在有大量重复键值情况下，哈希索引的效率极低。B+tree 所有查询都要找到叶子节点，性能稳定；
场景区分
1、大多数场景下，都会有组合查询，范围查询、排序、分组、模糊查询等查询特征，Hash 索引无法满足要求，建议数据库使用B+树索引。
2、在离散型高，数据基数大，且等值查询时候，Hash索引有优势。
什么是聚簇索引？
聚集索引: 表数据按照索引的顺序来存储的，也就是说索引项的顺序与表中记录的物理顺序一致。对于聚集索引，叶子结点即存储了真实的数据行，不再有另外单独的数据页。 在一张表上最多只能创建一个聚集索引，因为真实数据的物理顺序只能有一种。
非聚集索引: 表数据存储顺序与索引顺序无关。对于非聚集索引，叶结点包含索引字段值及指向数据页数据行的逻辑指针，其行数量与数据表行数据量一致。
总结一下：聚集索引是一种稀疏索引，数据页上一级的索引页存储的是页指针，而不是行指针。而对于非聚集索引，则是密集索引，在数据页的上一级索引页它为每一个数据行存储一条索引记录。
何时使用聚簇索引与非聚簇索引
| 动作 | 使用聚簇索引 | 使用非聚簇索引 |
| 列经常被分组排序 | 应 | 应 |
| 返回某范围内的数据 | 应 | 不应 |
| 一个或极少不同值 | 不应 | 不应 |
| 小数目的不同值 | 应 | 不应 |
| 大数目的不同值 | 不应 | 应 |
| 频繁更新的列 | 不应 | 应 |
| 外键列 | 应 | 应 |
| 主键列 | 应 | 应 |
| 频繁修改索引列 | 不应 | 应 |
非聚簇索引一定会回表查询吗？
不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。
举个简单的例子，假设我们在员工表的年龄上建立了索引，那么当进行 select age from employee where age < 20 的查询时，在索引的叶子节点上，已经包含了age信息，不会再次进行回表查询。
联合索引是什么？为什么需要注意联合索引中的顺序？
MySQL可以使用多个字段同时建立一个索引，叫做联合索引。
在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。
联合索引的最左匹配原则（左前缀原则）
MySQL使用联合索引时，需要注意的是联合索引的最左匹配原则（左前缀原则）。如：
假设现在建立了idx_test (group_id,cal_id,user_name_info)的联合索引,那么索引的排序为: 先按照group_id排序,如果group_id相同,则按照cal_id排序,如果cal_id的值也相等,则按照user_name_info进行排序;
当进行查询时,此时索引仅仅按照group_id严格有序,因此必须首先使用group_id字段进行等值查询,之后对于匹配到的列而言,其按照cal_id字段严格有序,此时可以使用cal_id字段用做索引查找。以此类推.因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面.此外可以根据特例的查询或者表结构进行单独的调整。
- where group_id = 5 and cal_id = 6 and user_name_info = "pomit" ： (可以走索引idx_test)
- where cal_id = 6 and group_id = 5 and user_name_info = "pomit" ： (可以走索引idx_test)
- where group_id = 5 and cal_id = 6 ： (可以走索引idx_test)
- where group_id = 5 and user_name_info = "pomit" ： (可以走索引idx_test)
- where group_id = 5 ： (可以走索引idx_test)
- where cal_id = 6 ： (不走索引idx_test)
- where cal_id = 6 and user_name_info = "pomit" ： (不走索引idx_test)
可以看出，
-
如果条件里面含有联合索引的第一个索引字段，那么不管where条件的顺序和个数，则这次查询都会走索引（like等造成的索引失效除外）;
-
联合索引的使用和and条件的顺序无关。
-
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的，所以我们在数据库设计时尽可能不要让字段的默认值为NULL。
联合索引的好处
-
减少索引建立的开销。建了一个(a,b,c)的复合索引，那么实际等于建了(a),(a,b),(a,b,c)三个索引，因为每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，这可是不小的开销！
-
覆盖索引。同样的有复合索引（a,b,c），如果有如下的
select a,b,c from table where a=1 and b = 1。那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io操作。减少io操作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一 -
缩小筛选范围。有1000W条数据的表，有如下
select * from table where a = 1 and b =2 and c = 3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W*10%=100w 条数据，然后再回表从100w条数据中找到符合b=2 and c= 3的数据，然后再排序，再分页；如果是复合索引，通过索引筛选出1000w *10% *10% *10%=1w，然后再排序、分页。
可以使用多少列创建索引？
任何标准表最多可以创建 16 个索引列。
从锁的类别上分MySQL都有哪些锁呢？
从锁的类别上来讲，有共享锁和排他锁。
-
共享锁: 又叫做读锁。 当用户要进行数据的读取时，对数据加上共享锁。共享锁就是让多个线程同时获取一个锁。
-
排他锁: 又叫做写锁。 当用户要进行数据的写入时，对数据加上排他锁。排它锁也称作独占锁，一个锁在某一时刻只能被一个线程占有，其它线程必须等待锁被释放之后才可能获取到锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥。
隔离级别与锁的关系
-
在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突
-
在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；
-
在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁。
-
SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。
按照锁的粒度分数据库锁有哪些？锁机制与InnoDB锁算法
-
在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。
-
MyISAM和InnoDB存储引擎使用的锁：
- MyISAM采用表级锁(table-level locking)。
- InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁
行级锁，表级锁和页级锁对比
-
行级锁 行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁 和 排他锁。
- 特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
-
表级锁 表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
- 特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
-
页级锁 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
- 特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
MySQL中InnoDB引擎的行锁是怎么实现的？
InnoDB是基于索引来完成行锁。
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id 不是索引键那么InnoDB将完成表锁
InnoDB存储引擎的锁的算法有三种
- Record lock：单个行记录上的锁
- Gap lock：间隙锁，锁定一个范围，不包括记录本身
- Next-key lock：record+gap 锁定一个范围，包含记录本身
相关知识点：
- innodb对于行的查询使用next-key lock
- Next-locking keying为了解决Phantom Problem幻读问题
- 当查询的索引含有唯一属性时，将next-key lock降级为record key
- Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生
- 有两种方式显式关闭gap锁：（除了外键约束和唯一性检查外，其余情况仅使用record lock） A. 将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1
什么是死锁？
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。
数据库的乐观锁和悲观锁是什么？怎么实现的？
数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制（乐观锁）和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。
-
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。实现方式：使用数据库中的锁机制
//核心SQL,主要靠for update select status from t_goods where id=1 for update; 复制代码 -
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来，通过version的方式来进行锁定。实现方式：乐一般会使用版本号机制或CAS算法实现。
//核心SQL update table set x=x+1, version=version+1 where id=#{id} and version=#{version}; 复制代码
两种锁的使用场景
-
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
-
但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
什么是通用 SQL 函数？
- CONCAT(A, B) - 连接两个字符串值以创建单个字符串输出。通常用于将两个或多个字段合并为一个字段。
- FORMAT(X, D)- 格式化数字 X 到 D 有效数字。
- CURRDATE(), CURRTIME()- 返回当前日期或时间。
- NOW（） - 将当前日期和时间作为一个值返回。
- MONTH（），DAY（），YEAR（），WEEK（），WEEKDAY（） - 从日期值中提取给定数据。
- HOUR（），MINUTE（），SECOND（） - 从时间值中提取给定数据。
- DATEDIFF（A，B） - 确定两个日期之间的差异，通常用于计算年龄
- SUBTIMES（A，B） - 确定两次之间的差异。
- FROMDAYS（INT） - 将整数天数转换为日期值。
解释访问控制列表
ACL（访问控制列表）是与对象关联的权限列表。这个列表是 Mysql 服务器安全模型的基
础，它有助于排除用户无法连接的问题。
Mysql 将 ACL（也称为授权表）缓存在内存中。当用户尝试认证或运行命令时，Mysql 会按
照预定的顺序检查 ACL 的认证信息和权限。
什么是视图？
为了提高复杂SQL语句的复用性和表操作的安全性，MySQL数据库管理系统提供了视图特性。所谓视图，本质上是一种虚拟表，在物理上是不存在的，其内容与真实的表相似，包含一系列带有名称的列和行数据。但是，视图并不在数据库中以储存的数据值形式存在。行和列数据来自定义视图的查询所引用基本表，并且在具体引用视图时动态生成。
视图的使用场景有哪些？
简化sql查询，提高开发效率。如果说还有另外一个用途那就是兼容老的表结构。
下面是视图的常见使用场景：
-
重用SQL语句；
-
简化复杂的SQL操作。在编写查询后，可以方便的重用它而不必知道它的基本查询细节；
-
使用表的组成部分而不是整个表；
-
保护数据。可以给用户授予表的特定部分的访问权限而不是整个表的访问权限；
-
更改数据格式和表示。视图可返回与底层表的表示和格式不同的数据。
视图的优点
- 查询简单化。视图能简化用户的操作
- 数据安全性。视图使用户能以多种角度看待同一数据，能够对机密数据提供安全保护
- 逻辑数据独立性。视图对重构数据库提供了一定程度的逻辑独立性
视图的缺点
-
性能。数据库必须把视图的查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也把它变成一个复杂的结合体，需要花费一定的时间。
-
修改限制。当用户试图修改视图的某些行时，数据库必须把它转化为对基本表的某些行的修改。事实上，当从视图中插入或者删除时，情况也是这样。对于简单视图来说，这是很方便的，但是，对于比较复杂的视图，可能是不可修改的
这些视图有如下特征：1.有UNIQUE等集合操作符的视图。2.有GROUP BY子句的视图。3.有诸如AVG\SUM\MAX等聚合函数的视图。 4.使用DISTINCT关键字的视图。5.连接表的视图（其中有些例外）
Mysql 表中允许有多少个 TRIGGERS？
在 Mysql 表中允许有六个触发器，如下：
- BEFORE INSERT
- AFTER INSERT
- BEFORE UPDATE
- AFTER UPDATE
- BEFORE DELETE
- AFTER DELETE
什么是存储过程？有哪些优缺点？
存储过程是一个预编译的SQL语句，优点是允许模块化的设计，就是说只需要创建一次，以后在该程序中就可以调用多次。如果某次操作需要执行多次SQL，使用存储过程比单纯SQL语句执行要快。
优点
- 存储过程是预编译过的，执行效率高。
- 存储过程的代码直接存放于数据库中，通过存储过程名直接调用，减少网络通讯。
- 安全性高，执行存储过程需要有一定权限的用户。
- 存储过程可以重复使用，减少数据库开发人员的工作量。
缺点
- 调试麻烦，但是用 PL/SQL Developer 调试很方便！弥补这个缺点。
- 移植问题，数据库端代码当然是与数据库相关的。但是如果是做工程型项目，基本不存在移植问题。
- 重新编译问题，因为后端代码是运行前编译的，如果带有引用关系的对象发生改变时，受影响的存储过程、包将需要重新编译（不过也可以设置成运行时刻自动编译）。
- 如果在一个程序系统中大量的使用存储过程，到程序交付使用的时候随着用户需求的增加会导致数据结构的变化，接着就是系统的相关问题了，最后如果用户想维护该系统可以说是很难很难、而且代价是空前的，维护起来更麻烦。
什么是触发器？触发器的使用场景有哪些？
- 触发器是用户定义在关系表上的一类由事件驱动的特殊的存储过程。触发器是指一段代码，当触发某个事件时，自动执行这些代码。
使用场景
- 可以通过数据库中的相关表实现级联更改。
- 实时监控某张表中的某个字段的更改而需要做出相应的处理。
- 例如可以生成某些业务的编号。
- 注意不要滥用，否则会造成数据库及应用程序的维护困难。
- 大家需要牢记以上基础知识点，重点是理解数据类型CHAR和VARCHAR的差异，表存储引擎InnoDB和MyISAM的区别。
MySQL中都有哪些触发器？
- Before Insert
- After Insert
- Before Update
- After Update
- Before Delete
- After Delete
SQL语句主要分为哪几类
-
数据定义语言DDL（Data Ddefinition Language）CREATE，DROP，ALTER
主要为以上操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。
-
数据查询语言DQL（Data Query Language）SELECT
这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。
-
数据操纵语言DML（Data Manipulation Language）INSERT，UPDATE，DELETE
主要为以上操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。
-
数据控制功能DCL（Data Control Language）GRANT，REVOKE，COMMIT，ROLLBACK
主要为以上操作 即对数据库安全性完整性等有操作的，可以简单的理解为权限控制等。
SQL 约束有哪几种？
- NOT NULL: 用于控制字段的内容一定不能为空（NULL）。
- UNIQUE: 控件字段内容不能重复，一个表允许有多个 Unique 约束。
- PRIMARY KEY: 也是用于控件字段内容不能重复，但它在一个表只允许出现一个。
- FOREIGN KEY: 用于预防破坏表之间连接的动作，也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。
- CHECK: 用于控制字段的值范围。
[SELECT *] 和[SELECT 全部字段]的 2 种写法有何优缺点?
1. 前者要解析数据字典，后者不需要
2. 结果输出顺序，前者与建表列顺序相同，后者按指定字段顺序。
3. 表字段改名，前者不需要修改，后者需要改
4. 后者可以建立索引进行优化，前者无法优化
5. 后者的可读性比前者要高
HAVNG 子句 和 WHERE 的异同点?
1. 语法上：where 用表中列名，having 用 select 结果别名
2. 影响结果范围：where 从表读出数据的行数，having 返回客户端的行数
3. 索引：where 可以使用索引，having 不能使用索引，只能在临时结果集操作
4. where 后面不能使用聚集函数，having 是专门使用聚集函数的。
MySQL 当记录不存在时 insert,当记录存在时 update，语句怎么写？
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEYUPDATE c=c+1;MySQL 的 insert 和 update 的 select 语句语法
insert into student (stuid,stuname,deptid) select 10,'xzm',3 from student where stuid > 8;
update student a inner join student b on b.stuID=10 set a.stuname=concat(b.stuname, b.stuID) where a.stuID=10 ;六种关联查询
-
交叉连接（CROSS JOIN）
-
内连接（INNER JOIN）
-
外连接（LEFT JOIN/RIGHT JOIN）
-
联合查询（UNION与UNION ALL）
-
全连接（FULL JOIN）
-
交叉连接，笛卡尔集（CROSS JOIN）
内连接分为三类
- 等值连接：ON A.id=B.id
- 不等值连接：ON A.id > B.id
- 自连接：SELECT * FROM A T1 INNER JOIN A T2 ON T1.id=T2.pid
外连接（LEFT JOIN/RIGHT JOIN）
- 左外连接：LEFT OUTER JOIN, 以左表为主，先查询出左表，按照ON后的关联条件匹配右表，没有匹配到的用NULL填充，可以简写成LEFT JOIN
- 右外连接：RIGHT OUTER JOIN, 以右表为主，先查询出右表，按照ON后的关联条件匹配左表，没有匹配到的用NULL填充，可以简写成RIGHT JOIN
联合查询（UNION与UNION ALL）
- 就是把多个结果集集中在一起，UNION前的结果为基准，需要注意的是联合查询的列数要相等，相同的记录行会合并
- 如果使用UNION ALL，不会合并重复的记录行
- 效率 UNION 高于 UNION ALL
LIKE 和 REGEXP 操作有什么区别？
LIKE 和 REGEXP 运算符用于表示^和％。
SELECT * FROM employee WHERE emp_name REGEXP "^b";
SELECT * FROM employee WHERE emp_name LIKE "%b";
drop、delete与truncate的区别
| 比较 | Delete | Truncate | Drop |
|---|---|---|---|
| 类型 | 属于DML | 属于DDL | 属于DDL |
| 回滚 | 可回滚 | 不可回滚 | 不可回滚 |
| 删除内容 | 表结构还在，删除表的全部或者一部分数据行 | 表结构还在，删除表中的所有数据 | 从数据库中删除表，所有的数据行，索引和权限也会被删除 |
| 删除速度 | 删除速度慢，需要逐行删除 | 删除速度快 | 删除速度最快 |
因此，在不再需要一张表的时候，用drop；在想删除部分数据行时候，用delete；在保留表而删除所有数据的时候用truncate。
说出一些数据库优化方面的经验?
- 有外键约束的话会影响增删改的性能，如果应用程序可以保证数据库的完整性那就去除外键
- Sql语句全部大写，特别是列名大写，因为数据库的机制是这样的，sql语句发送到数据库服务器，数据库首先就会把sql编译成大写在执行，如果一开始就编译成大写就不需要了把sql编译成大写这个步骤了
- 如果应用程序可以保证数据库的完整性，可以不需要按照三大范式来设计数据库
- 其实可以不必要创建很多索引，索引可以加快查询速度，但是索引会消耗磁盘空间
- 如果是jdbc的话，使用PreparedStatement不使用Statement，来创建SQl，PreparedStatement的性能比Statement的速度要快，使用PreparedStatement对象SQL语句会预编译在此对象中，PreparedStatement对象可以多次高效的执行
怎么优化SQL查询语句吗
- 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引
- 用索引可以提高查询
- SELECT子句中避免使用*号，尽量全部大写SQL
- 应尽量避免在 where 子句中对字段进行 is null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，使用 IS NOT NULL
- where 子句中使用 or 来连接条件，也会导致引擎放弃使用索引而进行全表扫描
- in 和 not in 也要慎用，否则会导致全表扫描
Mysql 如何优化 DISTINCT？
DISTINCT 在所有列上转换为 GROUP BY，并与 ORDER BY 子句结合使用
如何输入字符为十六进制数字？
如果想输入字符为十六进制数字，可以输入带有单引号的十六进制数字和前缀（X），或者
只用（Ox）前缀输入十六进制数字。
如果表达式上下文是字符串，则十六进制数字串将自动转换为字符串。
你怎么知道SQL语句性能是高还是低
- 查看SQL的执行时间
- 使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MYSQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
大表数据查询，怎么优化
- 优化shema、sql语句+索引；
- 第二加缓存，memcached, redis；
- 主从复制，读写分离；
- 垂直拆分，根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；
- 水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key, 为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；
大表怎么优化？
- 限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。；
- 读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；
- 缓存： 使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存；
分库分表策略、工具
全网最全的分库分表方案_vincent-CSDN博客_分库分表工具
数据库瓶颈
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。
1、IO瓶颈
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。
2、CPU瓶颈
第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。
第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。
1、水平分库
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
结果：
每个库的结构都一样；
每个库的数据都不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。
分析：库多了，io和cpu的压力自然可以成倍缓解。
2、水平分表
概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
结果：
每个表的结构都一样；
每个表的数据都不一样，没有交集；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。推荐：一次SQL查询优化原理分析
分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。
3、垂直分库
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
结果：
每个库的结构都不一样；
每个库的数据也不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。
分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。
4、垂直分表
概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
结果：
每个表的结构都不一样；
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。
分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。
但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。
分库分表工具
sharding-sphere：jar，前身是sharding-jdbc；
TDDL：jar，Taobao Distribute Data Layer；
Mycat：中间件。
分库分表后面临的问题
-
事务支持 分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
-
跨库join
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品
-
跨节点的count,order by,group by以及聚合函数问题 这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
-
数据迁移，容量规划，扩容等问题 来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
-
ID问题
-
一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略
- UUID 使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。 Twitter的分布式自增ID算法Snowflake 在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。
跨分片的排序分页问题
一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。如下图所示：
MySQL的复制原理以及流程
主从复制：将主数据库中的DDL和DML操作通过二进制日志（BINLOG）传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。
主从复制的作用
- 主数据库出现问题，可以切换到从数据库。
- 可以进行数据库层面的读写分离。
- 可以在从数据库上进行日常备份。
MySQL主从复制解决的问题
- 数据分布：随意开始或停止复制，并在不同地理位置分布数据备份
- 负载均衡：降低单个服务器的压力
- 高可用和故障切换：帮助应用程序避免单点失败
- 升级测试：可以用更高版本的MySQL作为从库
MySQL主从复制工作原理
- 在主库上把数据更高记录到二进制日志
- 从库将主库的日志复制到自己的中继日志
- 从库读取中继日志的事件，将其重放到从库数据中
基本原理流程，3个线程以及之间的关联
-
主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
-
从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进自己的relay log中；
-
从：sql执行线程——执行relay log中的语句；
读写分离有哪些解决方案？
- 读写分离是依赖于主从复制，而主从复制又是为读写分离服务的。因为主从复制要求
slave不能写只能读（如果对slave执行写操作，那么show slave status将会呈现Slave_SQL_Running=NO，此时你需要按照前面提到的手动同步一下slave）。
方案一
-
使用mysql-proxy代理
-
优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议实际生产中使用
-
缺点：降低性能， 不支持事务
方案二
- 使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。
- 如果采用了mybatis， 可以将读写分离放在ORM层，比如mybatis可以通过mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select 都访问salve库，这样对于dao层都是透明。 plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不过这样依然有一个问题， 也就是不支持事务， 所以我们还需要重写一下DataSourceTransactionManager， 将read-only的事务扔进读库， 其余的有读有写的扔进写库。
方案三
-
使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务.
-
缺点：类内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理。
备份计划，mysqldump以及xtranbackup的实现原理
(1)备份计划
-
视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为 mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备份出来的文件比较小，压缩之后更小)。
-
100G 以上的库，可以考虑用 xtranbackup 来做，备份速度明显要比 mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。
(2)备份恢复时间
-
物理备份恢复快，逻辑备份恢复慢
-
这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考
-
20G的2分钟（mysqldump）
-
80G的30分钟(mysqldump)
-
111G的30分钟（mysqldump)
-
288G的3小时（xtra)
-
3T的4小时（xtra)
-
逻辑导入时间一般是备份时间的5倍以上
(3)备份恢复失败如何处理
首先在恢复之前就应该做足准备工作，避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错，再根据报错的提示来进行相应的调整。
(4)mysqldump和xtrabackup实现原理
-
mysqldump
mysqldump 属于逻辑备份。加入–single-transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)，之后显式开启一个事务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上–master-data=1 的话，在刚开始的时候还会加一个数据库的读锁(FLUSH TABLES WITH READ LOCK),等开启事务后，再记录下数据库此时 binlog 的位置(showmaster status)，马上解锁，再读取表的数据。等所有的数据都已经导完，就可以结束事务
-
Xtrabackup:
xtrabackup 属于物理备份，直接拷贝表空间文件，同时不断扫描产生的 redo 日志并保存下来。最后完成 innodb 的备份后，会做一个 flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作会丢数据)，确保所有的 redo log 都已经落盘(涉及到事务的两阶段提交
-
概念，因为 xtrabackup 并不拷贝 binlog，所以必须保证所有的 redo log 都落盘，否则可能会丢最后一组提交事务的数据)。这个时间点就是 innodb 完成备份的时间点，数据文件虽然不是一致性的，但是有这段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事情)。然后还需要 flush tables with read lock，把 myisam 等其他引擎的表给备份出来，备份完后解锁。这样就做到了完美的热备。
数据表损坏的修复方式有哪些？
使用 myisamchk 来修复，具体步骤：
- 1 修复前将mysql服务停止。
- 2 打开命令行方式，然后进入到mysql的/bin目录。
- 3 执行myisamchk –recover 数据库所在路径/*.MYI
MySQL 5.6 和 MySQL 5.7 对索引做了哪些优化？
MySQL5.6 引入了索引下推优化，默认是开启的。
例子：user 表中（a,b,c）构成一个索引。
select * from user where a='23' and b like '%eqw%' and c like 'dasd'。 l
解释：如果没有索引下推原则，则 MySQL 会通过 a='23' 先查询出一个对应的数
据。然后返回到 MySQL 服务端。MySQL 服务端再基于两个 like 模糊查询来校验
and 查询出的数据是否符合条件。这个过程就设计到回表操作。
如果使用了索引下推技术，则 MySQL 会首先返回返回条件 a='23'的数据的索引，然
后根据模糊查询的条件来校验索引行数据是否符合条件，如果符合条件，则直接根据
索引来定位对应的数据，如果不符合直接 reject 掉。因此，有了索引下推优化，可以
在有 like 条件的情况下，减少回表的次数。
一张表，里面有 ID 自增主键，当 insert 了 17 条记录之后，删除了第 15,16,17 条记录，再把 Mysql 重启，再 insert 一条记录，这条记录的 ID 是 18 还是 15 ？
(1)如果表的类型是 MyISAM，那么是 18
因为 MyISAM 表会把自增主键的最大 ID 记录到数据文件里，重启 MySQL 自增主键的最大ID 也不会丢失
（2）如果表的类型是 InnoDB，那么是 15
InnoDB 表只是把自增主键的最大 ID 记录到内存中，所以重启数据库或者是对表进行OPTIMIZE 操作，都会导致最大 ID 丢失
federated 表是什么？
federated 表，允许访问位于其他服务器数据库上的表。
如果一个表有一列定义为 TIMESTAMP，将发生什么？
每当行被更改时，时间戳字段将获取当前时间戳。
列设置为 AUTO INCREMENT 时，如果在表中达到最大 值，会发生什么情况？
它会停止递增，任何进一步的插入都将产生错误，因为密钥已被使用。
怎样才能找出最后一次插入时分配了哪个自动增量？
LAST_INSERT_ID 将返回由 Auto_increment 分配的最后一个值，并且不需要指定表名 称。
你怎么看到为表格定义的所有索引？
索引是通过以下方式为表格定义的： SHOW INDEX FROM <tablename>;
LIKE 声明中的％和_是什么意思？
％对应于 0 个或更多字符，_只是 LIKE 语句中的一个字符。
如何在 Unix 和 Mysql 时间戳之间进行转换？
UNIX_TIMESTAMP 是从 Mysql 时间戳转换为 Unix 时间戳的命令 FROM_UNIXTIME 是从 Unix 时间戳转换为 Mysql 时间戳的命令
NOW（）和 CURRENT_DATE（）有什么区别？
NOW（）命令用于显示当前年份，月份，日期，小时，分钟和秒。
CURRENT_DATE（）仅显示当前年份，月份和日期。
Mysql 里记录货币用什么字段类型好
NUMERIC 和 DECIMAL 类型被 Mysql 实现为同样的类型，这在 SQL92 标准允许。他们被用于
保存值，该值的准确精度是极其重要的值，例如与金钱有关的数据。当声明一个类是这些
类型之一时，精度和规模的能被(并且通常是)指定；点击这里有一套最全阿里面试题总
结。
例如：
salary DECIMAL(9,2)
在这个例子中，9(precision)代表将被用于存储值的总的小数位数，而 2(scale)代表将被用于
存储小数点后的位数。
因此，在这种情况下，能被存储在 salary 列中的值的范围是从-9999999.99 到 9999999.99。 在 ANSI/ISO SQL92 中，句法 DECIMAL(p)等价于 DECIMAL(p,0)。
同样，句法 DECIMAL 等价于 DECIMAL(p,0)，这里实现被允许决定值 p。Mysql 当前不支持
DECIMAL/NUMERIC 数据类型的这些变种形式的任一种。
这一般说来不是一个严重的问题，因为这些类型的主要益处得自于明显地控制精度和规模
的能力。
DECIMAL 和 NUMERIC 值作为字符串存储，而不是作为二进制浮点数，以便保存那些值的小
数精度。
一个字符用于值的每一位、小数点(如果 scale>0)和“-”符号(对于负值)。如果 scale 是 0，
DECIMAL 和 NUMERIC 值不包含小数点或小数部分。
DECIMAL 和 NUMERIC 值得最大的范围与 DOUBLE 一样，但是对于一个给定的 DECIMAL 或
NUMERIC 列，实际的范围可由制由给定列的 precision 或 scale 限制。
当这样的列赋给了小数点后面的位超过指定 scale 所允许的位的值，该值根据 scale 四舍五
入。
当一个 DECIMAL 或 NUMERIC 列被赋给了其大小超过指定(或缺省的）precision 和 scale 隐含
的范围的值，Mysql 存储表示那个范围的相应的端点值。
我希望本文可以帮助你提升技术水平。那些，感觉学的好难，甚至会令你沮丧的人，别担
心，我认为，如果你愿意试一试本文介绍的几点，会向前迈进，克服这种感觉。这些要点
也许对你不适用，但你会明确一个重要的道理：接受自己觉得受困这个事实是摆脱这个困
境的第一步。
MYSQL 数据表在什么情况下容易损坏？
服务器突然断电导致数据文件损坏。
强制关机，没有先关闭 mysql 服务等。
表中有大字段 X（例如：text 类型），且字段 X 不会经常更新，以读为为主，将该字段拆成子表好处是什么？
如果字段里面有大字段（text,blob)类型的，而且这些字段的访问并不多，这时候放在一起就变成缺点了。 MYSQL 数据库的记录存储是按行存储的，数据块大小又是固定的（16K），每条记录越小，相同的块存储的记录就越多。此时应该把大字段拆走，这样应付大部分小字段的查询时，就能提高效率。当需要查询大字段时，此时的关联查询是不可避免的，但也是值得的。拆分开后，对字段的 UPDAE 就要 UPDATE 多个表了
如何基于Canal 和 Kafka，实现 MySQL 的 Binlog 近实时同步？
如何基于Canal 和 Kafka，实现 MySQL 的 Binlog 近实时同步？_vincent-CSDN博客_canal kafka mysql
扫一扫
6497
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
