13518219792
首先说说索引的 优点 ：最大的好处无疑就是提高查询效率。有的索引还能保证数据的唯一性，比如唯一索引。
创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于成都网站建设、网站制作、宿城网络推广、重庆小程序开发、宿城网络营销、宿城企业策划、宿城品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联公司为所有大学生创业者提供宿城建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
而它的 坏处 也很明显：索引也是文件，我们在创建索引时，也会创建额外的文件，所以会占用一些硬盘空间。其次，索引也需要维护，我们在增加删除数据的时候，索引也需要去变化维护。当一个表的索引多了以后，资源消耗是很大的，所以必须结合实际业务再去确定给哪些列加索引。
再说说索引的基本结构。一说到这里肯定会脱口而出：B+树！了解B+树前先要了解二叉查找树和二叉平衡树。 二叉查找树 ：左节点比父节点小，右节点比父节点大，所以二叉查找树的中序遍历就是树的各个节点从小到大的排序。 二叉平衡树 ：左右子树高度差不能大于1。B+树就是结合了它们的特点，当然，不一定是二叉树。
为什么要有二叉查找树的特点？？ 因为查找效率快，二分查找在这种结构下，查找效率是很快的。 那为什么要有平衡树的特点呢？ 试想，如果不维护一颗树的平衡性，当插入一些数据后，树的形态有可能变得很极端，比如左子树一个数据没有，而全在右子树上，这种情况下，二分查找和遍历有什么区别呢？而就是因为这些特点需要去维护，所以就有了上面提到的缺点，当索引很多后，反而增加了系统的负担。
接着说B+树。 它的结构如下 ：
可以发现，叶子节点其实是一个 双向循环链表 ，这种结构的好处就是，在范围查询的时候，我只用找到一个数据，就可以直接返回剩余的数据了。比如找小于30的，只用找到30，其余的直接通过叶子节点间的指针就可以找到。再说说其他特点： 数据只存在于叶子节点 。当叶子节点满了，如果再添加数据，就会拆分叶子节点，父节点就多了个子节点。如果父节点的位置也满了，就会扩充高度，就是拆分父节点，如25 50 75拆分成：25为左子树，75为右子树，50变成新的头节点，此时B+树的高度变成了3。它们的扩充的规律如下表，Leaf Page是叶子节点，index Page是非叶子节点。
再说说B树 ，B树相比较B+树，它所有节点都存放数据，所以在查找数据时，B树有可能没到达叶子节点就结束了。再者，B树的叶子节点间不存在指针。
最后说说Hash索引 ，相较于B+树，Hash索引最大的优点就是查找数据快。但是Hash索引最大的问题就是不支持范围查询。试想，如果查询小于30的数据，hash函数是根据数据的值找到其对应的位置，谁又知道小于30的有哪几个数据。而B+树正好相反，范围查询是它的强项。
附录： Hash到底是啥？？ 哈希中文名散列，哈希只是它的音译。 为啥都说Hash快？？ 首先有一块哈希表（散列表），它的数据结构是个数组，一个任意长度的数据通过hash函数都可以变成一个固定长度的数据，叫hash值。然后通过hash值确定在数组中的位置，相同数据的hash值是相同的，所以我们存储一个数据以后，只需O(1)的时间复杂度就可以找到数据。 那hash函数又是啥？？ 算术运算或位运算，很多应用里都有hash函数，但实际运算过程大不一样。这是Java里String的hashCode方法：
publicint hashCode() {
}
还有一个问题，hash函数计算出来的hash值有可能存在碰撞，即两个不同的数据可能存在相同的hash值，在MySQL或其他的应用中，如Java的HashMap等，如果存在碰撞就会以当前数组位置为头节点，转变成一个链表。
说到这里也清楚了为啥Java中引用类型要同时重写hashCode和equals了。两个对象，实例就算一模一样，它们的hash值也不相等， 为啥不相等？？ 默认的Object的hashCode方法会根据对象来计算hash值的，实例相同，但它们还是两个不同的对象啊，所以我们重写hashCode时，最简单的方法就是调用Object的hashCode方法，然后传入该引用类型的属性，让hashCode方法只根据这几个属性来计算，那么实例相同的话，它们的hash值也会相等。等hashCode比较完后，如果相等再比较实例内容，也就是equals，确保不是hash碰撞。
索引的分类
如果我们指定了一个主键，那么这个主键就是主键索引。如果我们没有指定，Mysql就会自动找一个非空的唯一索引当主键。如果没有这种字段，Mysql就会创建一个大小为6字节的自增主键。如果有多个非空的唯一索引，那么就让第一个定义为唯一索引的字段当主键，注意，是第一个定义，而不是建表时出现在前面的。
对于辅助索引来说，它们的B+树结构稍微有点特殊，它们的叶子节点存储的是主键，而不是整个数据。所以在大部分情况下，使用辅助索引查找数据，需要二次查找。但并不是所有情况都需要二次查找。比如查找的数据正好就是当前索引字段的值，那么直接返回就行。这里提一句，B+树的key就是对应索引字段的内容。
而辅助索引又有一些分类：唯一索引：不能出现重复的值，也算一种约束。普通索引：可以重复、可以为空，一般就是查询时用到。前缀索引：只适用于字符串类型数据，对字符串前几个字符创建索引。全文索引：作用是检测大文本数据中某个关键字，这也是搜索引擎的一种技术。
注意，聚集索引、非聚集索引和前面几个索引的分类并不是一个层面上的。上面的几个分类是从索引的作用来分析的。聚集、非聚集索引是从索引文件上区分的。主键索引就属于聚集索引，即索引和数据存放在一起，叶子节点存放的就是数据。数据表的.idb文件就是存放该表的索引和数据。
辅助索引属于非聚集索引，说到这也就明白了。索引和数据不存放在一起的就是非聚集索引。在MYISAM引擎中，数据表的.MYI文件包含了表的索引， 该表的 叶子节点存储索引和索引对应数据的指针，指向.MYD文件的数据。
索引的几点使用经验
经常被查询的字段；经常作为条件查询的字段；经常用于外键连接或普通的连表查询时进行相等比较字段；不为null的字段；如果是多条件查询，最好创建联合索引，因为联合索引只有一个索引文件。
经常被更新的字段、不经常被查询的字段、存在相同功能的字段
只要字段值还可以继续拆分，就不满足第一范式。
范式设计得越详细，对某些实际操作可能会更好，但并非都有好处，需要对项目的实际情况进行设定。
在满足第一范式的前提下，其他列都必须完全依赖于主键列。 如果出现不完全依赖，只可能发生在联合主键的情况下：
实际上，在这张订单表中，product_name 只依赖于 product_id ，customer_name 只依赖于 customer_id。也就是说，product_name 和 customer_id 是没用关系的，customer_name 和 product_id 也是没有关系的。
这就不满足第二范式：其他列都必须完全依赖于主键列！
拆分之后，myorder 表中的 product_id 和 customer_id 完全依赖于 order_id 主键，而 product 和 customer 表中的其他字段又完全依赖于主键。满足了第二范式的设计！
在满足第二范式的前提下，除了主键列之外，其他列之间不能有传递依赖关系。
表中的 customer_phone 有可能依赖于 order_id 、 customer_id 两列，也就不满足了第三范式的设计：其他列之间不能有传递依赖关系。
修改后就不存在其他列之间的传递依赖关系，其他列都只依赖于主键列，满足了第三范式的设计！
查询每门课的平均成绩。
查询 score 表中至少有 2 名学生选修，并以 3 开头的课程的平均分数。
分析表发现，至少有 2 名学生选修的课程是 3-105 、3-245 、6-166 ，以 3 开头的课程是 3-105 、3-245。也就是说，我们要查询所有 3-105 和 3-245 的 degree 平均分。
查询所有学生的 name，以及该学生在 score 表中对应的 c_no 和 degree 。
通过分析可以发现，只要把 score 表中的 s_no 字段值替换成 student 表中对应的 name 字段值就可以了，如何做呢？
查询所有学生的 no 、课程名称 ( course 表中的 name ) 和成绩 ( score 表中的 degree ) 列。
只有 score 关联学生的 no ，因此只要查询 score 表，就能找出所有和学生相关的 no 和 degree ：
然后查询 course 表：
只要把 score 表中的 c_no 替换成 course 表中对应的 name 字段值就可以了。
查询所有学生的 name 、课程名 ( course 表中的 name ) 和 degree 。
只有 score 表中关联学生的学号和课堂号，我们只要围绕着 score 这张表查询就好了。
只要把 s_no 和 c_no 替换成 student 和 srouse 表中对应的 name 字段值就好了。
首先把 s_no 替换成 student 表中的 name 字段：
再把 c_no 替换成 course 表中的 name 字段：
查询 95031 班学生每门课程的平均成绩。
在 score 表中根据 student 表的学生编号筛选出学生的课堂号和成绩：
这时只要将 c_no 分组一下就能得出 95031 班学生每门课的平均成绩：
查询在 3-105 课程中，所有成绩高于 109 号同学的记录。
首先筛选出课堂号为 3-105 ，在找出所有成绩高于 109 号同学的的行。
查询所有成绩高于 109 号同学的 3-105 课程成绩记录。
查询所有和 101 、108 号学生同年出生的 no 、name 、birthday 列。
查询 '张旭' 教师任课的学生成绩表。
首先找到教师编号：
通过 sourse 表找到该教师课程号：
通过筛选出的课程号查询成绩表：
查询某选修课程多于5个同学的教师姓名。
首先在 teacher 表中，根据 no 字段来判断该教师的同一门课程是否有至少5名学员选修：
查看和教师编号有有关的表的信息：
我们已经找到和教师编号有关的字段就在 course 表中，但是还无法知道哪门课程至少有5名学生选修，所以还需要根据 score 表来查询：
根据筛选出来的课程号，找出在某课程中，拥有至少5名学员的教师编号：
在 teacher 表中，根据筛选出来的教师编号找到教师姓名：
查询 “计算机系” 课程的成绩表。
思路是，先找出 course 表中所有 计算机系 课程的编号，然后根据这个编号查询 score 表。
查询 计算机系 与 电子工程系 中的不同职称的教师。
查询课程 3-105 且成绩 至少 高于 3-245 的 score 表。
查询课程 3-105 且成绩高于 3-245 的 score 表。
查询某课程成绩比该课程平均成绩低的 score 表。
查询所有任课 ( 在 course 表里有课程 ) 教师的 name 和 department 。
查询 student 表中至少有 2 名男生的 class 。
查询 student 表中不姓 "王" 的同学记录。
查询 student 表中每个学生的姓名和年龄。
查询 student 表中最大和最小的 birthday 值。
以 class 和 birthday 从大到小的顺序查询 student 表。
查询 "男" 教师及其所上的课程。
查询最高分同学的 score 表。
查询和 "李军" 同性别的所有同学 name 。
查询和 "李军" 同性别且同班的同学 name 。
查询所有选修 "计算机导论" 课程的 "男" 同学成绩表。
需要的 "计算机导论" 和性别为 "男" 的编号可以在 course 和 student 表中找到。
建立一个 grade 表代表学生的成绩等级，并插入数据：
查询所有学生的 s_no 、c_no 和 grade 列。
思路是，使用区间 ( BETWEEN ) 查询，判断学生的成绩 ( degree ) 在 grade 表的 low 和 upp 之间。
准备用于测试连接查询的数据：
分析两张表发现，person 表并没有为 cardId 字段设置一个在 card 表中对应的 id 外键。如果设置了的话，person 中 cardId 字段值为 6 的行就插不进去，因为该 cardId 值在 card 表中并没有。
要查询这两张表中有关系的数据，可以使用 INNER JOIN ( 内连接 ) 将它们连接在一起。
完整显示左边的表 ( person ) ，右边的表如果符合条件就显示，不符合则补 NULL 。
完整显示右边的表 ( card ) ，左边的表如果符合条件就显示，不符合则补 NULL 。
完整显示两张表的全部数据。
在 MySQL 中，事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性 。
比如我们的银行转账：
在实际项目中，假设只有一条 SQL 语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。
因此，在执行多条有关联 SQL 语句时， 事务 可能会要求这些 SQL 语句要么同时执行成功，要么就都执行失败。
在 MySQL 中，事务的 自动提交 状态默认是开启的。
自动提交的作用 ：当我们执行一条 SQL 语句的时候，其产生的效果就会立即体现出来，且不能 回滚 。
什么是回滚？举个例子：
可以看到，在执行插入语句后数据立刻生效，原因是 MySQL 中的事务自动将它 提交 到了数据库中。那么所谓 回滚 的意思就是，撤销执行过的所有 SQL 语句，使其回滚到 最后一次提交 数据时的状态。
在 MySQL 中使用 ROLLBACK 执行回滚：
由于所有执行过的 SQL 语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？
将自动提交关闭后，测试数据回滚：
那如何将虚拟的数据真正提交到数据库中？使用 COMMIT :
事务的实际应用 ，让我们再回到银行转账项目：
这时假设在转账时发生了意外，就可以使用 ROLLBACK 回滚到最后一次提交的状态：
这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT 。
事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：
仍然使用 COMMIT 提交数据，提交后无法再发生本次事务的回滚。
事务的四大特征：
事务的隔离性可分为四种 ( 性能从低到高 ) ：
查看当前数据库的默认隔离级别：
修改隔离级别：
测试 READ UNCOMMITTED ( 读取未提交 ) 的隔离性：
由于小明的转账是在新开启的事务上进行操作的，而该操作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK 命令，会发生什么？
这就是所谓的 脏读 ，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。
把隔离级别设置为 READ COMMITTED ：
这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据，例如：
但是这样还有问题，那就是假设一个事务在操作数据时，其他事务干扰了这个事务的数据。例如：
虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是 在读取同一个表的数据时，可能会发生前后不一致的情况。* 这被称为* 不可重复读现象 ( READ COMMITTED ) 。
将隔离级别设置为 REPEATABLE READ ( 可被重复读取 ) :
测试 REPEATABLE READ ，假设在两个不同的连接上分别执行 START TRANSACTION :
当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有操作事务的连接。相当于开辟出一条单独的线程。
无论小张是否执行过 COMMIT ，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：
这是 因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) * ，那么* 在他的这条新事务的线上，跟其他事务是没有联系的 ，也就是说，此时如果其他事务正在操作数据，它是不知道的。
然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？
报错了，操作被告知已存在主键为 6 的字段。这种现象也被称为 幻读，一个事务提交的数据，不能被其他事务读取到 。
顾名思义，就是所有事务的 写入操作 全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE :
还是拿小张和小王来举例：
此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照 固定顺序执行 ，执行完一个事务后再继续执行下一个事务的 写入操作 ( 这意味着队列中同时只能执行一个事务的写入操作 ) 。
根据这个解释，小王在插入数据时，会出现等待状态，直到小张执行 COMMIT 结束它所处的事务，或者出现等待超时。
转载：
当MySQL表字段设置 unique key 或者 primary key 时，被约束的字段就必须是唯一的。新插入数据直接使用 insert into ，如果出现唯一性冲突，就会抛出异常。我们应该根据需求选择合适的插入语句。
为了演示，我们先新建一张user表，SQL语句如下:
当插入数据时，如果唯一性校验出现重复问题，则报错；
如果没有重复性问题，则执行插入操作。
简单总结：重复则直接报错，sql 语句不执行，不重复则插入。
示例
执行结果
当插入数据时，如果唯一性校验出现重复问题，则忽略错误，只以警告形式返回，不执行此SQL语句；
如果没有重复性问题，则执行插入操作。
简单总结：重复则忽略，sql 语句不执行，不重复则插入。
示例
执行结果
当插入数据时，如果唯一性校验出现重复问题，则在原有记录基础上，更新指定字段内容，其它字段内容保留；
如果没有重复性问题，则执行插入操作。
简单总结：重复则更新指定字段，不重复则插入。
示例
执行结果
表记录， mobile_phone_number 从 '13800000077' 更新为 '13800000088' 了， update_time 也从 NULL 更新为有值了，但是 id 没有变:
replace into表示插入替换数据，当插入数据时，如果唯一性校验出现重复问题，删除旧记录，插入新记录；
如果没有重复性问题，则执行插入操作，效果和insert into是一样的。
简单总结：重复则先删除再插入新记录，不重复则插入
。
示例
执行结果
表记录， id 和 mobile_phone_number 变了， update_time 变为了字段默认值 NULL :
replace into 执行的逻辑:
示例一
示例一 insert into ... on deplicate key update 操作在 binlog 中记录为：
示例二
示例二 replace into 操作在binlog中记录为：
从示例可以看出，使用 replace into 会有以下问题:
执行结果
因为全部列都是指定的值，所以，相当于所有字段全部更新了一次。
binlog 中的记录:
如果出现重复异常，希望捕获异常，则使用 insert into ;
如果出现重复异常，希望保存旧纪录，忽略新纪录，则使用 insert ignore into ;
如果出现重复异常，希望更新指定字段，则使用 insert into … on duplicate key update ;
如果出现重复异常，希望删除旧记录，插入新记录，则使用 replace into 。
bigdecimal(p,d)：p表示多少位数，d表示有多少位表示小数
与钱相关，比如工资使用BigDecimal，不用使用float、double避免计算时的精度丢失
参考：
float、double在存储为二进制时会出现精度丢失，导致进行二进制计算时出现不数据不准确
varchar记录的是字符的长度
使用char，由于时固定长度，在数据检索时，磁盘IO的次数要比varchar少(每个数据段需要当前数据段的长度和结束)
所以，在长度变化不大的情况下，使用char。
当varchar大于5000，使用text代替，并且另建一张表，避免影响其它字端的检索效率
参考：
对于有主键或者唯一键冲突的情况下，replace会使用delete+insert执行。但是在row模式下，binlog记录的是update
因此有这么一种情况：在自增主键并且binlog是row模式，当发生唯一性冲突时，主从库的自增列会产生不一致，导致主从切换时，在新主库新增数据会出现主键冲突（自增列是小于最大id值的）
先来看下面一句sql
上面这一段sql存在的问题：
虽让fr_id有索引，查询时可以用到fr_id索引，但是由于查询了所有字段会导致回表，并且随机读严重，扫面更多的页，最终会使整体sql的执行性能不佳
如何优化呢？
使用延迟关联：第一步先利用覆盖索引查询id，再做关联查询
如何进一步优化？
根据业务场景，如果不需要支持跳页(即只支持翻页，解决深度分页问题)，可以考虑用如下进行优化
第一次查询
第二次查询
假设第一次查询的结果的最大fr_id为200，那么第二次查询的如下
使用翻页要考虑的问题时，字段一定要是单调自增的，不然在翻页的过程中会有漏数据
所以整体优化思路为(两种方案二选一)：
1、使用延迟关联，解决两个问题（1.使用覆盖索引 2.减少回表次数、避免随机读，提高性能）
2、根据业务场景，是否需要支持跳页查询？
Mysql在创建表的时候有如下限制：
1、如果单个字段大小大于65535byte，自动转化成text
2、单行大小不能大于65535byte，否则创建失败，不包括text、blob字段
同时在插入数据有如下限制：
限制单行的大小不能大于单行的字段个数*768byte，否则会出现行裂变（768的含义是：mysql会对存储大字段进行优化，对每个字段的前768byte存储在当前页，其余存储在溢出页中，保证一个数据页至少能存储两行数据）
