c#中sql查詢?yōu)槭裁疵看蔚谝淮尾樵儠?huì)慢。第二次以后都會(huì)快？根連接無關(guān)緊要，因?yàn)榉?wù)器第二次有了緩存。向服務(wù)器添加1000萬條數(shù)據(jù)，停止并重新打開數(shù)據(jù)庫。查詢時(shí)，內(nèi)存不斷增加。這是第一次讀取，這是讀取

c#中sql查詢?yōu)槭裁疵看蔚谝淮尾樵儠?huì)慢。第二次以后都會(huì)快？

根連接無關(guān)緊要，因?yàn)榉?wù)器第二次有了緩存。向服務(wù)器添加1000萬條數(shù)據(jù)，停止并重新打開數(shù)據(jù)庫。查詢時(shí)，內(nèi)存不斷增加。這是第一次讀取，這是讀取IO到內(nèi)存的速度。第二次查詢時(shí)，內(nèi)存不再增加。第一次可能需要10分鐘，第二次只需要2秒鐘。這是因?yàn)閿?shù)據(jù)庫緩存。

如果是MS SQLSEVER，則在查詢前添加一句話“set statistics io on”，第二次將不進(jìn)行預(yù)讀取，即io讀取。這時(shí)，再插入1000行，發(fā)現(xiàn)有好幾次預(yù)讀。這些時(shí)間只是剛剛加上的臺詞。只有這些行需要從硬盤中讀取，其他內(nèi)存也可以讀取。內(nèi)存讀取比磁盤讀取快n倍。

如果平均一個(gè)頁面數(shù)據(jù)庫要執(zhí)行200次查詢，這個(gè)數(shù)量級有問題嗎？有一個(gè)合理的閾值嗎？

其實(shí)最理想的情況是盡量少與數(shù)據(jù)庫交互，因?yàn)閿?shù)據(jù)庫提供的功能是數(shù)據(jù)的存儲(chǔ)和檢索，所以我們有很多方法將常用的數(shù)據(jù)緩存在內(nèi)存中，這樣可以大大提高性能，減少傳輸。

還有另外一個(gè)考慮因素。200次數(shù)據(jù)庫檢索，例如，如果一次檢索1KB的數(shù)據(jù)，200次就是200KB，100人就是20MB。這顯然不合適。這只是訪問一個(gè)頁面

你必須一次檢索這些數(shù)據(jù)嗎？不是異步的？騰訊微博主頁調(diào)用了大量數(shù)據(jù)，但反應(yīng)迅速。最重要的是按主次異步加載內(nèi)容，按需加載

如果這200個(gè)查詢不能拆分，只能說你的系統(tǒng)耦合度太高了，必須改變架構(gòu)，耦合度太強(qiáng)了，這是不好的