文章详细阐述了数据库中的存储引擎，如InnoDB和MyISAM的特点，以及它们在事务处理、锁机制上的差异。同时，讨论了索引的作用、类型，包括B+Tree、Hash索引，以及如何选择和优化索引。此外，还提到了事务的ACID特性、并发问题和隔离级别。文章最后提及了SQL查询优化，如使用索引、避免全表扫描等策略。
多表关系
一对多：在多的一方设置外键，关联一的一方的主键
多对多：建立中间表，中间表包含两个外键，关联两张表的主键
一对一：用于表结构的拆分，在其中任何一方设置外键(unique)，关联另一方的主键
多表查询
笛卡尔积的筛选
内连接
交集
隐式内连接
select 字段 from 表1, 表2 where 条件
显式内连接
select 字段 from 表1, [inner] join 表2 on 条件
外连接
将A表的相关数据按条件追加到B表上, B表数据全部显示
左外连接
查询表1（左表）的所有数据，包含 表1和表2交集部分的数据
select 字段 from 表1 left [outer] join 表2 on 条件
右外连接
查询表2（右表）的所有数据，包含 表1和表2交集部分的数据
select 字段 from 表1 left [outer] join 表2 on 条件
自连接
自连接查询，可以是内连接查询，也可以是外连接查询
select 字段 from 表1 join 表2 on 条件
联合查询 union, union all
对于union查询，就是把多次查询的结果合并起来，形成一个新的查询结果
select 字段列表1 from 表1 ...
union [alll]
select 字段列表2 from 表2 ...
字段列表1和字段列表2的 列数、类型应保持一致
union 和 union all 都是将两个结果集合并
注意：union去重且排序，union all 不去重不排序
子查询
sql 套 sql 称嵌套查询，子查询
select * from t1 where col1 = (select col from t2)
子查询外部语句可以是 insert / update / delete / select 任何一个
根据子查询结果不同，分为
| 子查询 | 结果 | 操作符 |
|---|---|---|
| 标量子查询 | 子查询结果为单个值 | =, >, <, >=, <= |
| 列子查询 | 子查询结果为一列 | in, not int, any, some, all |
| 行子查询 | 子查询结果为一行 | =, <>, in, not in |
| 表子查询 | 子查询结果为多行多列 | in |
事务
事务是一组操作集合，是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败
默认MySQL的事务是自动提交
事务操作
查看/设置事务提交方式
select @@autocommit;
set @@autocommit = 0;
# 1 自动提交(默认)
# 0 手动提交
提交事务
commit;
回滚事务
rollback;
开启事务
start transaction 或 begin
事务四大特性
| 事务 | ||
|---|---|---|
| 原子性 | Atomicity | 事务是不可分割的最小操作单元，要么全部成功，要么全部失败 |
| 一致性 | Consistency | 事务完成时，必须使所有的数据都保持一致状态 |
| 隔离性 | Isolation | 数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境中运行 |
| 持久性 | Durability | 事务一旦提交或回滚，它对数据库中的数据的改变是永久的 |
并发事务问题
| 问题 | 描述 |
|---|---|
| 脏读 | 一个事务读到另一个事务还没有提交的数据 |
| 不可重复读 | 一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读 |
| 幻读 | 一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了幻影（在解决不可重复读之后出现的问题） |
事务隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| Read uncommitted | √ | √ | √ |
| Read committed–Sql Server , Oracle | x | √ | √ |
| Repeatable–MySQL | x | x | √ |
| Serializable | x | x | x |
--查看事务隔离级别
select @@transaction_isolation
--设置事务隔离级别
set [session|global] transaction isolation level [read uncommitted| read committed| repeatable| serializable]
存储引擎
MySQL体系结构
存储引擎简介
存储引擎就是存储数据，建立索引，更新/查询数据等技术的实现方式。存储引擎是基于表的，而不是基于库的，所以存储引擎也可被称为表类型。
1，在创建表时，指定存储引擎
create table 表名(
字段 字段类型 [comment 注释]
...
) engin=innoDB [comment 注释]
2，查看当前数据库支持的存储引擎
show engines;
存储引擎特点
InnoDB
InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MySQL5.5之后，InnoDB是默认的MySQL存储引擎。
特点：
DML操作遵循ACID模型，支持事务
行级锁，提高并发访问性能；
支持外键 foreign key约束，保证数据完整性和正确性
文件：
xxx.ibd: xxx代表表名，InnoDB引擎的每张表都会对应这样一个表空间文件，存储该表的表结构（frm,sdi），数据和索引。
参数： innodb_file_per_table
InnoDB逻辑存储结构
MyISAM
MyISAM是MySQL早期的默认存储引擎
特点：
不支持事务，不支持外键
支持表锁，不支持行锁
访问速度快
文件：
xxx.sdi : 存储表结构信息
xxx.MYD : 存储数据
xxx.MYI : 存储索引
Memory
Memory引擎的表数据是存储在内存中的，由于受到硬件问题，或断电问题的影响，只能将这些表作为临时表或缓存使用。
特点：
内存存放
hash索引（默认）
文件：
xxx.sdi : 存储表结构信息
区别及特点
| 特点 | InnoDB | MyISAM | Memory |
|---|---|---|---|
| 存储限制 | 64TB | 有 | 有 |
| 事务安全 | 支持 | - | - |
| 锁机制 | 行锁 | 表锁 | 表锁 |
| B+tree索引 | 支持 | 支持 | 支持 |
| Hash索引 | - | - | 支持 |
| 全文索引 | 支持(5.6+) | 支持 | - |
| 空间使用 | 高 | 低 | N/A |
| 内存使用 | 高 | 低 | 中等 |
| 批量插入速度 | 低 | 高 | 高 |
| 支持外键 | 支持 | - | - |
面试题
InnoDB引擎与MyISAM引擎的区别 ?
①. InnoDB引擎, 支持事务, 而MyISAM不支持。
②. InnoDB引擎, 支持行锁和表锁, 而MyISAM仅支持表锁, 不支持行锁。
③. InnoDB引擎, 支持外键, 而MyISAM是不支持的。
主要是上述三点区别，当然也可以从索引结构、存储限制等方面，更加深入的回答
具体参考如下官方文档：
https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.html
https://dev.mysql.com/doc/refman/8.0/en/myisam-storage-engine.html
存储引擎选择
在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统，还可以根据实际情况选择多种存储引擎进行组合。
InnoDB：是MySQL的默认存储引擎，支持事务外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多的更新，删除操作，那么InnoDB存储引擎比较合适的选择
MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性，并发性要求不是很高，那么选择这个存储引擎是非常合适的。
Memory：将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。Memory的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。
索引
概述
索引（index）是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。
特点
| 优势 | 劣势 |
|---|---|
| 提高数据检索的效率，降低数据库的IO成本 | 索引列也要占用空间 |
| 通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗 | 索引大大提高了查询效率，同时也降低了更新表的速度，如对表进行insert，update，delete时，效率降低。 |
索引结构
MySQL的索引时在存储引擎层实现的，不同的存储引擎有不同的索引结构，主要包含了以下几种：
| 索引结构 | 描述 |
|---|---|
| B+Tree索引 | 最常见的索引类型，大部分引擎都支持B+树索引 |
| Hash索引 | 底层数据结构是用哈希表实现的，只有精确匹配索引列的查询才有效，不支持范围查询 |
| R-tree（空间索引） | 空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少 |
| Ful-text（全文索引） | 是一种通过建立倒排索引，快速匹配文档的方式。类似于Lucene,Solr,ES |
存储引擎对索引结构的支持
| 索引 | InnoDB | MyISAM | Memory |
|---|---|---|---|
| B+tree索引 | 支持 | 支持 | 支持 |
| Hash索引 | 不支持 | 不支持 | 支持 |
| R-tree索引 | 不支持 | 支持 | 不支持 |
| Full-text | 5.6+ | 支持 | 不支持 |
B+tree
MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能，利于排序。
Hash
哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中。
2). 特点
A. Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，…）
B. 无法利用索引完成排序操作
C. 查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引
3). 存储引擎支持
在MySQL中，支持hash索引的是Memory存储引擎。 而InnoDB中具有自适应hash功能，hash索引是InnoDB存储引擎根据B+Tree索引在指定条件下自动构建的。
思考题
为什么InnoDB存储引擎选择使用B+tree索引结构?
A. 相对于二叉树，层级更少，搜索效率高；
B. 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；
C. 相对Hash索引，B+tree支持范围匹配及排序操作；
索引分类
在MySQL数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引
| 分类 | 含义 | 特点 | 关键字 |
|---|---|---|---|
| 主键索引 | 针对于表中主键创建的索引 | 默认自动创建，只能有一个 | primary |
| 唯一索引 | 避免同一个表中某数据列中的值重复 | 可以有多个 | unique |
| 常规索引 | 快速定位特定数据 | 可以有多个 | |
| 全文索引 | 全文索引查找的是文本中的关键词，而不是比较索引中的值 | 可以有多个 | fulltext |
而在在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：
| 分类 | 含义 | 特点 |
|---|---|---|
| 聚集索引(clustered index) | 将数据存储与索引放到了一块，索引结构的叶子结点保存了行数据 | 必须有，且只有一个 |
| 二级索引(secondary index) | 将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键 | 可以存在多个 |
聚集索引选取规则
- 如果存在主键，主机索引就是聚集索引。
- 如果不存在主键，将使用第一个唯一索引作为聚集索引。
- 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引
回表查询：先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取数据的方式，称之为回表查询。
思考题：
以下两条SQL语句，那个执行效率高? 为什么?
A. select * from user where id = 10 ;
B. select * from user where name = 'Arm' ;
备注: id为主键，name字段创建的有索引；
解答：
A 语句的执行性能要高于B 语句。
因为A语句直接走聚集索引，直接返回数据。 而B语句需要先查询name字段的二级索引，然
后再查询聚集索引，也就是需要进行回表查询。
思考题：
InnoDB主键索引的B+tree高度为多高呢?
假设:
一行数据大小为1k，一页中可以存储16行这样的数据,一个内存块/页大小为16*1k。InnoDB的指针占用6个字节的空
间，主键即使为bigint，占用字节数为8。
高度为2：
n * 8 + (n + 1) * 6 = 16*1024 , 算出n约为 1170
1171* 16 = 18736
也就是说，如果树的高度为2，则可以存储 18000 多条记录。
高度为3：
1171 * 1171 * 16 = 21939856
也就是说，如果树的高度为3，则可以存储 2200w 左右的记录。
索引语法
- 创建索引
creat [unique|fulltext] index index_name on table_name(index_clo_name,...);
- 查看索引
show index from table_name;
- 删除索引
drop index index_name on table_name;
SQL性能分析
SQL执行频率
MySQL 客户端连接成功后，通过 show [session|global] status 命令可以提供服务器状态信
息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次：
-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
SHOW GLOBAL STATUS LIKE 'Com_______';
通过上述指令，我们可以看到当前数据库到底是以查询为主，还是以增删改为主，从而为数据库优化提供参考依据，
如果是以增删改为主，我们可以考虑不对其进行索引的优化。
如果是以查询为主，那么就要考虑对数据库的索引进行优化了。
慢查询日志
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10s）的所有SQL语句的日志。
# 查看系统变量
show variables like='show_query_log' # on/off
# 如果要开启慢查询日志，在MySQL配置文件(/etc/my.cnf)中配置如下信息：
# 开启MySQL慢日志查询开关
slow_query_log=1
# 设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志
long_query_time=2
# 重启服务
systemctl restart mysqld
# 日志文件位置/var/lib/mysql/localhost-slow.log。
profile详情
show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了，通过hang_profiling参数，能够查看当前MySQL是否支持profile操作：
select @@have_profiling;
# yes
# 开启profiling
set profiling = 1
-- 查看每一条SQL的耗时基本情况
show profiles;
-- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
-- 查看指定query_id的SQL语句CPU的使用情况
-- 指定SQL各个阶段的耗时情况
show profile cpu for query query_id;
explain
explain或desc命令获取MySQL如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序。
-- 直接在select语句之前加上关键字 explain/desc
explain select 字段 from 表名 where 条件;
| 字段 | 含义 |
|---|---|
| id | select查询的序列号，表示查询中执行select字句或者是操作表的顺序（id相同，执行顺序从上到下；id不同，值越大，越先执行） |
| select_type | 表示select的类型，常见的取值有simple（简单表，即不使用表连接或者子查询），primary（主查询，即外层的查询），union（union中的第二个或者后面的查询语句），subquery（select/where之后包含了子查询）等 |
| type | 表示连接类型，性能由好到差的连接类型为null，system，const，eq_ref，ref，range，index，all |
| possible_key | 显示可能应用在这张表上的索引，一个或多个 |
| key | 实际使用的索引，如果为null，则没有使用索引 |
| key_len | 表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好。 |
| rows | MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估值，可能并不总是准确的 |
| filtered | 表示返回结果的行数占读取行数的百分比，filtered的值越大越好 |
索引使用
最左前缀法则
如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列，如果跳跃某一列，索引将会部分失效（后面的字段索引失效）。
思考题：
当执行SQL语句: explain select * from tb_user where age = 31 and status = ‘0’ and profession = ‘软件工程’； 时，是否满足最左前缀法则，走不走上述的联合索引，索引长度？
答，是完全满足最左前缀法则的，索引长度54，联合索引是生效的。
注意 ： 最左前缀法则中指的最左边的列，是指在查询时，联合索引的最左边的字段(即是第一个字段)必须存在，与我们编写SQL时，条件编写的先后顺序无关。
范围查询
联合索引中，出现范围查询（>,<），范围查询右侧的列索引失效
explain select * from tb_user where profession = ‘软件工程’ and age > 30 and status
= ‘0’;
但是，当范围查询使用>= 或 <= 时，走联合索引，所以，在业务允许的情况下，尽可能的使用类似>=, <=这类范围查询，避免使用 > 或 < 。
联合索引中，出现范围查询（>,<）范围查询右侧的列索引失效。而（>=，=<）不会失效。
可通过explain 查看key_len验证。
索引失效情况
索引列运算
不要再索引列上进行运算操作，索引将失效
explain select * from tb_user where substring(phone, 10,2)='15'
# 全盘扫描，没有进行索引优化
字符串不加引号
字符串类型字段使用时，不加引号，索引将失效。
因为数据库存在隐式类型转换，索引将失效。
模糊查询
如果仅仅是尾部模糊匹配，索引不会失效 '软件%'
如果是头部模糊匹配，索引失效 '%工程' , '%工%'
or连接
or分割开的条件，如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到
数据分布影响
如果MySQL评估使用索引比全表更慢，则不使用索引。
经过测试我们发现，相同的SQL语句，只是传入的字段值不同，最终的执行计划也完全不一样，这是为
什么呢？
就是因为MySQL在查询时，会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃
索引，走全表扫描。 因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不
如走全表扫描来的快，此时索引就会失效。
因此，is null 、is not null是否走索引，得具体情况具体
分析，并不是固定的。
SQL提示
自己来指定使用哪个索引
1). use index ： 建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进行评估）。
explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';
2). ignore index ： 忽略指定的索引。
explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';
3). force index ： 强制使用索引。
explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';
覆盖索引
覆盖索引是指 查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到 ，不需要回表查询
思考题：
一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案:
select id,username,password from tb_user where username =‘itcast’;
答案: 针对于 username, password建立联合索引, sql为:
create index idx_user_name_pass on tb_user(username,password);
这样可以避免上述的SQL语句，在查询的过程中，出现回表查询。
前缀索引
当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让
索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。
1，语法
create index idx_xxxx on table_name(column(n)) ;
2，前缀长度
不重复的索引值（基数）和数据表的记录总数的比值，越高越好，唯一索引为1，
select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ;
单列索引与联合索引
单列索引：一个索引只包含单个列
联合索引：一个索引包含了多个列
当有多个查询条件时，即使每个条件都有索引，最终也只会选择一个索引去查询，会出现回表查询的情况，所以在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单列索引。
索引设计原则
1，针对于数据量较大，且查询比较频繁的表建立索引
2，针对于常作为查询条件（where）,排序（order by），分组（group by）操作的字段建立索引。
3，尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。4，如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
5，尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
6，要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构代价越大，会影响增删改的效率。
7，如果索引列不能存储NULL值，请在建表时使用NOT NULL约束它，当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。
SQL优化
插入数据
insert
1，批量插入数据
2，手动控制事务，插入前开启，插入全部完成后提交
3，按照主键顺序插入
大批量插入数据
使用MySQL提供的load指令进行插入
-- 客户端连接服务端时，加上参数 -–local-infile
mysql –-local-infile -u root -p
-- 设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;
-- 执行load指令将准备好的数据，加载到表结构中
load data local infile '/root/sql1.log' into table tb_user fields terminated by ',' lines terminated by '\n' ;
主键优化
数据组织方式
在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表成为索引组织表（index organized table IOT）
行数据，都是存储在聚集索引的叶子节点上的。
InnoDB的逻辑结构图：
在InnoDB引擎中，数据行是记录在逻辑结构page页中的，而每一个页的大小是固定的，默认16k，也就意味着，一个页中所存储的行也是有限的，如果插入的数据行row在该页存储不下，将会存储到下一个页中，页与页之间会通过指针连接。
页分裂
页可以为空，也可以填充一半，也可以填充100%，每个页包含了2-N行数据（如果一行数据过大，会行溢出），根据主键排列。
顺序插入 vs 乱序插入
A. 主键顺序插入效果
①. 从磁盘中申请页，主键顺序插入
②. 第一个页没有满，继续往第一页插入
③. 当第一个也写满之后，再写入第二个页，页与页之间会通过指针连接
④. 当第二页写满了，再往第三页写入
B. 主键乱序插入效果
①. 加入1#,2#页都已经写满了，存放了如图所示的数据
②. 此时再插入id为50的记录，我们来看看会发生什么现象
会再次开启一个页，写入新的页中吗？
不会。因为，索引结构的叶子节点是有顺序的。按照顺序，应该存储在47之后。
但是47所在的1#页，已经写满了，存储不了50对应的数据了。 那么此时会开辟一个新的页 3#。
但是并不会直接将50存入3#页，而是会将1#页后一半的数据，移动到3#页，然后在3#页，插入50。
移动数据，并插入id为50的数据之后，那么此时，这三个页之间的数据顺序是有问题的。 1#的下一个页，应该是3#， 3#的下一个页是2#。 所以，此时，需要重新设置链表指针。
上述的这种现象，称之为 “页分裂”，是比较耗费性能的操作。
页合并
目前表中已有数据的索引结构(叶子节点)如下：
当我们对已有数据进行删除时，具体的效果如下:
当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。
当我们继续删除2#的数据记录
当页中删除的记录达到 MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用。
删除数据，并将页合并之后，再次插入新的数据21，则直接插入3#页
这个里面所发生的合并页的这个现象，就称之为 “页合并”。
MERGE_THRESHOLD：合并页的阈值，可以自己设置，在创建表或者创建索引时指定。
索引设计原则
1.满足业务需求的情况下，尽量降低主键的长度。
2.插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键。
3.尽量不要使用UUID做主键或者是其他自然主键，如身份证号。
4.业务操作时，避免对主键的修改。
order by 优化
MySQL的排序，有两种方式：
Using filesort : 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort
buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。
Using index : 通过有序索引顺序扫描直接返回有序数据，这种情况即为 using index，不需要
额外排序，操作效率高。
对于以上的两种排序方式，Using index的性能高，而Using filesort的性能低，我们在优化排序
操作时，尽量要优化为 Using index。
order by优化原则:
A. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。
B. 尽量使用覆盖索引。
C. 多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）。
D. 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小
sort_buffer_size(默认256k)。
group by 优化
A. 在分组操作时，可以通过索引来提高效率。
B. 分组操作时，索引的使用也是满足最左前缀法则的。
limit 优化
在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。
优化思路: 一般分页查询时，通过创建 覆盖索引 能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。
explain select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) a where t.id = a.id;
count优化
如果数据量很大，在执行count操作时，是非常耗时的。
- MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个 数，效率很高； 但是如果是带条件的count，MyISAM也慢。
- InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出 来，然后累积计数。
如果说要大幅度提升InnoDB表的count效率，主要的优化思路：自己计数(可以借助于redis这样|的数据库进行,但是如果是带条件的count又比较麻烦了)。
| count用法 | 含义 |
|---|---|
| count(主键) | InnoDB 引擎会遍历整张表，把每一行的 主键id 值都取出来，返回给服务层。服务层拿到主键后，直接按行进行累加(主键不可能为null) |
| count(字段) | 没有not null 约束 : InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，服务层判断是否为null，不为null，计数累加。 有not null 约束：InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，直接按行进行累加。 |
| count(数字) | InnoDB 引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字“1”进去，直接按行进行累加。 |
| count(*) | InnoDB引擎并不会把全部字段取出来，而是专门做了优化，不取值，服务层直接按行进行累加。 |
按照效率排序的话，count(字段) < count(主键 id) < count(1) ≈ count()，所以尽量使用 count()。
update优化
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁
升级为表锁 。
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
