MySQL 性能优化
1. 灵魂拷问
- MySQL的索引在执行过程中是如何被使用的？
- MySQL的表数据和索引在底层是如何被使用的？
- 索引覆盖是什么？索引覆盖如何优化检索性能
- 组合索引和单列所有哪个更好？
- 聚集索引和非聚集索引存储方式有什么不同
- B+ Tree和B Tree的区别
2.1 MySQL架构
2.1.1 结构图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CsccXQcU-1595768400184)(http://zhaox.github.io/assets/images/MySQL.png)]
第一层负责连接管理、授权认证、安全等
第二层负责解析查询(编译SQL)，并对其进行优化(如调整表的读取顺序，选择合适的索引等)。对于SELECT语句，在解析查询前，服务器会先检查查询缓存，如果能在其中找到对应的查询结果，则无需再进行查询解析、优化等过程，直接返回查询结果。存储过程、触发器、视图等都在这一层实现。
第三层是存储引擎，存储引擎负责在MySQL中存储数据、提取数据、开启一个事务等等
2.1.2Optimizer优化器
语法解析和查询重写之后，MySQL会根据语法树和数据的统计信息对SQL进行优化，包括决定表的读取顺序、选择合适的索引等，最终生成SQL的具体执行步骤
2.1.3 Pluggable Storage Engines存储引擎
| 存储引擎 | 优点 | 缺点 |
|---|---|---|
| InnoDB | 5.5版本后MySQL默认数据库，支持事务，比MyISAM处理速度稍慢 | 非常复杂，性能较一些简单的引擎要差一点儿。空间占用比较多。 |
| MyISAM | 高速引擎，拥有极高的插入，查询速度 | 不支持事务，不支持行锁、崩溃后数据不容易修复 |
| Archive | 将数据压缩后存储，非常适合存储大量的独立的，作为历史记录的数据 | 只能进行插入和查询操作，非事务型 |
| CSV | 是基于CSV格式文件存储数据（应用于跨平台数据交换） | |
| Memory | 内存存储引擎，拥有极高的插入，更新和查询效率 | 占用和数据量成正比的内存空间，只在内存上保存数据，意味着数据可能会丢失，并发能力低下。不支持BLOB或TEXT类型的列 |
| Falcon | 一种新的存储引擎，支持事务处理，传言可能是InnoDB的替代者 |
最常用的是InnoDB和MyISAM，InnoDB和MyISAM存储引擎区别
| 类别 | InnoDB | MyISAM |
|---|---|---|
| 存储文件 | .frm 表定义文件 .idb 数据文件和索引文件 |
.frm 表定义文件 .myd 数据文件 .myi 索引文件 |
| 锁 | 表锁、行锁 | 表锁 |
| 事务 | 支持 | 不支持 |
| CRUD | 读、写 | 读多 |
| count | 扫表 | 专门存储的地方 |
| 索引结构 | B+ Tree | B+ Tree |
2.1.4 MySQL物理文件
1. 日志文件(顺序IO)
MySQL通过日志记录了数据库操作信息和错误信息。常用的日志文件包括错误日志、二进制日志、查询日志、慢查询 日志和事务Redo 日志、中继日志等
错误日志（errorlog）
默认是开启的，而且从5.5.7以后无法关闭错误日志，错误日志记录了运行过程中遇到的所有严重的错误信息,以及MySQL每次启动和关闭的详细信息。二进制日志（bin log）
默认是关闭的。binlog记录了数据库所有的ddl语句和dml语句，但不包括select语句内容，语句以事件的形式保存，描述了数据 的变更顺序，binlog还包括了每个更新语句的执行时间信息。如果是DDL语句，则直接记录到binlog日志，而DML语 句，必须通过事务提交才能记录到binlog日志中。
binlog主要用于实现mysql主从复制、数据备份、数据恢复。通用查询日志（general query log）
默认情况下通用查询日志是关闭的慢查询日志（slow query log）
默认是关闭的。重做日志（redo log）
作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。-
回滚日志（undo log）
保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
-
中继日志（relay log）
是在主从复制环境中产生的日志。主要作用是为了从机可以从中继日志中获取到主机同步过来的SQL语句，然后执行到从机中。
2. 数据文件(随机IO)
- InnoDB数据文件
.frm文件：主要存放与表相关的数据信息,主要包括表结构的定义信息
.ibd：使用独享表空间存储表数据和索引信息，一张表对应一个ibd文件。
ibdata文件：使用共享表空间存储表数据和索引信息，所有表共同使用一个或者多个ibdata文件 - MyIsam数据文件
.frm文件：主要存放与表相关的数据信息,主要包括表结构的定义信息
.myd文件：主要用来存储表数据信息。
.myi文件：主要用来存储表数据文件中任何索引的数据树。
3. 顺序IO和随机IO
- 顺序I/O一般只需扫描一次数据、所以、缓存对它用处不大
- 顺序I/O比随机I/O快
- 随机I/O通常只要查找特定的行、但I/O的粒度是页级的、其中大部分是浪费的，而顺序I/O所读取的数据、通常发生在想要的数据块上的所有行更加符合成本效益
2.1.5 MySQL执行流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-juGC81EP-1595768400190)(https://ask.qcloudimg.com/http-save/yehe-1446357/l7kw2rr47e.jpeg?imageView2/2/w/1620)]
客户端发送一条查询给服务器；
服务器通过权限检查之后,先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果。否则进入下一阶段；
服务器端进行SQL解析、预处理，再由优化器根据该SQL所涉及到的数据表的统计信息进行计算，生成对应的执行计划；
MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询；
将结果返回给客户端。
SQL执行的最大瓶颈在于磁盘的IO，即数据的读取 ；不同SQL的写法，会造成不同的执行计划的执行，而不同的执行计划在IO的上面临完全不一样的数量级，从而造成性能的差距；
所以,我们说,优化SQL,其实就是让查询优化器根据程序猿的计划选择匹配的执行计划,来减少查询中产生的IO;
2.1.6 SQL解析顺序
SELECT DISTINCT
< select_list >
FROM
< left_table > < join_type >
JOIN < right_table > ON < join_condition >
WHERE
< where_condition >
GROUP BY
< group_by_list >
HAVING
< having_condition >
ORDER BY
< order_by_condition >
LIMIT < limit_number >
执行顺序：
FROM
ON
JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT
2.2 MySQL索引
2.2.1 索引是什么
- 高效获取数据的数据结构，相当于书的目录
- 使用B+树结构（多路搜索树，并不一定是二叉的）
- 索引是存储在磁盘文件中的（可能单独的索引文件中，也可能和数据一起存储在数据文件中）
2.2.2 索引的优势和劣势
优势：
- 可以提高数据检索的效率，降低数据库的IO成本
- 通过索引对数据进行排序，降低数据排序的成本，降低CPU消耗
劣势：
- 空间换时间，索引会占据磁盘空间
- 能提高效率，但是降低更新表的效率
2.2.3 常用索引分类
- 单列索引
- 普通索引：MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值，纯粹为了查询数
据更快一点。 - 唯一索引：索引列中的值必须是唯一的，但是允许为空值。
- 主键索引：是一种特殊的唯一索引，不允许有空值
- 组合索引
- 在表中的多个字段组合上创建的一个索引
- 组合索引的使用，需要遵循最左前缀原则（最左匹配原则）。
- 一般情况下，建议使用组合索引代替单列索引（主键索引除外）。
2.2.4 索引的存储结构
-
索引是在存储引擎中实现的。
MyISAM和InnoDB存储引擎：只支持BTREE索引， 也就是说默认使用BTREE，不能够更换
2.2.5 B树和B+树
-
数据结构在线演示
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
-
B树结构
B树是为了磁盘或其它存储设备而设计的一种多叉平衡查找树（下面你会看到，相对于二叉，B树每个内结点有多个分支，即多叉）
image
B树的高度一般都是在2-4这个高度，树的高度直接决定IO读写的次数以及查询时间复杂度（log(n)）。
-
B树三层可以存储bigint类型的主键10亿条
InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针 类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为 是估值，为方便计算，这里的K取值为〖10〗3）。也就是说一个深度为3的B+Tree索引可以维护103 * 10^3 * 10^3 = 10亿 条记录。
如果是三层树结构---支撑的数据可以达到20G，如果是四层树结构---支撑的数据可以达到几十T
- B树和B+树的区别
- B树是非叶子节点和叶子节点都会存储数据。
- B+树只有叶子节点才会存储数据，而且存储的数据都是在一行上，而且这些数据都是有指针指向的，是有顺链表
2.2.6 聚集索引（InnoDB)
InnoDB存储引擎的数据组织方式，是聚簇索引表：完整的记录，存储在主键索引中，通过主键索引，就可以获取记录所有的列，也就是说表数据和索引是在一起，这就是聚集索引
InnoDB要求表必须有主键(MyISAM 可以没有),如果没有显式指定,则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL 自动为 InnoDB 表生成一个隐含字段作为主键,类型为长整形。
- 主键索引
- 辅助索引
聚集索引这种实现方式使得按主键的搜索十分高效,但是辅助索引搜索需要检索两遍索引:首先检索辅助索引获得主
键,然后用主键到主索引中检索获得记录
2.2.7 非聚集索引（MyISAM）
B+树叶子节点只会存储数据行（数据文件）的指针，简单来说数据和索引不在一起，就是非聚集索引。非聚集索引中的主键索引和辅助索引都会存储指针的值
- 主键索引
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mEgG5yIm-1595768400196)(http://ww1.sinaimg.cn/large/007OGB2sgy1g5fk8x2a3kj31b812aar4.jpg)]
- 非主键索引
在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。
2.2.8 组合索引使用
为了节省mysql索引存储空间以及提升搜索性能，可建立组合索引（能使用组合索引就不使用单列索引）
例如：创建如下的一个组合索引，相当于建立了col1,col1 col2,col1 col2 col3三个索引：
以下语句会创建一颗B+tree，但是它相对于三颗索引树的功效
ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3'）
如何选择哪些列用来创建组合索引？
- 常出现在where条件中的列，建议用来创建组合索引，至于组合索引中的顺序，是很重要的，因为组合索引会使用到最左前缀原则。但是因为MySQL中存在查询优化器，所以你的书写SQL条件的顺序，不一定是执行时候的where条件顺序。
- 常出现在order by和group by语句中的列。最后按照顺序去创建组合索引。
- 常出现在select语句中的列，也建议按照顺序，创建组合索引
最左前缀原则
顾名思义，就是最左优先，这个最左是针对于组合索引和前缀索引，理解如下：
- 最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
- =和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
2.2.9 如何使用索引
哪些情况需要创建索引
- 主键自动建立唯一索引
- 频繁作为查询条件的字段应该创建索引(业务)
- 多表关联查询中，关联字段应该创建索引
- 查询中统计或者分组字段，应该创建索引
- 查询中排序的字段，应该创建索引
哪些情况不需要创建索引
- 表记录太少
- 经常进行增删改操作的表
- 频繁更新的字段
- where条件里使用频率不高的字段
2.3 MySQL性能优化
| 类型 | 解释 |
|---|---|
| id | SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符. |
| select_type | SELECT 查询的类型. table: 查询的是哪个表partitions: 匹配的分区 |
| type | join 类型 |
| possible_keys | 此次查询中可能选用的索引key: 此次查询中确切使用到的索引. |
| ref | 哪个字段或常数与 key 一起被使用 |
| rows | 显示此查询一共扫描了多少行. 这个是一个估计值. filtered: 表示此查询条件所过滤的数据的百分比 |
| extra | 额外的信息 |
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8ta0nOc8-1595768400198)(https://i6448038.github.io/img/explain/explain.png)]
2.3.1 type讲解
显示的是单位查询的连接类型或者理解为访问类型，访问性能依次从好到差
1. system
2. const
3. eq_ref
4. ref
5. fulltext
6. ref_or_null
7. unique_subquery
8. index_subquery
9. range
10. index_merge
11. index
12. ALL
除了all之外，其他的type都可以使用到索引
除了index_merge之外，其他的type只可以用到一个索引
最少要使用到range级别
默认数据导入：https://github.com/datacharmer/test_db/blob/master/employees.sql
-
System
表中只有一行数据或者是空表
image -
const
使用唯一索引或者主键，返回记录一定是1行记录的等值where条件时，通常type是const。其他数据库也叫做唯一索引扫描
image -
eq_ref
此类型通常出现在多表的 join 查询, 表示对于前表的每一个结果, 都只能匹配到后表的一行结果. 并且查询的比较操作通常是 =, 查询效率较高
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lxSw8K3Q-1595768400201)(http://ww1.sinaimg.cn/large/007OGB2sgy1g5fx1vtac9j310s0cg0u9.jpg)]
-
ref
针对非唯一性索引，使用等值（=）查询。或者是使用了最左前缀规则索引的查询。
- 组合索引
image- 非唯一索引
image -
fulltext
全文索引检索，全文索引的优先级很高，若全文索引和普通索引同时存在时，mysql不管代价，优先选择使用全文索引
-
req_or_null
与ref方法类似，只是增加了null值的比较。实际用的不多。
-
unique_subquery
用于where中的in形式子查询，子查询返回不重复值唯一值
-
index_subquery
用于in形式子查询使用到了辅助索引或者in常数列表，子查询可能返回重复值，可以使用索引将子查询去重
-
range
索引范围扫描，常见于使用>,<,is null,between ,in ,like等运算符的查询中
imageimage -
index_merge
表示查询使用了两个以上的索引，最后取交集或者并集，常见and，or的条件使用了不同的索引，官方排序这个在ref_or_null之后，但是实际上由于要读取所个索引，性能可能大部分时间都不如range
-
index
select结果列中使用到了索引，type会显示为index。
索引扫描，把索引从头到尾扫一遍，常见于使用索引列就可以处理
image All
2.3.2 extra讲解
-
using index
查询时不需要回表查询，直接通过索引就可以获取查询的结果数据
- 表示相应的SELECT查询中使用到了覆盖索引（covering index),避免访问表的数据行
- 如果同时出现using where，说明索引被用来执行查找索引键值
- 如果没有出现using where，表明索引用来读取数据而非执行查找动作
-
using where
表示Mysql将对storage engine提取的结果进行过滤，过滤条件字段无索引
-
using index condition
Using index condition 会先条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用 WHERE 子句中的其他条件去过滤这些数据行
-
using filesort
排序时无法使用到索引时，就会出现这个。常见于order by和group by语句中说明MySQL会使用一个外部的索引排序，而不是按照索引顺序进行
2.3.3 优化SQL语句
创建索引注意：
为搜索字段（where中的条件）、排序字段、select查询列，创建合适的索引，
不过要考虑数据的业务场景：查询多还是增删多？
尽量建立组合索引并注意组合索引的创建顺序，按照顺序组织查询条件、尽量将筛选粒度大的查询条件放到最左边。
尽量使用覆盖索引
SELECT语句中尽量不要使用*。
order by、group by语句要尽量使用到索引
索引优化
- 全值匹配
- 最佳左前缀法则（ 带头索引不能死，中间索引不能断）
- 不要在索引上做计算
- 范围条件右边的列失效
- 尽量使用覆盖索引（ 尽量使用覆盖索引（只查询索引的列），也就是索引列和查询列一致，减少select）
- 索引字段上不要使用不等
- 索引字段上不要判断null（索引字段上使用 is null / is not null 判断时，会导致索引失效而转向全表扫描）
- 索引字段使用like不以通配符开头（索引字段使用like以通配符开头（‘%字符串’）时，会导致索引失效而转向全表扫描）
- 索引字段字符串要加单引号
- 索引字段不要使用or
- JOIN两张表的关联字段最好都建立索引，而且最好字段类型是一样的
其他优化
- WHERE条件中尽量不要使用1=1、not in语句（建议使用not exists）
- 不用 MYSQL 内置的函数，因为内置函数不会建立查询缓存。
- 尽量不使用count(*)、尽量使用count（主键）
总结
假设index(a,b,c)
| where语句 | 索引是否被引用 |
|---|---|
| where a = 3 | |
| where a = 3 and b = 5 | |
| where a = 3 and b = 5 and c = 4 | |
| where b = 3 或者 where b = 3 and c = 4 或者 where c = 4 | |
| where a = 3 and c = 5 | |
| where a = 3 and b > 4 and c = 5 | |
| where a = 3 and b like 'kk%' and c = 4 | |
| where a = 3 and b like '%kk' and c = 4 | |
| where a = 3 and b like '%kk%' and c = 4 | |
| where a = 3 and b like 'k%kk%' and c = 4 |
| where语句 | 索引是否被引用 |
|---|---|
| where a = 3 | Yes，使用到a |
| where a = 3 and b = 5 | Yes，使用到a，b |
| where a = 3 and b = 5 and c = 4 | Yes，使用到a，b，c |
| where b = 3 或者 where b = 3 and c = 4 或者 where c = 4 | No |
| where a = 3 and c = 5 | Yes，使用到了a，但是c不可以，因为b断了 |
| where a = 3 and b > 4 and c = 5 | Yes，使用到了a和b，c不能在范围之后，b断了 |
| where a = 3 and b like 'kk%' and c = 4 | Yes，使用到a，b，c |
| where a = 3 and b like '%kk' and c = 4 | Yes，使用到了a |
| where a = 3 and b like '%kk%' and c = 4 | Yes，使用到了a |
| where a = 3 and b like 'k%kk%' and c = 4 | Yes，使用到a，b，c |
2.3.4 服务器参数调优
- 设置足够大的innodb_buffer_pool_size，将数据读取到内存中(建议innodb_buffer_pool_size设置为总内存大小的3/4或者4/5.)
怎样确定 innodb_buffer_pool_size 足够大。数据是从内存读取而不是硬盘？
SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_pages_%';
- 内存预热
将磁盘数据在MySQL Server启动的时候，读取到内存中。
-
降低磁盘写入次数
对于生产环境来说，很多日志是不需要开启的，比如：通用查询日志
-
慢查询日志、错误日志使用足够大的写入缓存 innodb_log_file_size
推荐 innodb_log_file_size 设置为 0.25 * innodb_buffer_pool_size
设置合适的innodb_flush_log_at_trx_commit，和日志落盘有关系
提高磁盘读写
可以考虑使用SSD硬盘，不过得考虑成本是否合适
2.3.5 硬件选购和参数优化
- 内存相关
内存的 IO 比硬盘的速度快很多，可以增加系统的缓冲区容量，使数据在内存停留的时间更长，以减少磁盘的 IO
- 磁盘 I/O 相关
- 使用 SSD 或 PCle SSD 设备，至少获得数百倍甚至万倍的 IOPS 提升
- 购置阵列卡同时配备 CACHE 及 BBU 模块，可以明显提升 IOPS
- 尽可能选用 RAID-10，而非 RAID-5
- 配置 CUP 相关
- 在服务器的 BIOS 设置中，调整如下配置：
- 选择 Performance Per Watt Optimized（DAPC）模式，发挥 CPU 最大性能
- 关闭 C1E 和 C States 等选项，提升 CPU 效率
- Memory Frequency（内存频率）选择 Maximum Performance
2.3.6 SQL设计层面优化
- 表设计
设计中间表，一般针对于统计分析功能，或者实时性不高的需求（OLTP、OLAP）
为减少关联查询，创建合理的冗余字段（考虑数据库的三范式和查询性能的取舍，创建冗余字段还需要注意数据一致性问题
每张表建议都要有一个主键（主键索引），而且主键类型最好是int类型，建议自增主键（不考虑分布式系统的情况下）
- 选择合适的数据类型
使用可以存下数据最小的数据类型
使用简单的数据类型。int 要比 varchar 类型在mysql处理简单
尽量使用 tinyint、smallint、mediumint 作为整数类型而非 int
尽可能使用 not null 定义字段，因为 null 占用4字节空间
尽量少用 text 类型,非用不可时最好考虑分表
尽量使用 timestamp 而非 datetime
单表不要有太多字段，建议在 20 以内
-
拆分表
对于表中经常不被使用的字段或者存储数据比较多的字段，考虑拆表
对于字段太多的大表，考虑垂直拆表（比如一个表有100多个字段
比如商品表中会存储商品介绍，此时可以将商品介绍字段单独拆解到另一个表中，使用商品ID关联）
- 垂直拆分：将表中多个列分开放到不同的表中。例如用户表中一些字段经常被访问，将这些字段放在一张表中，另外一些不常用的字段放在另一张表中。插入数据时，使用事务确保两张表的数据一致性。
- 水平拆分：按照行进行拆分。例如用户表中，使用用户ID，对用户ID取10的余数，将用户数据均匀的分配到0~9的10个用户表中。查找时也按照这个规则查询数据。
-
读写分离
一般情况下对数据库而言都是“读多写少”。换言之，数据库的压力多数是因为大量的读取数据的操作造成的。我们可以采用数据库集群的方案，使用一个库作为主库，负责写入数据；其他库为从库，负责读取数据。这样可以缓解对数据库的访问压力。
2.3.7 数据库架构调优
- 分区分表
- 业务分库
- 主从同步与读写分离
- 数据缓存
- 主从热备与HA双活
2.4 实战优化
-
慢SQL优化挑战赛
表结构
CREATE TABLE `a` ( `id` int(11) NOT NULL AUTO_INCREMENT, `seller_id` bigint(20) DEFAULT NULL, `seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=32744 DEFAULT CHARSET=utf8; CREATE TABLE `b` ( `id` int(11) NOT NULL AUTO_INCREMENT, `seller_name` varchar(100) DEFAULT NULL, `user_id` varchar(50) DEFAULT NULL, `user_name` varchar(100) DEFAULT NULL, `sales` bigint(20) DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=32744 DEFAULT CHARSET=utf8; CREATE TABLE `c` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` varchar(50) DEFAULT NULL, `order_id` varchar(100) DEFAULT NULL, `state` bigint(20) DEFAULT NULL, `gmt_create` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=458731 DEFAULT CHARSET=utf8;待优化SQL
select a.seller_id, a.seller_name, b.user_name, c.state from a,b,c where a.seller_name = b.seller_name and b.user_id = c.user_id and c.user_id = 17 and a.gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL 600 MINUTE) and DATE_ADD(NOW(), INTERVAL 600 MINUTE) order by a.gmt_create;创建索引
-- A表上创建索引： Alter table a add index ind_a_gmt_create(gmt_create); -- B表上创建索引： Alter table b add index ind_b_seller_name(seller_name); -- C表创建索引： Alter table c add index ind_c_user_id(user_id);
隐式转换
-- a表：gmt_create使用了varchar来存储，在5.6支持更高时间精度后，将会发生隐式转换。
-- b表：a表和b表的seller_name字段在COLLATE定义上不一致，也会导致隐式转换。
-- c表：b表和c表的user_id字段都定义为了varchar，但是SQL传入为数字，也会导致隐式转换。
alter table a modify column gmt_create datetime;
alter table a modify column seller_name varchar(100) ;
alter table c modify column user_id bigint;
-
优化LIMIT分页
尽可能的使用覆盖索引扫描
SELECT ID, ADDRESS FROM PROJECT ORDER BY STATUS LIMIT 64000, 100SELECT SQL_NO_CACHE `b_regbroker`.*,`db`.`name`,db.sub_branch,db.account,db.card_img,mu.UserName,pb.broker_name,pb.mobile_tel from b_regbroker LEFT JOIN myuser mu on mu.UserGUID=b_regbroker.ModifiedBy LEFT JOIN b_regbroker pb on pb.b_regbrokerId=b_regbroker.parent_brokerId LEFT JOIN b_regbroker_bank db on db.regbroker_id = b_regbroker.b_regbrokerId and isdel=0 and isdefault=1 where b_regbroker.`status` in (1,2) and b_regbroker.token='rkqqnn1427611021' and b_regbroker.is_delete=0 and IFNULL(b_regbroker.capacity_des,'') <> '9108' ORDER BY CreatedOn desc LIMIT 126000, 3000;
SELECT p.ID,p.ADDRESS
FROM PROJECT p
INNER JOIN (
SELECT ID FROM PROJECT ORDER BY STATUS LIMIT 64000, 100
) AS tmp
ON p.ID = tmp.ID
SELECT SQL_NO_CACHE `b_regbroker`.*,`db`.`name`,db.sub_branch,db.account,db.card_img,mu.UserName,pb.broker_name,pb.mobile_tel
from b_regbroker
LEFT JOIN myuser mu on mu.UserGUID=b_regbroker.ModifiedBy
LEFT JOIN b_regbroker pb on pb.b_regbrokerId=b_regbroker.parent_brokerId
LEFT JOIN b_regbroker_bank db on db.regbroker_id = b_regbroker.b_regbrokerId
and isdel=0 and isdefault=1
where b_regbroker.`status` in (1,2)
and b_regbroker.token='rkqqnn1427611021'
and b_regbroker.is_delete=0
and IFNULL(b_regbroker.capacity_des,'') <> '9108'
AND b_regbroker.CreatedOn <= '2016-07-23 14:19:04'
ORDER BY CreatedOn desc
LIMIT 3000;
3. 参考
- https://zhaox.github.io/2016/06/24/mysql-architecture【MySQL的多存储引擎架构】
- https://segmentfault.com/a/1190000010681611【MySQL三层逻辑架构】
- https://www.jianshu.com/p/1f17a496f14e【MySQL架构及历史】
- https://www.cnblogs.com/wy123/p/7102128.html【MySQL 物理文件体系结构的简单整理说明】
- http://database.51cto.com/art/201901/590564.htm【一份超详细的MySQL高性能优化实战总结！】
- https://blog.csdn.net/asdfsadfasdfsa/article/details/83015488【从数据库层面理解：随机 I/O & 顺序 I/O】
- https://juejin.im/post/59d83f1651882545eb54fc7e#heading-26【MySQL 性能优化技巧】
- https://www.cnblogs.com/nullzx/p/8729425.html【B树和B+树的插入、删除图文详解】
- https://blog.51cto.com/13912525/2313851【随机读写与顺序读写怎么去理解】
- https://www.kancloud.cn/kancloud/theory-of-mysql-index/41851【MySQL索引背后的数据结构及算法原理】
- https://www.jianshu.com/p/5600781f67ba 【聊一聊B+树】
- https://www.jianshu.com/c/cd1570246385【高性能MySQL】
- https://blog.csdn.net/qq_26222859/article/details/80631121【b+树图文详解】
- https://juejin.im/post/5d351303f265da1bd30596f9【[灵魂拷问]MySQL面试高频一百问(工程师方向)】
- https://juejin.im/post/5d3423c35188252bd255de32【MySql优化之索引原理与 SQL 优化】
- https://juejin.im/post/5d1c32bf51882551253e483d【MySQL 中NULL和空值的区别？】
- https://my.oschina.net/benhaile/blog/849499【记一次mysql性能优化过程】
- https://yq.aliyun.com/articles/645477【MySQL高性能优化实战总结！】
- https://blog.csdn.net/weixin_39152648/article/details/80250741【MySQL优化原理，这一篇就够了！】
- https://www.bilibili.com/video/av56419635/【MySQL性能优化视频】
- https://cloud.tencent.com/developer/article/1056041【MySQL性能优化的最佳20+条经验】
- https://www.centos.bz/2017/09/mysql-big-table-performance-optimize/【MySQL大表性能优化方案】
- http://www.365jz.com/article/24732【MySQL性能优化提升访问速度的方法】
- https://juejin.im/post/5d23ef4ce51d45572c0600bc【我以为我对Mysql索引很了解，直到我遇到了阿里的面试官】
- https://juejin.im/post/5d1758d06fb9a07eed351405【推荐收藏！MySQL重要知识点/面试题总结。】
- https://juejin.im/post/5d2335846fb9a07f021a2509#heading-127【客官，这里有一份《MySQL 必知必会》读书笔记，请您笑纳!】
- https://www.jianshu.com/p/9fab9266be84【一次非常有意思的SQL优化经历:从30248.271s到0.001s】
- https://www.jianshu.com/p/569569b8b40c【mysql数据库设计中的14个技巧】
- https://www.jianshu.com/p/a14ea51a4458【心里没点B树，怎能吃透数据库索引底层原理？】
- https://yq.aliyun.com/articles/136363?spm=5176.100240.searchblog.32.oYlhtr【速围观！慢SQL数据库挑战赛】
- https://cloud.tencent.com/developer/article/1200822【MySQL探秘(二)：SQL语句执行过程详解】、
- https://www.cnblogs.com/annsshadow/p/5037667.html【MySQL架构总览->查询执行流程->SQL解析顺序】
- https://github.com/datacharmer/test_db【mysql test_db】