数据库版本
阿里云 RDS SQLSERVER
需求
需求是因为老项目的长 SQL 实在是过于多了，几百行的 SQL 一找一个准，去优化 SQL 工作量非常大。
导致生产环境数据库很不稳定，经常因为 SQL 引起数据库不可用导致被客户投诉罚钱，问了阿里云他们推荐高可用集群，但是阿里云高可用对于小企业来说实在是太贵了。迁移下云又需要比较专业的 DBA 来运维数据库，小企业老板估计也不会同意。
做了什么
已经做了这几步：
-
使用了 DTS ，同步主库的数据到从库，基本上实现了读写分离；
-
拆分了核心业务，但是核心业务仍然有访问数据库的需求，因此万一数据库不可用时，如何保证核心业务的正常运行，成为了一个大问题；
想做什么：
领导提了一个想法：能否通过在中间加一层缓存层的方式，比如 Redis ，核心业务的增删改查先走 Redis 。一段时间后落库，这样即使数据库挂了，只要能撑住 10 分钟数据库就能恢复。
其他方案：
将数据库和接口都进行拆分，拆成多服务，需要对应数据的，走接口进行查询调用
不知道有没有其他更好的方案，求大佬们指教，谢谢~
48 条回复 • 2024-12-17 14:49:52 +08:00
 |
1
duuu 4 小时 11 分钟前
那 Redis 挂了呢
|
 |
3
evan1 4 小时 7 分钟前
我遇到的项目都是先加监控，定位慢 SQL 然后进行针对性的优化，比如加索引，分库分表之类的。
没有遇到过用 redis 做这种中间库的。 |
 |
4
bg7lgb 4 小时 2 分钟前
数据库优化，从应用开始，而不是从数据库层面入手。
老老实实查日志，找慢 SQL 优化。 |
|
5
bg7lgb 4 小时 1 分钟前
Redis 做缓存，增加了技术的复杂性，故障节点也多了。
而且目前这个问题也不是用高可用版本就可以解决的。 |
 |
7
seedhk OP @bg7lgb 大佬说的是，这样加东西，只会增加复杂性和排查问题的难度，最根本还是得优化 SQL 。
有没有什么其他好一些的方案？ 因为 SQL 优化是一个很漫长的过程，其中还牵涉到很多老的业务逻辑，那些 SQL 和表我看过，给我的感觉是一天能改好一个都已经不错了。 |
 |
8
Varobjs 3 小时 50 分钟前
redis 缓存有个项目叫 readyset ，可以兼容 mysql 协议，数据库连接可以直接改为 readyset 端口，默认 sql 都会直连数据库，可以在控制台指定 sql ，走内存
|
 |
9
SoulSleep 3 小时 49 分钟前
@evan1 +1
不解决问题，要靠堆配置是最后的选择，又不舍得花钱，这不是既要又要吗？ 阿里云的 dts 使用场景主要是异构数据库，相同数据库直接开主从就好了.... 再就是如果分析型 sql 过多可以考虑用列存数据库、可以考虑加读写分离。。。但是归根结底 必须要做的： 精简在线业务库的单表大小（做做历史归档？） 做慢 SQL 优化（加索引、改写法、做限流...) 优化业务逻辑（如同步改异步） |
|
10
seedhk OP @SoulSleep 谢谢大佬的指导
1.公司买的是阿里云的 RDS sqlserver ，除了 DTS ，不支持其他方式做主从或者读写分离； 2.精简在线业务库的单表大小、做慢 SQL 优化、优化业务逻辑 这些都有在做，也在拆分核心业务，但是数据库这一层始终没有非常好的办法解决。 列存数据库您具体指的是哪些？ |
|
12
bg7lgb 3 小时 44 分钟前
挂的时候是什么情况？系统响应慢导致服务不可用？还是直接崩掉了？
最直接的方法就是升级配置，先缓解一下，争取点时间来优化。 |
 |
13
cccb 3 小时 43 分钟前
可以参考，[redis gears write-behind]( https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/gears-v1/python/recipes/write-behind/)
|
 |
14
goodryb 3 小时 40 分钟前
redis 本质是做缓存的（不乏一些开了持久化当数据库用），提升查询效率，正常写逻辑都是要直接写库
而且加缓存业务也得改，不如好好投入精力，优化 SQL ，短期来不及就先升级配置，后续改好了再奖降回去 |
 |
15
fatyoung 3 小时 38 分钟前
用 redis 做只读缓存应该可以分担很多数据库压力吧？看描述应该是数据量不大，只是 sql 执行时间长吧？
|
 |
16
adoal 3 小时 37 分钟前
这种典型的传统信息化型应用的性能瓶颈问题，就不要指望能直接套互联网基础设施来速成了。
|
|
17
seedhk OP @bg7lgb 最常见的情况就是因为 SQL 太复杂，表数据量又太大，引起数据库 CPU 过高导致数据库服务不可用，一般重启就能解决，但是也要将近 10 分钟时间。配置目前是 16C 32G 次高，在网上就是顶配 16C 64G 。业务压力点是夏天，时间大概有 2-4 个月。
|
|
18
seedhk OP |
 |
19
gostair 3 小时 23 分钟前
redis 增删改查,定期同步到 db,在游戏业务服务器上,是比较常见的方案.
但这种方案,仅针对单条记录的线性的增删改查. 但如果复杂业务复杂 sql,比如涉及跨表查询,比如 事务性的多表修改,加缓存层 实现起来也比较麻烦吧? 何况还得考虑并发等情况. 具体还得结合你的业务场景,看起来是复杂 sql,目测不适合. |
 |
21
blackeeper 3 小时 16 分钟前
感觉你需要的是一个网关，对流量进行拦截，限流，限频。从而服务降级，来保证数据库不崩溃。
当你数据库慢的时候，前端不断的重试，刷新，加重数据库的卡死。 |
 |
22
mangodai 3 小时 13 分钟前
要看业务规模 和 架构。
redis 确实做过库存扣件最后落 db 。 infoq 写过快手等电商系统， 对于直播超大秒杀百万 qps 直接走 redis 。 你们有这个业务场景，和维护 redis 库存的技术能力吗？ |
 |
23
0x663 3 小时 12 分钟前
感觉和数据库容灾没啥关系，和你们项目的脏 SQL 关系更大。
即使做了容灾，运行这些 SQL 还是会出现问题。 |
 |
24
bellx 3 小时 7 分钟前 via iPhone
如果核心业务也涉及复杂的查询，那怎么堆配置都是没用的，根本问题解决不了，还是得老老实实优化查询。
|
 |
25
ala2008 2 小时 58 分钟前
1 、缓存肯定要加的，你说的 sql 复杂，估计查询也慢
2 、阿里云应该直接支持配置从库啊，不用自己搞 3 、sql 优化吧 |
|
26
seedhk OP @blackeeper #21 是这样的，越是不可用的时候，用户越会不断重试刷新，因为解决这类问题，不是一套工具或者一个方案能解决的。相关的熔断限流都有，现在想解决的是数据库挂了的问题；
@mangodai #22 有这个能力就不会问这个问题了 哈哈哈 @0x663 #23 根本问题就在大 SQL ，但是远水解不了近渴，得先想数据库挂了如何处理的问题 @bellx #24 核心业务少，SQL 优化耗费的时间和精力都能接受 @ala2008 #25 好像 sqlserver 不支持从库 |
 |
28
heiya 2 小时 43 分钟前
SQL 太复杂，一查几百行，表数据量又太大 导致大量的慢 sql ，是不是瓶颈在于查询而不是新增和修改？这样的话我感觉用 Redis 替代 Mysql 查询不合适，原因是即使前台没有显式的调用这些复杂 sql ，在相关业务进行新增和修改时也调用复杂 sql 同步到 Redis ；如果说不调用 sql 直接将数据存到 Redis ，那能不能确定由复杂 sql 组成的数据可以通过简单的 Redis 命令重新组成，我感觉挺困难的；还有数据量太多的话假设 Redis 挂掉，AOF 恢复是需要时间的，在这段时间内服务不可用；综上，我感觉 Redis 不合适。 解决办法根据描述我感觉：1.针对那些很复杂、数据量又特别多导致慢 sql 的表，将这数据同步到 ES 的一个索引中，组成一个大宽表，所有有关的复杂查询全走 ES 2.每次新增或修改时使用消息队列同步到 ES ，不能直接同步（或者现在有一些同步组件可以用） 3.如果有很多复杂查询但彼此不相关就需要多个索引了 4. 如果条件允许的话针对这些复杂的查询单独拆出来组成查询服务 5.分库分表还是有必要搞的，不过根据我的经验用过 Sharding 和 Mycat ，复杂的 sql 还是歇菜 6. 优化还得继续，慢 sql 报警不知道有没有 7.业务上能不能限制一下查询条件，比如起始时间什么的 8.有没有数据冷热分离的可能性？ 9.据说 PG 很强，但我没有用过，得试试
|
 |
29
z1829909 1 小时 41 分钟前 via Android
定期捞慢 sql ，然后拆分优化或者跳过。既然你们钱不够，那就靠人力解决。
不是很赞同直接引入 redis ，可以分析出慢的地方，sql 优化成本很高的时候，针对这一部分做一些缓存。sql 虽然几百行，但是多花一些时间，逐步分析，测试到位问题不大。 |
|
30
seedhk OP @ala2008 这个真迁不了 哈哈哈 工作量太大了
@heiya #28 谢谢大佬的回复，原先的方案确实不合适，我已经否了，现在在考虑新的方案，主要是解决如何避免数据库挂了，以及如果数据库挂了如何保证业务可用的问题，针对您说的这几点我概括一下，您看我说的对不对 1. 如果是将大数据量的表同步到 ES ，那如何解决关联查询的问题？ 还是说将关联查询的结果直接同步到 ES ？ 2.阿里云的 rds sqserver 好像不支持从库，只能通过 DTS 同步。 3.索引是肯定有的，但是数据量太大，优化的工作量也不小，目前同步在做； 4.将核心业务迁出来，包括代码和数据库，避免影响到核心业务。 5. 分库分表暂时没有 6. 慢 SQL ，大 SQL 的报警都有，但是优化难度很大 7. 业务上的限制条件也是有的 8. 问了阿里云客服，除了买高可用和 DTS ，没有其他方案，自己做了部分冷数据的备份，但也仅仅是备份 9. 更换数据库成本太高了，而且领导层不一定支持，我综合一下方案往上提 |
 |
33
opengps 1 小时 21 分钟前
复杂 sql 本身就是业务设计时候应该避免的
|
 |
34
Atoony 1 小时 18 分钟前
可以试试让 AI 优化 SQL ，说不定有奇效
|
|
35
seedhk OP |
|
36
blackeeper 57 分钟前
都已经确定是数据库的问题了，那就从数据库优化着手。
1,买几个虚拟机，整多个只读实例，卡死一个，不影响全局 2,优化数据库服务器的性能，换 SSD ，32G 内存太小，建议加大内存，配置数据库 cache 大小 3,排查优化慢 sql ，增加相关索引 4,把旧的数据归档，很多 sql 每次几亿的全表扫描是很消耗资源的。 |
 |
37
baibaibaibai 49 分钟前
@seedhk 查询从 es 走，落库后组织数据写 es
|
|
38
seedhk OP |
|
39
heiya 29 分钟前
@seedhk
1.这个需要你们去分析。可以将关联查询出来的数据结果集作为一个大宽表同步到 ES 的索引中，这个大宽表可能有很多字段；也可以在后端业务逻辑中将需要的条件提前准备好了直接传递给 ES （如果被 jion 的表查询很快的话）；还有一种是 ES 的索引间关联查询也可以。 2.有一个数据同步中间件 datax ，可以将 Mysql 的表数据同步到各种其他数据库。 4.我感觉是哪个工作量相对小就将哪一个迁出，目标就是避免影响到核心业务。 10.还有一种查询是各种聚合查询，针对于各种大数据量下的 count 语句，那 ClickHouse 特别合适，不过使用他是有条件的，只有写入和查询的话可以使用。 11.前端页面上点击查询一时半会返回不了就不要再发送相同请求了 整体上我感觉就是现在的 Mysql 满足不了复杂的查询业务，把整个服务拖垮了，并发量其实并不高。最要紧的是把 1 和 4 搞定，其他的 6,11 同步做。不过，这么一搞就把技术复杂度提上去了，新增了 ES 和消息。 |
|
40
seedhk OP @heiya #39 谢谢回复
1 、ES 关联查询不如数据库那么方便，如果将查询后的数据汇总到 ES ，又涉及到数据变动更新的问题，不管怎么做都很复杂 2. 我是 RDS SQLSERVER WEB 版，目前来看只支持 DTS ，其他都不支持。 |
|
41
baibaibaibai 20 分钟前
@seedhk 是的，我们是这样做的
|
 |
42
LoNeZ 19 分钟前
要么改代码, 要么加机器...
|
|
43
baibaibaibai 18 分钟前
@seedhk 根据业务复杂查询扩展 es ，单行复杂数据横向扩展进 es ，损耗一点增删改的接口效率，但是基本也忽略不计
|
|
44
adoal 9 分钟前
你那些大 SQL 是什么类型的，事务型还是分析型，如果是前者，没啥好办法，只能硬着头皮一点一点改了。后者的话，可以考虑同步到数仓里做分析，但是结果可能不会跟事务库完全实时一致。
|
|
45
seedhk OP @baibaibaibai #43 那么如果数据发生变动了，也要同步更新 ES 的数据吗，因为是查询后的数据同步到 ES ，更新逻辑也会很麻烦把？
|
|
46
adoal 7 分钟前
至于换数据库，千万不要幻想 PG 比 MSSQL 性能好……至于 MySQL 想都别想了。
|
 |
48
wxw752 几秒前
你这题我会，我们公司用到了大量各类阿里的云服务。
对于你们来说，不要动 SQL ，最好的解决方案确实是读写分离，但读不要再用 RDS 了，用 DTS 将主库的数据同步到 AnalyticDB 中，这个阿里云的数仓和 mysql 的语法完全一样，SQL 查询效率直接拉满，一行代码不改，JDBC 直接连 ADB 读就完事了。 |
Select Language