这是一个创建于 2240 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个 api 需要查询数据库 1400 多次.
想把他们捏到一个或几个 sql 里面.
这样的话可能需要连 N(5-10)张表查询.也就是说,将压力推给了数据库.这样的方式可行吗?
每个表的记录数量都不大.几千条记录.
1400 个查询,大概耗时 10 秒.
想把他们捏到一个或几个 sql 里面.
这样的话可能需要连 N(5-10)张表查询.也就是说,将压力推给了数据库.这样的方式可行吗?
每个表的记录数量都不大.几千条记录.
1400 个查询,大概耗时 10 秒.
 |
1
sujin190 2018-11-07 13:57:23 +08:00
连接断开确实开销很大，但是一般是复用连接查多次，join 需要临时表太消耗数据库 cpu 了，最好还是不要连接太多表
|
 |
2
sutra 2018-11-07 14:00:38 +08:00
所以出现了连接池技术吧。
|
 |
3
TomVista 2018-11-07 14:21:14 +08:00
完全可以,
不过我很好奇什么东西需要 1400 多次数据库查询,你确定业务没问题吗? 另外你确定你的后端 分离了数据存储服务吗? |
 |
4
no1xsyzy 2018-11-07 15:20:55 +08:00
连表一般问题不大
只要 sql 不瞎写（不需要的不取，多连也没关系，无关的话连接会自动优化消失的），不管连表还是多次查询差不了多少的，连表有消耗，传递语句和结果也有消耗，口头估算不用考虑 除非你在 sql 语句里做运算，那个不是 sql 专长 具体先 perf 再决定。也可以 explain 一下再优化点。 |
|
5
no1xsyzy 2018-11-07 15:22:32 +08:00
我不清楚能不能先 prepare 了再多次查询，那个其实效率挺好的，只做一次预处理。
甚至出现过单次查询都是 prepare 效率更高的情况 |
 |
6
luozic 2018-11-07 15:42:26 +08:00
這種數據是實時的還是可以緩存的，可以緩存的直接上緩存和更新緩存。不過你這需要查 1400 多次的，設計確定沒問題？
|
 |
7
jydeng 2018-11-07 15:54:58 +08:00
一直不断建立连接很耗费性能，连表还好。
|
 |
8
mmdsun 2018-11-07 19:22:09 +08:00 via Android
MySQL 设计是轻量级连接开销不大
|
 |
9
feverzsj 2018-11-07 19:26:16 +08:00
才这么点数据，你全都读到本地不就好了
|
Select Language