 |
1
sujin190 Nov 7, 2018
连接断开确实开销很大，但是一般是复用连接查多次，join 需要临时表太消耗数据库 cpu 了，最好还是不要连接太多表
|
 |
2
sutra Nov 7, 2018
所以出现了连接池技术吧。
|
 |
3
TomVista Nov 7, 2018
完全可以,
不过我很好奇什么东西需要 1400 多次数据库查询,你确定业务没问题吗? 另外你确定你的后端 分离了数据存储服务吗? |
 |
4
no1xsyzy Nov 7, 2018
连表一般问题不大
只要 sql 不瞎写（不需要的不取，多连也没关系，无关的话连接会自动优化消失的），不管连表还是多次查询差不了多少的，连表有消耗，传递语句和结果也有消耗，口头估算不用考虑 除非你在 sql 语句里做运算，那个不是 sql 专长 具体先 perf 再决定。也可以 explain 一下再优化点。 |
|
5
no1xsyzy Nov 7, 2018
我不清楚能不能先 prepare 了再多次查询，那个其实效率挺好的，只做一次预处理。
甚至出现过单次查询都是 prepare 效率更高的情况 |
 |
6
luozic Nov 7, 2018
這種數據是實時的還是可以緩存的，可以緩存的直接上緩存和更新緩存。不過你這需要查 1400 多次的，設計確定沒問題？
|
 |
7
jydeng Nov 7, 2018
一直不断建立连接很耗费性能，连表还好。
|
 |
8
mmdsun Nov 7, 2018 via Android
MySQL 设计是轻量级连接开销不大
|
 |
9
feverzsj Nov 7, 2018
才这么点数据，你全都读到本地不就好了
|
Select Language