mysql查询优化
一、基础概念
1、数据库3大范式
第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
例子：考虑这样一个表：【联系人】（姓名，性别，电话），如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF，我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。
第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
例子：考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName
只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。
第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖 于非主键列 B，非主键列 B 依赖于主键的情况。
例子：考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity
等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到3NF。
二、查询优化
1、数据库设计
A、适当反范式。
- Eg: 用户订单表，冗余用户名称，此处违反第三范式，用户名称直接依赖用户uid，传递依赖orderId。
B、适当建立索引
-
较频繁的查询且选择性高的条件、表关联的字段应该创建索引;
-
WHERE、Order by 、Group by 、Distinct 最好在这些列上建立索引，利于索引排序与查询。
-
更新非常频繁、选择性太低的字段不适合创建索引;
-
MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及前缀完全匹配的LIKE。
-
优先使用联合索引，注意索引的最左匹配原则。
-
!=，<>、 where 子句中对字段进行表达式或函数操作，这将导致mysql放弃使用索引。
2、优化工具
-
慢日志
-
Explain 执行计划
三、业务场景
1、大数据量分页查询的解决方案：
子查询(id递增，可以不连续)、id限定(id连续递增)、临时表
https://blog.csdn.net/youanyyou/article/details/95558514
END
如有错漏，望赐教！！！
