已经没分了，大家救命啊，多个线程同时更新数据库的问题，我只建立了一个可以访问数据库的实例，而且更新数据库的函数页设置为了同步，还是会发生死锁的问题，好烦啊，救命啊！！！！！！！！！！！！！！

ahtu 2002-01-06 12:36:17

...全文

75 3 打赏收藏转发到动态举报

写回复

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

0legend 2002-01-06

打赏
举报

回复

光同步不行，当两个以上的线程在同步执行时，需要互相打开--死锁，快去找找
"以全局的固定顺序获取多个锁来避免死锁" (查找相关网页)

ahtu 2002-01-06

打赏
举报

回复

但是我已经设置了是同步访问的啊，怎么办啊

0legend 2002-01-06

打赏
举报

回复

一个实例也是同时访问的啊，只有改数据库的访问了

蛋痛的东东，一个都不会啊看不懂啊，求救命！！！

比如，一个线程在修改数据，另一个线程在读同一条数据，数据库为了保证数据一致性，就得加锁。这就是所谓的“资源争夺死循环”：连接多了，资源分配不够，系统变慢，更多请求涌入，最终全盘崩溃。设置合理的最大连接数，避免资源争夺。今天，老韩就来掰扯清楚，为什么一个简单的数据库连接，会这么消耗资源。别觉得这是“技术活”，听完你会发现，这些道理不仅适用于代码，还适用于人生。优化你的 SQL 语句，避免全表扫描，添加必要的索引，减少不必要的查询次数，能显著提升效率。实际情况是，连接多了，数据库根本忙不过来，结果反而更差。

举个例子，假如某个查询功能需要3秒时间，串行查询的时候并没什么问题，我们继续假设这功能每秒大概QPS为100，那么在第一次查询结果返回之前，接下来的所有查询都应该穿透到数据库，也就意味着这几秒时间有300个请求到数据库，如果这个时候数据库CPU达到了100%，那么接下来的所有查询都会超时，也就是无法有第一个查询结果缓存起来，从而还是形成了缓存击穿。对于一些旧的项目来说，某些业务的数据入口非常多，无法完整清晰的梳理清楚，这个时候CDC就是一种非常好的方式，只要从最底层数据库层面把变更记录取到就可。

正文毫不夸张地说，咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方**，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱们日常遇到的80%-90%的性能问题。从解决问题的角度出发，我们得先了解到问题的原因；其次我们得有一套思考、判断问题的流程方式，让我们合理的站在哪个层面选择方案；最后从众多的方案里面选择一个适合的方案进行解决问题，找到一个合适的方案的前提，是我们自己对各种方案之间的优缺点、场景有足够

大家好，我是路人~毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱么日常遇到的80%甚至90%的性能问题。从解决问题的角度出发，我们得先了解到问题的原因；其次我们得有一套思考、判断问题的流程方式，让我们合理的站在哪个层面选择方案；最后...

23,407

社区成员

70,513

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章