{eval=Array;=+count(Array);}

问答专栏Q & A COLUMN

SQL数据库如何优化?

mengera88mengera88 回答0 收藏1
收藏问题

1条回答

Brenner

Brenner

回答于2022-06-28 13:53

之前在BAT里参与过一个公司级应用(非市场级,投入的人力也不会那么大),上线2年后,总是被用户投诉,原因是这个应用使用MySql数据库来做持久层,但是2年了,有一张非常重要的存储历史任务的表实在是太大了,导致通过页面想要查询历史数据的速度变得非常非常慢,所以用户很是不满意。

分析下来,这不是用Redis能解决的缓存问题,而是历史数据的查询响应速度问题。

我们最开始是希望能够通过增加索引的方式解决,但是面对千万级别的数据量,我们也不敢贸然加索引,因为一旦数据库hang住,期间的所有数据库写入请求都会被放到等待队列中,如果请求是通过http请求发过来的,很有可能导致服务发生分钟级别的超时不响应。

虽然经常被用户投诉反应慢,也不能破罐破摔,直接超时不响应了吧。

于是我们陷入了两难的境地。

后来我们分了两个部分来优化持久层。

MySQL的主从配置

第一步就是配置MySQL的主从库,通过将读写请求分离,来提高数据库的响应速度。

从上图可知,来自同一台服务器的请求,经过MySQL-proxy被分流给了不同的MySQL节点,其中写请求给了主节点,读请求给了从节点。因此,我们首先通过分流的方式,减轻了单节点MySQL的响应压力,实现了优化的第一步。

引入ElasticSearch

但是,只配置MySQL的主从是远远不够的。

通过查阅论坛,相关资料,我们最终敲定在持久层引入ElasticSearch。

Elastic Search是一个轻量级的持久层工具,它支持动态多节点部署,自动备份,节点掉线后能够自动切换主从,动态广播发现新上线的节点,而这些优点的应用,无须修改任何server端配置。可以这样理解,如果你部署了4个elastic search节点,其中2个掉了,服务器还是可以很好的继续运行。

此外,它还有一个最重要的优势,那就是支持大数据快速查询。一张几千万的表,如果用MySQL查询,可能需要几秒到几十秒不等,但是如果用elastic search,只需要毫秒级别就能查询到结果。完美的解决了我们当前的问题,还顺带帮我们巩固了持久层的稳定性问题。


综上,优化Mysql的目的是为持久层服务,除了引入主从配置,当MySQL自身局限性导致无法继续优化后,引入其他技术也是十分必要的。


如果你对这篇回答有任何问题,欢迎在下方点赞,留言。

我是苏苏思量,来自BAT的java开发工程师,头像是本人,每天都会分享科技类见闻,欢迎关注我,与我共同进步。

评论0 赞同0
  •  加载中...

相关问题

最新活动

您已邀请0人回答 查看邀请

我的邀请列表

  • 擅长该话题
  • 回答过该话题
  • 我关注的人
向帮助了您的网友说句感谢的话吧!
付费偷看金额在0.1-10元之间
<