Mysql从入门到删库之sql语句的优化
数据库三范式与逆范式
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
第一范式1NF，原子性
第二范式2NF，消除部分依赖
第三范式3NF，消除传递依赖
1、范式
（1）第一范式：具有原子性，确保每列保持原子性。
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式。
（2）第二范式：主键列与非主键列遵循完全函数依赖关系，确保表中的每列都和主键相关。
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
（3）第三范式：非主键列之间没有传递函数依赖关系索引，确保每列都和主键列直接相关,而不是间接相关。
所谓传递函数依赖，指的是如果存在"A→B→C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段→非关键字段x→非关键字段y
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。
先满足第一范式，再满足第二范式，才能满足第三范式。
2、逆范式
逆范式是指打破范式，通过增加冗余或重复的数据来提高数据库的性能。
示例： 假如有一个学校表school：
字段有school_id(学校id), school_name(学校名称)。
还有一个学生表student：
字段有stu_id(学生id), stu_name(学生名称)，stu_school(所属学校id)。
现在要查询学校为id为3的学生的数量，
可以使用下列sql语句：
Select c.*, count(g.stu_id) from school c left join student g c.school_id=g.stu_school group by c.school_id;
但是，假如学生数量较大，那么就比较耗性能了。这时，我们可以考虑重新设计school表：增加存当前学校下学生数量的字段。
每当学生改动时，修改对应学校学生的数量信息。
再查询分类列表时：Select * from school;
此时额外的消耗，出现在维护该字段的正确性上，保证学校的任何更新都正确的处理该数量才可以。
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个字节的定长字节字符串 |
MySql 存储引擎
在创建表的时候我们使用sql语句，
Create table tableName () engine=myisam|innodb;
这里就指明了存储引擎是myisam还是innodb。存储引擎是一种用来存储MySQL中对象（记录和索引）的一种特定的结构（文件结构），处于MySQL服务器的最底层，直接存储数据。导致上层的操作，依赖于存储引擎的选择。
MySQL支持很多存储引擎，包括MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、ARCHIVE等，其中InnoDB和BDB支持事务安全。它还支持一些第三方的存储引擎，例如TokuDB（高写性能高压缩存储引擎）、Infobright（列式存储引擎）。
查看当前表的存储引擎
show create table t_user
查看当前数据库支持的存储引擎
show engines
可以在创建表的时候指定存储引擎engine=innodb，也可以不指定 ，mysql5.5之前默认是myisam,5.5之后默认是innodb.
也可以在创建完表之后修改
alter table t_user engine=innodb;
Innodb 介绍
MySQL5.5之后的默认存储引擎，MySQL推荐使用的存储引擎。支持事务，行级锁定，外键约束。事务安全型存储引擎。更加注重数据的完整性和安全性。
优点：提供了具有提交（Commit）、回滚（Rollback）、崩溃恢复能力的事务安全，支持外键。
缺点：相比较于MyISAM，写的处理效率差一点，并且会占用更多的磁盘空间来存储数据和索引
特点：
1、自动增长列
innoDB表的自动增长列必须是索引，如果是组合索引，也必须是组合索引的第一列
MyISAM表的自动增长列可以是组合索引的其他列
设置自动增长列：create表时，在字段后加auto_increment
可以通过alter table emp auto_increment=n 来强制设置自动增长列的初始值，默认是1，但是该强制指定的值是保存在内存中的，所以在数据库重启后会失效，需要重新设置
2、外键约束
MySQL的存储引擎中只有innoDB支持外键约束
注意：当某个表被其它表创建了外键参照，那么该表对应的索引和主键禁止被删除
当导入多个表的数据时，如果要忽略表之前导入顺序，或者当执行load data和alter table操作，为了提高处理速度的时候，可以暂时关闭外键约束，命令是
mysql> set foreign_key_checks=0;
执行完之后，再使其为1 ，开启外键。
查看外键信息
show create table 或show table status
3、存储方式
innoDB存储数据和索引有共享表空间存储和独占表空间存储两种方式，通过参数innodb_file_per_table控制，0表示共享空间，也是默认的，1表示独占空间
两种方式的表结构（描述）都保存在.frm文件中
共享表空间：
每一个数据库的所有表的数据、索引都保存在一个文件中，默认在data目录下，名为ibdata1，大小为10M的文件，可以通过参数innodn_data_file_path=/data/ibdata1:2000M来指定存储路径。
优点：
（1）、可以将表空间分为多个文件放在不同的磁盘上，分布IO，提高性能。innodn_data_file_path=/data/ibdata1:2000M；/db/ibdata2:2000M:autoextend
autoextend表示如果指定的2000M空间用满后，该文件自动增长。
也就是说采用共享空间存储，存储空间的大小不受文件系统下文件大小的限制了，而取决于自身的限制，官方文档显示，表空间的最大限制是64TB。
（2）、可以将表空间分成多个文件存放在各个磁盘上（表空间文件大小不受表大小的限制，如一个表可以分布在不同的文件上），数据和文件放在一起方便管理。
缺点： 由于所有的数据和索引都是在一个文件中混合存储，这样的话对一个表做了大量的删除操作后，表空间中会产生大量的空隙，特别是对统计分析、日值系统这类应用最不适合用共享表空间。
独占表空间：
每一张表都有自己独立的表空间，表的结构依然在.frm文件中，还有一个后缀为.ibd的文件，保存了这张表的数据和索引。
优点：
每个表都有自己独立的表空间；每个表的数据和索引都会存储在各个独立的表空间中；可以实现单表在不同的数据进行迁移；表空间可以回收（除了drop table操作，表空不能自己回收）；drop table 操作自动回收表空间，如果对统计分析或是日值表，删除大量数据后可以通过 ：alter table tablename engin=innodb进行回缩不用的空间；对于使用inodb-plugin的innodb使用truncate table会使用空间收缩。；对于使用独立表空间，不管怎么删除，表空间的碎片都不会太严重。
效率和性能会好一些
缺点： 由于每个表的数据都是以一个单独的文件来存放，所以会受到文件系统的大小限制
4、支持行锁
innodb擅长处理并发的。因为它使用了行级锁定，只该行锁了，其它行没有锁。
行级锁定：row-level locking，实现了行级锁定，在一定情况下，可以选择行级锁来提升并发性。也支持表级锁定，Innodb会自带锁，不需要我们自己设置。
多版本并发控制, MVCC，效果达到无阻塞读操作。
应用场景：innodb擅长事务、数据的完整性及高并发处理，不擅长快速插入（插入前要排序，消耗时间）和检索。如果应用对事务的完整性有较高的要求，在并发条件下要求数据的一致性，数据操作中包含读、插入、删除、更新，那InnoDB是最好的选择。在计费系统、财务系统等对数据的准确性要求较高的系统中被广泛应用。
MyISAM介绍
MySQL<= 5.5 MySQL默认的存储引擎。
ISAM：Indexed Sequential Access Method(索引顺序存取方法)的缩写，是一种文件系统。
擅长与处理，高速读与写。
不支持外键 不支持行级锁
1、存储方式
数据和索引分别存储于不同的文件中。
2 、插入顺序
数据的存储顺序为插入顺序（没有经过排序，插入速度快，空间占用量小。
innodb 数据按照主键顺序存储。
3、并发性：
仅仅支持表级锁定，不支持高并发。
支持并发插入。写操作中的插入操作，不会阻塞读操作（其他操作）
关于Innodb 和myisam的取舍：
| 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 是堆表，是非聚簇索引，MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。 | B+树索引，Innodb 是索引组织表，聚簇索引，InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。 |
| 哈希索引 | 不支持 | 支持 |
| 全文索引 | 支持 | 不支持 |
| 结论 | 高速查询及插入。擅长插入和查询。 | 数据完整性，并发性处理，擅长更新，删除。如果没有特别的需求，使用默认的Innodb即可。 |
MEMORY介绍
内存型，数据存储于内存中，存储引擎。缓存型存储引擎。MEMORY存储引擎是用保存在内存中的数据来创建表，每个memory表对应一个磁盘文件。格式是.frm
特点：由于他的数据是存放在内存中的，并且默认使用HASH索引，所以它的访问速度特别快，同时也造成了他的缺点，就是数据库服务一旦关闭，数据就会丢失，另外对表的大小有限制
每个memary表中可存储数据量的大小，受到max_heap_table_size变量的约束，他的初始值是16MB，可以在定义Memary表的时候通过max_rows指定表的最大行数
适用场景：内容变化不频繁的代码表，作为统计操作的中间结果表，便于利用它速率快的优势高效的对中间结果进分析。
MySql 索引
索引概述
MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。利用关键字，就是记录的部分数据（某个字段，某些字段，某个字段的一部分），建立与记录位置的对应关系，就是索引。索引的关键字一定是排序的。索引本质上是表字段的有序子集，它是提高查询速度最有效的方法。一个没有建立任何索引的表，就相当于一本没有目录的书，在每次查询时就会进行全表扫描，这样会导致查询效率极低、速度也极慢。如果建立索引，那么就好比一本添加的目录，通过目录的指引，迅速翻阅到指定的章节，提升的查询性能，节约了查询资源。
索引优缺点
优点：
索引大大减小了服务器需要扫描的数据量
索引可以帮助服务器避免排序和临时表
索引可以将随机IO变成顺序IO
索引对于InnoDB（对索引支持行级锁）非常重要，因为它可以让查询锁更少的元组。在MySQL5.1和更新的版本中，InnoDB可以在服务器端过滤掉行后就释放锁，但在早期的MySQL版本中，InnoDB直到事务提交时才会解锁。对不需要的元组的加锁，会增加锁的开销，降低并发性。 InnoDB仅对需要访问的元组加锁，而索引能够减少InnoDB访问的元组数。但是只有在存储引擎层过滤掉那些不需要的数据才能达到这种目的。一旦索引不允许InnoDB那样做（即索引达不到过滤的目的），MySQL服务器只能对InnoDB返回的数据进行WHERE操作，此时，已经无法避免对那些元组加锁了。如果查询不能使用索引，MySQL会进行全表扫描，并锁住每一个元组，不管是否真正需要。
关于InnoDB、索引和锁：InnoDB在二级索引上使用共享锁（读锁），但访问主键索引需要排他锁（写锁）
缺点：
虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存索引文件。
建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。
如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
对于非常小的表，大部分情况下简单的全表扫描更高效
MySQL里同一个数据表里的索引总数限制为16个。
索引分类
从索引的定义方式和用途中来看：主键索引，唯一索引，普通索引，全文索引。
普通索引,index：对关键字没有要求。
唯一索引,unique index：要求关键字不能重复。同时增加唯一约束。
主键索引,primary key：要求关键字不能重复，也不能为NULL。同时增加主键约束。
全文索引,fulltext key：关键字的来源不是所有字段的数据，而是从字段中提取的特别关键词。
复合索引，如果一个索引通过在多个字段上提取的关键字，称之为复合索引。 命令:alter table exp add index (field1, field2);
innodb 和myisam 索引的实现
MyISAM引擎使用B+Tree作为索引结构，叶节点data域存放数据记录的地址
是一颗B+Tree，data域保存数据记录的地址。
因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分
InnoDB索引实现
虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同
第一个重大区别是InnoDB的数据文件本身就是索引文件。
MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址
而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引
可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。
因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形
第二个与MyISAM索引的不同是InnoDB的辅索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如，
这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，
例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅索引都引用主索引，过长的主索引会令辅索引变得过大。
再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择
索引的使用
使用索引的时候需要遵循一些原则，否则会导致索引失效
1.列独立
如果需要某个字段上使用索引，则需要在字段参与的表达中，保证字段独立在一侧。或者不要在列上进行运算
第三个语句 empno-1就不是列独立：就不能用索引。类似函数等等。（write_time < unix_timestamp()-$gc_maxlifetime）
2.最左前缀匹配
Like：匹配模式必须要左边确定不能以通配符开头。
复合索引：一个索引关联多个字段，必须从左开始的索引都有使用到，如果只是使用了后面的索引 ，那么无效。
使用索引排序时，ORDER BY也要遵守“最左前缀”原则
1.当索引的顺序与ORDER BY中的列顺序相同，且所有的列是同一方向（全部升序或者全部降序）时，可以使用索引来排序。
2.ORDER BY子句和查询型子句的限制是一样的：需要满足索引的最左前缀的要求，有一种情况下ORDER BY子句可以不满足索引的最左前缀要求，那就是前导列为常量时：WHERE子句或者JOIN子句中对前导列指定了常量。
3.如果查询是连接多个表，仅当ORDER BY中的所有列都是第一个表的列时才会使用索引。其它情况都会使用filesort文件排序。
3.尽量不要使用NOT IN、<>、!= 操作
应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
对于not in，可以用not exists或者（外联结+判断为空）来代替；很多时候用 exists 代替 in 是一个好的选择： select num from a where num in(select num from b) 用下面的语句替换： select num from a where exists(select 1 from b where num=a.num)
4.OR的使用
必须要保证 OR 两端的条件都存在可以用的索引，该查询才可以使用索引。用 or 分割开的条件， 如果 or 前的条件中的列有索引， 而后面的列中没有索引， 那么涉及到的索引都不会被用到。