SQL基础
1.MySQL的数据类型
2.MySQL的SQL语句分类
DDL（Data Definition Language）语句：数据定义语言,这些语句定义了不同的数据段、表、列、索引等数据库对象的定义。常用的语句关键字主要包括create、drop、alter等。
DML（Data Manipulation Language）语句：数据操纵语句，用于添加、删除、更新和查询数据库记录，并检查数据完整性，常用的语句关键字主要包括insert、delete、update和select等。
DCL（Data Control Language）语句：数据控制语句，用于控制不同数据段直接的许可和访问级别的语句。这些语句定义了数据库、表、字段、用户的访问权限和安全级别。主要的语句关键字包括grant、revoke等。
数据库范式
第一范式（1NF）是指在关系模型中，数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
第二范式（2NF）是在1NF的基础上，要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性
第三范式（3NF）在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
巴斯-科德范式（BCNF）在3NF基础上，任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）
白话区:
第一范式：每个表应该有唯一标识每一行的主键。
第二范式：在复合主键的情况下，非主键部分不应该依赖于部分主键。
第三范式：非主键之间不应该有依赖关系。
BC范式:排除了任何属性(不光是非主属性，2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。
MyISAM与Innodb区别
(1)MyISAM不支持事务,Innodb支持事务
(2)Myisam不支持外键,innodb支持外键
(3)myisam支持表级锁,innodb支持行级锁
(4)innodb 进行select count(*) from tablename时,需要对表进行一次遍历;myisam进行select count(*) from tablename时
(5)myisam删除表时,先将表drop,然后新建一个表;innodb则是将表中数据一条一条的删除
(6)对于包含auto-increment字段的索引,innodb只包含auto-increment字段;而myisam则可以和其他字段一起建立联合索引
(7)myisam搜索引擎查找要比innodb搜索引擎快
(8)innodb中索引没有fulltext类型,而myisam中有fulltext类型
视图
视图（View）是一种虚拟存在的表，对于使用视图的用户来说基本上是透明的。视图并
不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表，并且是在使用视图时
动态生成的
简单：使用视图的用户完全不需要关心后面对应的表的结构、关联条件和筛选条件，
对用户来说已经是过滤好的复合条件的结果集。
安全：使用视图的用户只能访问他们被允许查询的结果集，对表的权限管理并不能
限制到某个行某个列，但是通过视图就可以简单的实现。
数据独立：一旦视图的结构确定了，可以屏蔽表结构变化对用户的影响，源表增加
列对视图没有影响；源表修改列名，则可以通过修改视图来解决，不会造成对访问
者的影响
事务的特性及隔离级别:
1.事务特性--ACID
Atomicity(原子性):要么全做,要么不做,不能只做一半(银行转账)
Consistency(约束性):事务的前后,约束都能满足
Isolation(依赖性):事务之间是独立的,互不影响的
Durability(持久性):事务执行之后,事物的结果可以持久保存
2.事务隔离级别:
read uncommitted:可以读到未提交的事务结果
read committed:只能读已提交事务的结果
repeatable reads:可以读到开启事务时的值
serializable:两个事务同时发生,必定是有先后的
索引
1.什么是索引
索引（Index）是帮助MySQL高效获取数据的数据结构。
2.索引的种类
从逻辑角度
1、主键索引：主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”
2、唯一索引：不允许具有索引值相同的行，从而禁止重复的索引或键值。系统在创建该索引时检查是否有重复的键值，并在每次使用 INSERT 或 UPDATE 语句添加数据时进行检查。
3、组合索引
从物理存储角度
1、聚簇索引（clustered index）：聚簇索引的叶子节点就是数据节点
2、非聚簇索引（non-clustered index）：非聚簇索引的叶子节点仍然是索引节点，只不过有指向对应数据块的指针。
从数据结构角度
1、B+树索引
2、hash索引
3、FULLTEXT索引（InnoDB引擎5.7以后支持）：
3.索引的设计原则
4.索引存在但是不使用索引
(1)如果MySQL估计使用索引比全表扫描更慢,则不使用索引。例如如果列key_part1均匀分布在1~100之间,下列查询使用索引就不是很好
SELECT * FROM table_name where key_part1 > 1 and key_part1 < 90;
(2)如果使用 MEMORY/HEAP 表并且 where 条件中不使用“=”进行索引列，那么不会用到索引。heap 表只有在“=”的条件下才会使用索引。
(3)用 or 分割开的条件，如果 or 前的条件中的列有索引，而后面的列中没有索引，那么涉及到的索引都不会被用到，例如
(4)对于符合索引如果不是第一列,在查询中也不会被MySQL用到
(5)如果like是以%开始,那么索引不会被MySQL使用
(6)如果列类型是字符串，那么一定记得在 where 条件中把字符常量值用引号引起来，否则的话即便这个列上有索引，MySQL 也不会用到的，因为，MySQL 默认把输入的常量值进行转换以后才进行检索。
5.B+Tree索引
B+树：B+树是为磁盘或其他直接存取辅助设备设计的一种平衡查找树。在B+树中，所有记录结点都是按键值的大小顺序存放在同一层的叶子节点上，由各叶子节点指针进行连接。
数据库中B+树索引分为聚集索引和辅助索引,两者内部都是B+树,即高度平衡的,叶子节点存放着所有的数据。聚集索引与辅助索引不同的是，叶子节点存放的是否是一整行的信息。
聚集索引
聚集索引：聚集索引就是按照每张表的主键构造的一棵B+树，同时叶子节点中存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。
辅助索引
慢查询
1.为什么查询速度会慢
查询性能低下最基本的原因是访问的数据太多。某些查询可能不可避免的需要筛选大量数据，但这并不常见。大部分性能低下的查询都可以减少访问的数据量的方式进行优化。对于低效的查询，我们发现通过下面两个步骤来分析总是很有效：
（1）确认应用程序是否在检索大量超过需要的数据。这通常意味着访问了太多的行，但有时候也可能是访间了太多的列。
（2）确认MYSQL服务器层是否在分析大量超过需要的数据行。
2.慢查询基础
（1）是否向数据库请求了不需要的数据
查询不需要的记录
一个常见的错误是常常会误以为MYSQL会只返回需要的数据，实际上MYSQL却
是先返回全部结果集再进行计算。我们经常会看到一些了解其他数据库系统的人会
设计出这类应用程序。这些开发者习惯使用这样的技术，先使用SELECT语句查询大
量的结果，然后获取前面的N行后关闭结果集（例如在新闻网站中取出100条记录，
但是只是在页面上显示前面10条）。他们认为MYSQL会执行查询，并只返回他们
需要的10条数据，然后停止查询。实际情况是MYSQL会查询出全部的结果集，客
户端的应用程序会接收全部的结果集数据，然后抛弃其中大部分数据。最简单有效
的解决方法就是在这样的查询后面加上LIMIT。
多表关联时返回全部列
如果你想查询所有在电影Academy Dinosaur中出现的演员，千万不要按下面的写法
编写查询:
ysql> select FRO sakila. Actor MER torn sakila. fin actor usimg(actor. id -2 INBROR, 5azla to. Mt -) WERE sakila. Film. Title - 'acadery Dinosaur'; 这将返回这三个表的全部数据列。正确的方式应该是像下面这样只取需要的列: my5ql> SELECT sakila. Actor. " fro sakila. Actor. . ;
总是取出全部列
每次看到SELECT *的时候都需要用怀疑的眼光审视，是不是真的需要返回全部的
列?很可能不是必需的。取出全部列，会让优化器无法完成索引覆盖扫描这类优化，
还会为服务器带来额外的I/O、内存和CPU的消耗。因此，一些DBA是严格禁止
SELECT *的写法的，这样做有时候还能避免某些列被修改带来的问题。
当然，查询返回超过需要的数据也不总是坏事。在我们研究过的许多案例中，人们
会告诉我们说这种有点浪费数据库资源的方式可以简化开发，因为能提高相同代码
片段的复用性，如果清楚这样做的性能影响，那么这种做法也是值得考虑的。如果
应用程序使用了某种缓存机制，或者有其他考虑，获取超过需要的数据也可能有其
好处，但不要忘记这样做的代价是什么。获取并缓存所有的列的查询，相比多个独
立的只获取部分列的查询可能就更有好处。
重复查询相同的数据
如果你不太小心，很容易出现这样的错误——不断地重复执行相同的查询，然后每
次都返回完全相同的数据。例如，在用户评论的地方需要查询用户头像的URL,那
么用户多次评论的时候，可能就会反复查询这个数据。比较好的方案是，当初次查
的的时候将这个数据缓存起来，需要的时候从缓存中取出，这样性能显然会更好
（2）MySQL是否在扫描额外的记录
响应时间
扫描行数
返回的行数
3.查看慢查询日志
慢查询日志记录了包含所有执行时间超过参数 long_query_time（单位：秒）所设置值的 SQL
语句的日志。获得表锁定的时间不算作执行时间。
(1) 文件位置和格式
当用--log-slow-queries[=file_name]选项启动 mysqld（MySQL 服务器）时，慢查询日志开始被
记录。和前面几种日志一样，如果没有给定 file_name 的值，日志将写入参数 DATADIR（数
据目录）指定的路径下，默认文件名是 host_name-slow.log。
(2) 日志的读取
和错误日志、查询日志一样，慢查询日志记录的格式也是纯文本，可以被直接读取。下例中
演示了慢查询日志的设置和读取过程。
(2.1)首先查询一下 long_query_time 的值。
mysql> show variables like 'long%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | long_query_time | 10 | +-----------------+-------+ 1 row in set (0.00 sec)
（2.2）为了方便测试，将修改慢查询时间为 2 秒。
mysql> set long_query_time=2; Query OK, 0 rows affected (0.02 sec)
（2.3）依次执行下面两个查询语句。
第一个查询因为查询时间低于 2 秒而不会出现在慢查询日志中：
mysql> select count(1) from emp; +----------+ | count(1) | +----------+ | 131075 | +----------+ 1 row in set (0.00 sec)
第二个查询因为查询时间大于 2 秒而应该出现在慢查询日志中：
mysql> select count(1) from emp t1,dept t2 where t1.id=t2.id; 322 +----------+ | count(1) | +----------+ | 33555200 | +----------+ 1 row in set (11.31 sec)
（2.4）查看慢查询日志。
[root@localhost mysql]# more localhost-slow.log /usr/sbin/mysqld, Version: 5.0.41-community-log (MySQL Community Edition (GPL)). started with: Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock Time Id Command Argument # Time: 070810 23:43:55 # User@Host: root[root] @ localhost [] # Query_time: 297 Lock_time: 0 Rows_sent: 0 Rows_examined: 26214 use test; # Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 512 select count(1) from emp t1,dept t2 where t1.id=t2.id;
从上面日志中，可以发现查询时间超过 2 秒的 SQL，而小于 2 秒的则没有出现在此日志中。
如果慢查询日志中记录内容很多，可以使用 mysqldumpslow 工具（MySQL 客户端安装自带）
来对慢查询日志进行分类汇总。下例中对日志文件 bj37-slow.log 进行了分类汇总，只显示汇
总后摘要结果：
[zzx@bj37 data]$ mysqldumpslow bj37-slow.log [root@localhost mysql]# mysqldumpslow localhost-slow.log Reading mysql slow query log from localhost-slow.log Count: 1 Time=297.00s (297s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@localhost select count(N) from emp t1,emp t2 where t1.id<>t2.id Count: 2 Time=11.00s (22s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@localhost select count(N) from emp t1,dept t2 where t1.id=t2.id Count: 1 Time=9.00s (9s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@localhost select count(N) from emp t1,emp t2 where t1.id=t2.id Count: 2 Time=3.00s (6s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@localhost select count(N) from emp t1,dept t2 where t1.id=t2.id and t1.id=N
对于 SQL 文本完全一致，只是变量不同的语句，mysqldumpslow 将会自动视为同一个语句进
行统计，变量值用 N 来代替。这个统计结果将大大增加用户阅读慢查询日志的效率，并迅
速定位系统的 SQL 瓶颈。
注意：慢查询日志对于我们发现应用中有性能问题的 SQL 很有帮助，建议正常情况下，打开此
日志并经常查看分析。
(3) 其他选项
在 MySQL 5.1 中，通过--log-slow-admin-statements 服务器选项，可以请求将慢管理语句，例
如 OPTIMIZE TABLE、ANALYZE TABLE 和 ALTER TABLE 写入慢查询日志
MySQL优化
1.优化SQL语句
(1)通过show status命令了解各种SQL的执行效率
例如show status like 'Com_%'
Com_select：执行select操作的次数，一次查询只累加1.
Com_insert：执行insert操作的次数，对于批量插入的INSERT操作，只累加一次。
Com_updated：执行UPDATE操作的次数。
Com_deleted：执行delle操作的次数。
Innodb_rows_read：select查询返回的行数.
Innodb_rows_inserted：执行INSERT操作插入的行数。
Innodb_rows_updated：执行UPDATE操作更新的行数
Innodb_rows_deleted：执行DELETE操作删除的行数。
Connections:：图连接MYSQL服务器的次数。
Uptime：服务器工作时间。
Slow_queries：慢查询的次数。
(2)定位性效率较低的SQL语句
通过慢查询日志定位那些执行效率较低的sql语句，用--log-slow-queries[=file_name]选
项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志
文件。
慢查询日志在查询结束以后才纪录，所以在应用反映执行效率出现问题的时候慢查
询日志并不能定位问题，可以使用show processlist命令查看当前mysql在进行的线程，
包括线程的状态、是否锁表等，可以实时地查看SOL的执行情况，同时对一些锁表操
作进行优化。
(3)通过Explain分析低效SQL的执行计划
Explain解析的每一列含义:
select_type:表示select的类型，常见的取值有simple(简单表，即不使用表连接
或者子查询）、PRIMARV(主查询，即外层的查询）、UNION(UNION中的第二个或
中的第二个或者后面的查询语句）、SUBQUERY (子查询中的第一个SHLECT)等。
table:输出结果集的表。
type:表示表的连接类型，性能由好到差的连接类型为
system(表中仅有一行，即常量表)、
const(单表中最多有一个匹配行，例如primary key或者unique index).
eq_ref(对于前面的每一行，在此表中只查询一条记录，简单来说，就是多表连接中使用primary key或者unique index)、
ref(与eq_ref类似，区别在于不是使用primary key或者unique index,而是使用普通的索引)、
ref_or_null(与ref类似，区别在于条件中包含对NULL的查询）、
index_merge(索引合并优化)、
unique_subquery (in的后面是一个查询主键字段的子查询）、
index_subquery(与unique_Subquery类似，区别在于in的后面是查询非唯一索引字段的子查询）、
range(单表中的范围查询）、
index(对于前面的每一行，都通过查询索引来得到数据）、
all(对于前面的每一行都通过全表扫描来得到数据）。
possible_keys:表示查询时，可能使用的索引
key:表示实际使用的索引。
key_len:索引字段的长度。
rows:扫描行的数量。
extra:执行情况的说明和描述。
(4)确定问题并采取相应的优化措施