qq_52896771的博客

1.关联查询优化保证被驱动表的JOIN字段已经创建了索引 需要JOIN 的字段，数据类型保持绝对一致。LEFT JOIN 时，选择小表作为驱动表， 大表作为被驱动表 。减少外层循环的次数。INNER JOIN 时，MySQL会自动将 小结果集的表选为驱动表 。选择相信MySQL优化策略。 能够直接多表关联的尽量直接关联，不用子查询。(减少查询的趟数) 不建议使用子查询，建议将子查询SQL拆开结合程序多次查询，或使用 JOIN 来代替子查询。衍生表建不了索引。2.子查询优化MySQL从4.1版本开始支持子查询

1.哪些情况适合创建索引1. 1字段的数值有唯一性的限制业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。（来源：Alibaba） 说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的。1.2 频繁作为 WHERE 查询条件的字段某个字段在SELECT语句的 WHERE 条件中经常被使用到，那么就需要给这个字段创建索引了。尤其是在 数据量大的情况下，创建普通索引就可以大幅提升数据查询的效率。 比如student_info数据表（含100万条数据），假设我

1.1数据并发问题1. 脏写（ Dirty Write ）对于两个事务 Session A、Session B，如果事务Session A 修改了 另一个 未提交 事务Session B 修改过 的数 据，那就意味着发生了 脏写2. 脏读（ Dirty Read ）对于两个事务 Session A、Session B，Session A 读取 了已经被 Session B 更新 但还 没有被提交 的字段。 之后若 Session B 回滚 ，Session A 读取 的内容就是 临时且无效 的。 Sessi

第一范式1NF：表的每个属性必须具有原子（单个）值。第二范式2NF：而 2NF 告诉我们一张表就是一个独立的对象，一张表只 表达一个意思。每个非主键属性依赖于主键，依赖于整个主键”。第三范式3NF：非主键属性之间不能有依赖关系，表中的字段只能依赖于主键，不能和主键之间有间接依赖关系。...

a表b表SELECT a.*,b.* FROM a LEFT JOIN b on a.id = b.id;以a表为基础，b表有的数据就与之对应，没有的数据应null代替结果：SELECT a.*,b.* FROM a RIGHT JOIN b on a.id = b.id;以b表为基础进行右连接查询，结果为b表有的数据全部与a表相对应。...

创建索引：(1)ALTER TABLE table_name ADD INDEX index_name (name) //普通索引(2)ALTER TABLE table_name ADD UNIQUE (name) //联合索引(3)ALTER TABLE table_name ADD PRIMARY KEY (name) //主键索引查

实际开发时，现在越来越多『长、难、复杂』SQL。这种 SQL 语句编写、维护较为困难。所以我们可以将这一的 SQL 语句创建为『视图』，这个视图生成了一张虚拟的表。下次再有需要时，执行这个视图即可得到相同的结果。视图是将一段查询 SQL 封装为一个虚拟的表。这个虚拟表只保存了 SQL 逻辑，不会保存任何查询结果。

具体从 SQL 优化的角度来说，select * 会导致我们加载很多没有创建索引的字段到内存中，增加了数据体积超过 sort_buffer_size 的风险。在实际业务功能开发过程中，禁止在 select 子句中使用 * 号代表全部字段。其实这个时候更要注意的是：是不是真的要查全部字段。所以在整个 SQL 查询语句中，能够将数据过滤掉的条件在不影响查询结果的前提下都要尽早使用，尽早过滤数据，缩小要操作的数据量，让后续操作减轻负担。分析语句：排序方向不一致的情况。分析语句：排序方向一致的情况。

此时需要给 book 表增加较多条记录，让两个表数据量差异明显才有这个效果。看这个分析结果发现：在 class 表上添加的索引起的作用不大。开始是没有加索引的情况。换成inner join（MySQL自动选择驱动表）MySQL 还是选择了 class 作为驱动表。

简单来说就是：MySQL 在决定是否要应用索引时，会对照 SQL 语句中要过滤的字段的顺序和索引中字段的顺序。此时联合索引生效，但是 key_len 字段的值是 5，而不是 68，说明 name 字段并没有按照索引去查询。对 name 字段来说，索引没有生效。其实原本是不应该生效的，但是此时是 MySQL 的 SQL 优化器调整了解析树，使查询字段符合了索引顺序，这才让索引生效了。在索引中，age 字段在最左边，现在查询的 deptId 作为第一个查询的字段不是 age，这就违背了最左原则。

一条 SQL 语句总体来看：其中可能会包含很多个 select 关键字。每一个 select 代表整个 SQL 语句执行计划中的一次小的查询，而每一个 select 关键字的每一次查询都有可能是不同类型的查询。select_type 字段就是用来描述每一个 select 关键字的查询类型，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色。

这个机制也比较好理解，比如说，一个数据表存储的是一篇篇的文章，文章中的常见词、语气词等等，出现的肯定比较多，搜索这些词语就没什么意义了，需要搜索的是那些文章中有特殊意义的词，这样才能把文章区分开。我们根据这个以非聚簇索引的索引列大小排序的 B+ 树只能确定我们要查找记录的主键值，所以如果我们想根据非聚簇索引的索引列的值查找到完整的用户记录的话，仍然需要回到聚簇索引中再查一遍，这个过程称为。例如，在表t_student的字段name中创建唯一性索引，那么字段name的值就必须是唯一的。

索引类型索引特点单列索引即一个索引是只根据一个字段创建的，里面只包含单个列， 一个表可以有多个单值索引（也叫单列索引）联合索引即一个索引包含多个列（也叫多值索引、多列索引）唯一索引索引列的值必须唯一，但允许有空值，空值可以有多个主键索引设定为主键后数据库会自动建立索引，InnoDB 为聚簇索引主键字段和这个字段中具体的值主键约束主键索引。

MySQL 从 5.5 版本之后，就开始默认采用 InnoDB 引擎。InnoDB 是 MySQL 的默认事务型引擎。InnoDB 被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。如果除了增加和查询外，还需要更新和删除操作，那么应优先选择 InnoDB 存储引擎。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑 InnoDB 引擎。

存储引擎层，存储引擎真正的负责了 MySQL 中数据的存储和提取，服务器通过 API 与存储引擎进行通信。MySQL 首先根据语法规则验证 SQL 语句的语法正确性，然后通过关键字将 SQL 语句进行解析，并生成一棵对应的『解析树』。主要体现在存储引擎的架构上，『插件式』的『存储引擎架构』将查询和其它的系统任务以及数据的存储提取相分离。优化器的作用就是找到这其中最好的执行计划。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化：如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。