在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

鍍金池/ 問答/ 數(shù)據(jù)庫問答
瘋子范 回答

你查詢的這行不存在吧，怎么會拖慢查詢呢。const 應該很快

過客 回答

時區(qū)問題，正好差8小時，參考https://www.cnblogs.com/wajik...

心癌 回答

Unknown column 'ys170606100349' in 'where clause' 他都說不識別的ys170606100349是不是ys這個的緣故
你打印sql看看能不能運行

六扇門 回答

所有的字段在取值的時候都做容錯處理啊

var a = obj.b || ''
初念 回答

&&左邊會隱式轉(zhuǎn)換為boolean

function verify() {
    return 123
}

let result = verify && verify();// -> true && verify() -> verify() -> 123
雨萌萌 回答
  1. 可以先通過bash命令mongoexport把mongo里的數(shù)據(jù)導出成文件，然后通過讀取文件內(nèi)容來處理
  2. data = list(col.find({'id': {"$in": nodes}})) 直接加載到內(nèi)存試一下？id字段加索引了吧？
舊言 回答

我也碰到類似的警告。 說是某某函數(shù)被棄用。 有些是可以忽略的。

淚染裳 回答

你這樣關聯(lián)字段來判斷是否已讀消息不科學啊，后期數(shù)據(jù)量大起來的話很難受的

一般都是消息表有個狀態(tài)字段來區(qū)分它們，比如：

—————————————————————————————————————————
| Id | 編號 |
—————————————————————————————————————————
| State | 消息狀態(tài)：1 未讀 2 已讀 |
—————————————————————————————————————————

關聯(lián)還是 messageId 與 消息表 Id 關聯(lián)

但查詢未讀消息的話就這樣

SELECT * FROM [message] WHERE State=1

豈不美哉?。?！

尐懶貓 回答

下次記得把原始查詢也發(fā)出來，我們看著更方便些。從執(zhí)行計劃來反推，查詢大約是

db.webDevice.find({
    lid: {
        $in: [
            "40CnwyHkVmnA9kbScMLNLneaxuS4Tcj",
            "140CnwyHkVmnA9kbScMLNLneaxuS4Tcj"
        ]
    }
}).sort({createTime: -1}).limit(1);

因為命中索引，這個查詢獲取數(shù)據(jù)的速度實際上比較快，你也提到在一段時間內(nèi)第二次查詢就快了，這是一個很明顯的特點，代表內(nèi)存不足。MongoDB和其他數(shù)據(jù)庫一樣，都會使用空閑內(nèi)存緩沖索引和數(shù)據(jù)，當內(nèi)存不足時就會使用LRU算法清理舊數(shù)據(jù)換入新數(shù)據(jù)再繼續(xù)查詢。因為這個過程涉及到磁盤數(shù)據(jù)交換，速度會大大降低。發(fā)生這種情況有一個特點，就是一段時間內(nèi)第二次執(zhí)行時速度就快了（因為數(shù)據(jù)已經(jīng)在內(nèi)存中）。但是如果過一段時間再執(zhí)行，速度又會變慢（因為又被換出內(nèi)存了）。所以你的情況實際上就是受限于硬件。
既然如此最直接的解決辦法就是：

  1. 使用更快的硬盤；
  2. 使用更大的內(nèi)存；

如果不能從硬件方面解決，有一點可以嘗試就是用CPU換內(nèi)存。做法是盡可能調(diào)小cacheSizeGB（是的沒錯，是調(diào)?。??？臻e出來的內(nèi)存操作系統(tǒng)會用來緩沖磁盤數(shù)據(jù)，而磁盤數(shù)據(jù)是經(jīng)過壓縮的，體積更小，因此可以緩沖更多數(shù)據(jù)到內(nèi)存中。但作為交換，在使用這些數(shù)據(jù)時需要經(jīng)過CPU再進行一次解壓從而額外消耗CPU。即使這樣，效果也比從磁盤讀取要好很多。整個過程是自動進行的，你需要做的只是調(diào)小cacheSizeGB。
這種做法可以在一定程度上緩解內(nèi)存不足的問題，但不是萬能的：

  • 首先它會增加CPU消耗，如果你的系統(tǒng)本身已經(jīng)沒有剩余的CPU資源，這種做法就不合適；
  • 其次受制于壓縮率，這樣做之后內(nèi)存能容納的數(shù)據(jù)并不會比以前多很多，所以并不是萬能的；

補充回答

基于你的新的疑問，以下幾點補充：

疑問1: 按照你說的方式調(diào)小cacheSizeGB,應該怎么調(diào)整比較合理

我在上面有提到，這樣做的效果有限，是受制于壓縮率的限制。所以多容納的數(shù)據(jù)實際就是壓縮的數(shù)據(jù)。比如1G的內(nèi)存能放多少數(shù)據(jù)？

  • 如果不壓縮（壓縮率100%），1G內(nèi)存能放1GB數(shù)據(jù)；
  • 如果壓縮率90%，1G內(nèi)存可以放10/9GB~=1.11數(shù)據(jù)；
  • 如果壓縮率80%，1G內(nèi)存可以放10/8 = 1.25GB數(shù)據(jù)；
  • 以此類推……

所以調(diào)到多少，其實要看你想往內(nèi)存里放多少數(shù)據(jù)，而這往往是一個不確定的數(shù)值。這里會有另外一個概念叫做工作集（working set），就是你經(jīng)常用到的那些數(shù)據(jù)。比如你的數(shù)據(jù)庫共有100GB數(shù)據(jù)，但是你經(jīng)常用到的部分只有10GB，那么你的內(nèi)存只要能裝下10GB數(shù)據(jù)，應用在大部分時候就可以非?？?，剩下的情況忽略就好了。
基于上面這些分析，你應該可以算一下，你的工作集有多大，數(shù)據(jù)壓縮率有多大，那么需要把cacheSizeGB調(diào)到多小才能容納下工作集（又或者調(diào)到多小都不可能容納下工作集）。你的情況是內(nèi)存不足CPU空閑，所以如果懶得算，直接把cacheSizeGB調(diào)到最小值就好了。

疑問2: config只用了1.5GB內(nèi)存(限制了CacheSizeGB3GB).可以說明索引都加載到了內(nèi)存中嗎?

這說明config數(shù)據(jù)庫（元數(shù)據(jù)）的索引和數(shù)據(jù)都加載到內(nèi)存中了。注意數(shù)據(jù)的索引肯定是在shard中，與config無關。而且大頭是在shard上面。
順便提一下，如果不是實驗目的，根本沒必要分這么多片。因為在一臺機器上分再多片，硬件資源也只有這么多，對于性能沒有什么意義，反而還會有額外的傳輸開銷。

疑問3: mongodb remove數(shù)據(jù)后,查詢卻越來越慢是什么情況?

remove之后跟查詢沒有本質(zhì)上的聯(lián)系，可能只是湊巧發(fā)生在一起。如果你有足夠的證據(jù)覺得這兩者確實有聯(lián)系，請另開問題描述清楚問題的上下文以及你發(fā)現(xiàn)的情況，必要的時候也可以求助于MongoDB JIRA。如果一定要做一個無根據(jù)的猜測，我覺得可能是remove時導致熱數(shù)據(jù)被換出內(nèi)存（注意remove也需要先找到滿足條件的數(shù)據(jù)然后才能刪除），引起后面的查詢需要重新從磁盤上加載數(shù)據(jù)造成的。

陌離殤 回答

1.在ubuntu系統(tǒng)中新建一個文件夾,然后將代碼拉下來,編譯打包后正常(公司測試服務器);
2.在后臺同事的電腦上(ubuntu16.0.4)執(zhí)行打包命令,也沒有問題,
所以初步結(jié)論就是公司測試服務器出了問題!
所以暫時的解決方法就是更改打包的文件夾

遺莣 回答

max_allowed_packet的值太小了，所以被 mysql 拒絕了。

show global variables like 'max_allowed_packet';

然后設置一個適合的值就好了

set global max_allowed_packet=xxxxx;

這個設置是一次性的，重啟就沒了，所以不用擔心。

要永久生效的話，得改配置文件my.cnf

乖乖瀦 回答

測試發(fā)現(xiàn)，SET SQL_MODE=ANSI_QUOTES 并不是影響sql的最終原因。而是原始sql語句中不能使用雙引號來引字符串。
應該用單引號'，如果單號不能使用就用帶轉(zhuǎn)義符的\'。

萌吟 回答

--sqlserver親測有效

--語句簡單優(yōu)雅卻又不失功能

--就是性能上可能有些不足


SELECT [subject].Id,COUNT([course].Id) AS course_count,

                    COUNT([book].Id)   AS book_count

FROM [subject],[course],[book]

WHERE [course].Uid=[subject].Id AND [book].Uid=[subject].Id

GROUP BY [subject].Id
替身 回答 
populate('replies.user')

自問自答了，是自己傻逼一直以為populate('replies.user')不起作用是這樣寫不對，后來發(fā)現(xiàn)是數(shù)據(jù)庫字段名沒對應

敢試 回答

h1表沒有使用到索引索引,所以type類型是index(全索引掃描)

帥到炸 回答

結(jié)論

  1. 需要存儲到緩存/數(shù)據(jù)庫。
  2. 設置cookie有效期為T1，緩存存儲時長為T2，兩者沒有硬性直接關聯(lián)。但理論上 T1 必須 <= T2。

問題一：還是說必須要將session保存到緩存或數(shù)據(jù)庫中？

答：建議存儲到緩存中去，避免服務重啟后會話全部失效。如果緩存服務不支持持久化，那么還需要落地到本地數(shù)據(jù)庫。

問題二：如果將保存session_id的cookie設置很長的有效期，那么服務器端的session是否也會保存很長時間？

答：不會，兩者沒有硬性關聯(lián)。
答：這里需要關注cookie的有效期T1、session的有效期T2、session的存儲期T3。正常來說，T1 <= T2 <= T3。
很多時候session失效后，session對應的數(shù)據(jù)還是在數(shù)據(jù)庫里待著，只是標識為失效而已。根據(jù)實際情況，可能會有定期清理數(shù)據(jù)庫的動作。

無標題 回答 
#確保你的teacher_class表有unique index(teacherId, classId)
SELECT teacherId,COUNT(1) FROM teacher_class 
WHERE classId IN(1,2,3)
GROUP BY teacherId
HAVING COUNT(1)=3
脾氣硬 回答

ulimit -n 已經(jīng)修改了，并且也生效了。最有我修改了service文件，總連接數(shù)就正常了：

[unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual

[Service]
User=root
Group=root
Environment="OPTIONS=-f /etc/mongod/mongos.conf"
ExecStart=/usr/bin/mongos $OPTIONS --maxConns 10000
ExecStartPre=/usr/bin/mkdir -p /var/run/mongodb
ExecStartPre=/usr/bin/chown mongod:mongod /var/run/mongodb
ExecStartPre=/usr/bin/chmod 0755 /var/run/mongodb
PermissionsStartOnly=true
PIDFile=/var/run/mongodb/mongos/mongod.pid

# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false
# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings

[Install]
WantedBy=multi-user.target
首頁 上一頁 10 11 12 13 14 15 16 17 18 下一頁 尾頁