Go最新慢 SQL 分析与优化(3)，2024年最新Golang零基础
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加戳这里获取
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
该方式较方式一的优点在于可并行查询，每个分段查询互不依赖；较方式一的缺点在于较依赖数据的连续性，若数据过于分散，代价较高。
minId = min(id) maxId = max(id)
for(int i = minId; i<= maxId; i+=pageSize){
select * from table_demo where type = ? and id between i and i+ pageSize;
}
优化 GROUP BY
提高 GROUP BY 语句的效率, 可以通过将不需要的记录在 GROUP BY 之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多。
低效:
select job , avg(sal) from table_demo group by job having job = ‘manager'
高效:
select job , avg(sal) from table_demo where job = ‘manager' group by job
范围查询
联合索引中如果有某个列存在范围（大于小于）查询，其右边的列是否还有意义？
explain select count(1) from statement where org_code='1012' and trade_date_time >= '2019-05-01 00:00:00' and trade_date_time<='2020-05-01 00:00:00'
explain select * from statement where org_code='1012' and trade_date_time >= '2019-05-01 00:00:00' and trade_date_time<='2020-05-01 00:00:00' limit 0, 100
explain select * from statement where org_code='1012' and trade_date_time >= '2019-05-01 00:00:00' and trade_date_time<='2020-05-01 00:00:00'
-
使用单键索引 trade_date_time 的情况下
- 从索引里找到所有 trade_date_time 在’2019-05-01’ 到’2020-05-01’ 区间的主键 id。假设有 100 万个。
- 对这些 id 进行排序（为的是在下面一步回表操作中优化 I/O 操作，因为很多挨得近的主键可能一次磁盘 I/O 就都取到了）
- 回表，查出 100 万行记录，然后逐个扫描，筛选出 org_code='1020’的行记录
-
使用联合索引 trade_date_time, org_code -联合索引 trade_date_time, org_code 底层结构推导如下：
以查找 trade_date_time >=‘2019-05-01’ and trade_date_time <=‘2020-05-01’ and org_code='1020’为例：
- 在范围查找的时候,直接找到最大,最小的值,然后进行链表遍历，故仅能用到 trade_date_time 的索引，无法使用到 org_code 索引
- 基于 MySQL5.6+的索引下推特性，虽然 org_code 字段无法使用到索引树，但是可以用于过滤回表的主键 id 数。
小结：对于该 case, 索引效果[org_code,trade_date_time] > [trade_date_time, org_code]>[trade_date_time]。实际业务场景中，检索条件中 trade_date_time 基本上肯定会出现，但 org_code 却不一定，故索引的设计还需要结合实际业务需求。
优化 Order by
索引：
KEY `idx_account_trade_date_time` (`account_number`,`trade_date_time`),
KEY `idx_trade_date_times` (`trade_date_time`)
KEY `idx_createtime` (`create_time`),
慢 SQL:
SELECT id,....,creator,modifier,create_time,update_time FROM statement
WHERE (account_number = 'XXX' AND create_time >= '2022-04-24 06:03:44' AND create_time <= '2022-04-24 08:03:44' AND dc_flag = 'C') ORDER BY trade_date_time DESC,id DESC LIMIT 0,1000;
优化前：SQL 执行超时被 kill 了
SELECT id,....,creator,modifier,create_time,update_time FROM statement
WHERE (account_number = 'XXX' AND create_time >= '2022-04-24 06:03:44' AND create_time <= '2022-04-24 08:03:44' AND dc_flag = 'C') ORDER BY create_time DESC,id DESC LIMIT 0,1000;
优化后：执行总行数为:6 行，耗时 34ms。
MySQL使不使用索引与所查列无关，只与索引本身，where条件，order by 字段，group by 字段有关。索引的作用一个是查找，一个是排序。
业务拆分
select * from order where status='S' and update_time < now-5min limit 500
拆分优化：
随着业务数据的增长 status='S’的数据基本占据数据的 90%以上，此时该条件无法走索引。我们可以结合业务特征，对数据获取按日期进行拆分。
date = now; minDate = now - 10 days
while(date > minDate) {
select * from order where order_date={#date} and status='S' and update_time < now-5min limit 500
date = data + 1
}
数据库结构优化
- 范式优化：表的设计合理化（符合 3NF），比如消除冗余（节省空间）；
- 反范式优化：比如适当加冗余等（减少 join）
- 拆分表：分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘 I/O，一个精心设置的分区可以将数据传输对磁盘 I/O 竞争均匀地分散开。对数据量大的表可采取此方法，可按月建表分区。
SQL 语句优化
SQL 检查状态及分数计算逻辑
- 尽量避免使用子查询
- 用 IN 来替换 OR
- 读取适当的记录 LIMIT M,N，而不要读多余的记录
- 禁止不必要的 Order By 排序
- 总和查询可以禁止排重用 union all
- 避免随机取记录
- 将多次插入换成批量 Insert 插入
- 只返回必要的列，用具体的字段列表代替 select * 语句
- 区分 in 和 exists
- 优化 Group By 语句
- 尽量使用数字型字段
- 优化 Join 语句
大表优化
- 分库分表（水平、垂直）
- 读写分离
- 数据定期归档
原理剖析
MySQL 逻辑架构图：
索引的优缺点
优点
- 提高查询语句的执行效率，减少 IO 操作的次数
- 创建唯一性索引，可以保证数据库表中每一行数据的唯一性
- 加了索引的列会进行排序，在使用分组和排序子句进行查询时，可以显著减少查询中分组和排序的时间
缺点
- 索引需要占物理空间
- 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
- 当对表中的数据进行增删改查时，索引也要动态的维护，这样就降低了数据的更新效率
索引的数据结构
主键索引
普通索引
组合索引
索引页结构
索引页由七部分组成，其中 Infimum 和 Supremum 也属于记录，只不过是虚拟记录，这里为了与用户记录区分开，还是决定将两者拆开。
数据行格式：
MySQL 有 4 种存储格式：
- Compact
- Redundant （5.0 版本以前用，已废弃）
- Dynamic （MySQL5.7 默认格式）
- Compressed
Dynamic 行存储格式下，对于处理行溢出（当一个字段存储长度过大时，会发生行溢出）时，仅存放溢出页内存地址。
索引的设计原则
哪些情况适合建索引
-
数据又数值有唯一性的限制
-
频繁作为 where 条件的字段
-
经常使用 group by 和 order by 的字段，既有 group by 又有 order by 的字段时，建议建联合索引
-
经常作为 update 或 delete 条件的字段
-
经常需要 distinct 的字段
-
多表连接时的字段建议创建索引，也有注意事项
- 连接表数量最好不要超过 3 张，每增加一张表就相当于增加了一次嵌套循环，数量级增长会非常快
- 对多表查询时的 where 条件创建索引
- 对连接字段创建索引，并且数据类型保持一致
-
在确定数据范围的情况下尽量使用数据类型较小的，因为索引会也会占用空间
-
对字符串创建索引时建议使用字符串的前缀作为索引
-
这样做的好处是：
- 能节省索引的空间，
- 虽然不能精确定位，但是能够定位到相同的前缀，然后通过主键查询完整的字符串，这样既能节省空间，又减少了字符串的比较时间，还能解决排序问题。
-
区分度高（散列性高）的字段适合作为索引。
-
在多个字段需要创建索引的情况下，联合索引优先于单值索引。使用最频繁的列作为索引的最左侧 。
哪些情况下不需要使用索引
- 在 where 条件中用不到的字段不需要。
- 数据量小的不需要建索引，比如数据少于 1000 条。
- 由大量重复数据的列上不要建索引，比如性别字段中只有男和女时。
- 避免在经常更新的表或字段中创建过多的索引。
- 不建议主键使用无序的值作为索引，比如 uuid。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加戳这里获取
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
)]
[外链图片转存中…(img-Po0DZo8v-1715896426202)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加戳这里获取
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！