高手问答第 312 期 —— 聊聊优化慢 SQL 那些事

小白兔爱吃大灰狼 发布于 2024/01/02 11:47
阅读 15K+
收藏 6

阅读《2024 中国开源开发者报告》赢大奖,扫码申请享特权

公司在业务发展初期,为了将产品快速投入市场验证商业模式或适应市场需要业务快速迭代,对系统架构设计要求较低。随着业务的不断发展系统和数据量也逐渐庞大,对系统性能和稳定性要求却越来越高,但此时系统性能逐渐开始显露瓶颈,没错~ 这是前期埋下的技术债开始浮出水面。

那我们如何解决性能瓶颈问题呢? 老程序员们都知道70%以上的性能瓶颈在数据库,因为慢SQL导致了性能瓶颈。

那么如何优化慢SQL呢?如何避免慢SQL呢?

OSCHINA 本期高手问答(1 月 3 日 - 1 月 9 日)我们请来了嘉宾高峰老师和大家一起聊聊优化慢 SQL 那些事。

可讨论的问题包括但不限于

  • 慢SQL发生的场景
  • 慢SQL优化思路
  • 慢SQL优化案例
  • 如何避免慢SQL
  • 分库分表的架构设计

其他相关的问题,也欢迎提问!

嘉宾介绍

高峰,京东物流架构师,10年以上架构设计和性能优化经验,支持京东物流集团国际技术部商家平台订单异步化的架构设计和落地,分布式文件存储系统的架构设计,慢SQL性能优化解决方案和优化工作推进等。

2022年获得《京东物流最佳贡献奖》

2023年获得《京东物流年度最佳设计奖》

🎁 为了鼓励踊跃提问,问答结束后我们将从提问者中抽取 5 名幸运会员,赠予京东joy公仔一个。

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就 “优化慢 SQL ” 相关问题向 高峰老师 提问,直接回帖提问既可。

加载中
0
小白兔爱吃大灰狼
小白兔爱吃大灰狼

高手问答第 312 期 —— 聊聊优化慢 SQL 那些事

@大熊小鸽鸽 @xiaour  @VdongA @kowhi  @益达先生

恭喜以上5位网友分别获得 京东 joy 公仔一个

请于2024年1月18日23点前登陆账号, 私信  @小白兔爱吃大灰狼   告知快递信息(格式:姓名+电话+地址),过期视为自动放弃哦~

7
大熊小鸽鸽
大熊小鸽鸽

引用来自“xiaour”的评论

@京东云开发者  您好,我们平时在性慢SQL优化的时候,更多的是针对SQL本身进行调优,很少对产品设计或者交互逻辑进行调整。那么很多慢SQL优化的效果一般不会得到非常显著的提升的;请问下您平时有没有说从产品设计层面调整的情况?或者怎么去说服产品经理调整设计的呢?

我感觉这种情况下,还是要看技术团队是否有话语权,整个团队是否有工程师文化。况且有些时候,确实是产品层面规划混乱进而导致的技术服务层和数据层的混乱。

freekevin
freekevin
回复 @zpache : 产品层面确实很多事伪需求 或者 讲需求的人 就没搞明白自己到底想要什么
zpache
zpache
优化一段时间慢SQL后,系统剩下的慢SQL基本都是顽疾,技术层面已经很难优化,只能从产品层面去调整功能或交互逻辑了,比如某些日期查询条件必选要选择一个、下拉框选项不超过1000个,模糊匹配的功能调整等等
1
大熊小鸽鸽
大熊小鸽鸽

老师您好,想与您探讨下关于分库分表的一点看法。

我认为,分库分表是在单机数据库承接不下海量数据且分布式数据库尚未成熟的情况下,催生出来的产物,属于是一种折中的方案。

就目前来看,分布式数据库的生态逐渐完善,如TiDB、PolarDB、TDSQL等,那么此时面对海量业务数据,是否还有分库分表的必要呢?是否可以在单机数据库即将达到瓶颈的时候逐步迁移到分布式数据库中?

zpache
zpache
回复 @京东云开发者 : 公司引进了oceanbase,提效几乎没有,部分SQL用ob的hint并发写法,并发高的时候直接把数据库CPU打满
大熊小鸽鸽
大熊小鸽鸽
@京东云开发者 感谢老师的回答,十分详细。
京东云开发者
京东云开发者
首先,感谢这位网友的提问。因为回复的规则设置,单条回复内容不能超过200字,我将拆分如下来回答您的问题。
京东云开发者
京东云开发者
主流分布式数据库都对具体的sharding机制做了封装,提升了开发人员在开发中的体验,随着企业不断发展数据量不断激增,分布式数据库的引入为企业的发展提供了很好的支撑,当数据库达到瓶颈是可以逐步迁移到分布式数据库的。但是想用好分布式数据库我们还是需要对分库分表技术有所了解的,毕竟分布式数据库的底层还是离不开分库分表技术。
京东云开发者
京东云开发者
既然有了分布式数据库,分库分表技术是否就没有价值了呢?我想从4个方面来回答您的问题。 1、成本方面: 小公司在发展初期没有那么大数据量所以不太可能提高成本采用分布式数据库。 大公司都有自己的中间件和DBA团队还有成熟的分库分表技术方案,对于重视降本增效的大公司来说,分布式数据库的引入会提升两方面的成本, 第一 分布式数据库自身的购买成本,第二 DBA团队维护成本。提效方面并不是很明显。
下一页
1
V
VdongA

@京东云开发者 您好,之前遇到一个使用场景,大概16万的数据,倒序连表查询的情况下,分页页码越到后面sql运行速度越慢,我尝试过使用子查询来限定查询范围,但是子查询的条件也需要连表查询,导致性能并没有提升多少,我也查看过sql的执行计划,where 条件的字段都触发了索引,我甚至还记录过上一页码的最后一个ID,用来作为下一页的ID筛选条件,但是前端如果是从第一页跳转到6,7千页码也会比较慢,请问遇到这个问题,我们应该从哪些方面来解决这个问题。

V
VdongA
回复 @kowhi : 好的,明白了,感谢
京东云开发者
京东云开发者
您好,您这是管理端吧,如果是管理端后续的查询条件会越来越复杂建议上es。
k
kowhi
看看淘宝的,绝大多数情况下100页就够了,6-7千页,用户很少会这么干的吧
0
大熊小鸽鸽
大熊小鸽鸽

我对慢“SQL的避免和优化”的一点点想法,大概就是三步。

1.合理设置索引

2.正确使用索引

3.学会查看执行计划并养成习惯

0
S
Shikinami02

@京东云开发者 order by 语句放内层排序还是放最后排序 对SQL速度有影响吗

魔力猫
魔力猫
回复 @AsukaQua : 除非你内层有只取前N条这种业务需求,不然排序应该放到最后处理。
S
Shikinami02
回复 @京东云开发者 : 内层先查出数据后排序 还是内层不排序 内层各种联表后排序 排序字段不变 这种场景下 到底如何处理排序问题
京东云开发者
京东云开发者
您好,感谢提问,有点抽象可以举个例子吗?
0
xiaour
xiaour

@京东云开发者  您好,我们平时在性慢SQL优化的时候,更多的是针对SQL本身进行调优,很少对产品设计或者交互逻辑进行调整。那么很多慢SQL优化的效果一般不会得到非常显著的提升的;请问下您平时有没有说从产品设计层面调整的情况?或者怎么去说服产品经理调整设计的呢?

xiaour
xiaour
回复 @京东云开发者 : 确实,要平衡成本问题。
京东云开发者
京东云开发者
这个问题特别好,很多时候通过产品设计和交互逻辑的调整要比单纯sql优化效果好很多。 上次的双11大促有不少优化采用了交互逻辑调整的方式。 在不改变原业务功能和体验,不产生大量成本的基础上提升性能,产品大概率是可以支持的。
0
varyuan
varyuan

@京东云开发者 最近工作上是在做一个统计的功能, sql慢的原因不是sql有问题,是数据表设计得有问题, 该建索引的字段没建索引, 还遇到了表字段太多,字段类型不合理,很多text类型, 数据量太大这些情况, 导致查询太慢, 表字段很多统计的时候其实不需要用,所以我想了从源表抽几个字段作为一张新表进行统计, 用的mysql数据库,只找到建触发器来同步源表和新表的数据这种方法, 想问一下如果把需要统计的字段放到一个组合索引里是不是和建少字段新表一样的效果

kis龍
kis龍
回复 @京东云开发者 : 不建新表,创建视图有效果吗?
京东云开发者
京东云开发者
您好, 建议不建表。 可把创建时间字典加上索引,写个定时任务根据创建时间字段按月或季度统计,把最后统计的结果加起来。
0
k
kowhi

@京东云开发者
最近遇到一个问题,删除大量数据后,碎片较多,通过 alter table xx engine = InnoDB优化表碎片空间,导致Iops占用非常高,持续大约10几分钟。目前在凌晨低峰期执行,暂未遇到问题,想问下是否有更好的设计方案。
基本情况:云上数据库mysql,磁盘总大小30G,该表单日写入数据量500万,只保留5天的数据,需要提供查询。存储6天的数据,磁盘占用大概10GB,其中数据空间大概5GB,索引5GB。每天定时任务删除5天前的数据,删除后碎片大概占1GB,如果不进行碎片整理,时间久了会影响存储。在不更换数据库的前提下,是否有更好的设计方案

京东云开发者
京东云开发者
方案1: 可以考虑采用天表,每天一个表,表名前缀_日期, 查数据的时候查对应的天表; 超过的数据可以执行drop或者truncate; 方案2:用分区表,drop partition xxx;
0
益达先生
益达先生

@京东云开发者

你好,最近准备上线一个功能,需要新建表,关于表主键是用自增,uuid,雪花Id等,和同事产生了分歧😂,能指导下用哪种方式么?

centos7,oracle数据库,一年能产生600W条数据

京东云开发者
京东云开发者
主键肯定是递增的,但是需要添加一个全局唯一ID字段(加个唯一索引),主要用于未来后期可能的分表分库使用,这个全局唯一ID可以使用雪花Id。uuid不建议,因为不能排序,也不是趋势递增的。
大熊小鸽鸽
大熊小鸽鸽
回复 @魔力猫 : 是的,MySQL主键不建议使用uuid。不过一年才600W数据,就算用了uuid,感受也不会很明显。
益达先生
益达先生
回复 @大熊小鸽鸽 : 好的,感谢
益达先生
益达先生
回复 @魔力猫 : 谢谢
大熊小鸽鸽
大熊小鸽鸽
直接上雪花ID就可以的
下一页
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部