鍍金池/ 問(wèn)答/ 數(shù)據(jù)庫(kù)問(wèn)答
呆萌傻 回答

select result := count(*) from tree where ...

尤禮 回答
  1. 檢查密碼中是不是有特殊符號(hào)，比如@，:之類的
  2. 從堆棧中看用的是SCRAM-SHA-1認(rèn)證，檢查一下你的賬號(hào)是不是MONGODB-CR：
use admin
db.system.users.find()
赱丅呿 回答

描述得不是很明白，不過(guò)看了下你的 sql 中并沒(méi)有存在mysql 中的去重 distinct 或者 group by 操作，如果你是不知道這兩個(gè)方法，可以自行了解下。這個(gè)應(yīng)該能滿足你說(shuō)的，不同 store_id 。
當(dāng)然，也可能你是其它需求，這樣的話，你可能需要描述得更清楚些，才能讓大家能對(duì)你提供有效的建議。

雨蝶 回答

很遺憾的是EF CORE并沒(méi)有官方的Oracle支持，Oracle自己在做官方的Oracle Provider,但是還沒(méi)有完成。
EF CORE具體的支持情況可以看微軟的官方說(shuō)明。

離夢(mèng) 回答 
for(int i = 0; i < n; i++) {
  if(a[i] == x) {
    cout << i << endl;
    break;              // 這里break了，下面的flag=true不會(huì)被執(zhí)行到
    flag = true;
  }
}
萌二代 回答

如果沒(méi)用多線程、定時(shí)器等技術(shù)，調(diào)用jdbc也是順序一個(gè)一個(gè)執(zhí)行的。

菊外人 回答

let asyncFn = (item) => {
return new Promise((resolve, reject) => {

setTimeout(() => {console.log(item); resolve(true)}, 0)

})
}

let a = ['a','b','c','d']

a.reduce((previous, current, index, array) => {
return previous
.then(()=>{return asyncFn(array[index])})
}, Promise.resolve())

情殺 回答

找到原因了，是因?yàn)樵陬^文件里面加上了
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />
自動(dòng)將http的不安全請(qǐng)求升級(jí)為https,所以請(qǐng)求全都變成https了

撥弦 回答

對(duì)于1，可能有安全問(wèn)題，但怎么處理要具體分析，過(guò)濾也不好處理?？赡苄枰~外的手段讓富文本部分僅僅是顯示，而不會(huì)有太多執(zhí)行的部分。

離魂曲 回答

distinct 去重返回一個(gè)數(shù)組，length 獲取長(zhǎng)度。
distinct 第一個(gè)參數(shù)是去重字段，第二個(gè)參數(shù)是篩選條件。

db.collectionName.distinct('trnrec.stunum', {"trnrec.rttype":0,"trnrec.createtime":{ $gte: ISODate("2017-11-23T00:00:00+0800"),  $lt: ISODate("2017-11-24T00:00:00+0800")}}).length

soonfy

旖襯 回答

appkey估計(jì)是寫死的，你多試幾個(gè)就知道了

sign估計(jì)是前端js加密的，建議單步調(diào)試找加密方法

孤酒 回答

這個(gè)叫SPA，主要依賴html5 history API，和PHP（與其他后端技術(shù)）幾無(wú)關(guān)系。

孤星 回答

你畫(huà)出的是一個(gè)json數(shù)組，每個(gè)json的key都相同，那就直接去掉key就行了啊。
原來(lái)是[{k1:v1},{k1:v2},{k1:v3},...]
直接改成 [v1, v2, v3, ...]

入她眼 回答

spring task在深夜業(yè)務(wù)不繁忙的時(shí)候，異步任務(wù)弄?？梢宰雒咳赵隽扛?/p>

朽鹿 回答

你的b表不太完善，因?yàn)樵u(píng)論還有對(duì)應(yīng)的回復(fù)評(píng)論，所以b表應(yīng)該還有個(gè)parent_id，默認(rèn)是0，就是直接評(píng)論的，如果有parent_id,則是回復(fù)評(píng)論。

嘟尛嘴 回答

就第二張截圖來(lái)看webpack是把依賴的字體文件用base64編碼插入到main.js里了，可以考慮在配置里排除掉這個(gè)字體的依賴

憶往昔 回答

not exists效率本來(lái)就不高啊...

暫時(shí)先不考慮數(shù)據(jù)庫(kù)自動(dòng)進(jìn)行的編譯優(yōu)化這點(diǎn)，假設(shè)兩個(gè)實(shí)現(xiàn)用最樸素的實(shí)現(xiàn)方式

not exists本質(zhì)上就是循環(huán)執(zhí)行doctor數(shù)據(jù)量次數(shù)的select 1 xxx語(yǔ)句，篩選出執(zhí)行查詢沒(méi)有結(jié)果的數(shù)據(jù)，在這里就是30w或者20w次的select，即便都有索引select起來(lái)很快也架不住循環(huán)次數(shù)多啊

not in一般是先把in里的語(yǔ)句查出來(lái)，然后對(duì)結(jié)果和doctor做一個(gè)join關(guān)聯(lián)出匹配的上（in）或者匹配不上（not in）的數(shù)據(jù)，就算沒(méi)有優(yōu)化查詢次數(shù)也依然比not exists少很多

而且如果not in的子查詢有建索引，還可以直接自動(dòng)優(yōu)化成一個(gè)join語(yǔ)句做兩張表的關(guān)聯(lián)以進(jìn)行索引之間的對(duì)比，也不用先把select子查詢計(jì)算出來(lái)再對(duì)比，類似
select count(*) from docker d,doctor_intro di where d.did = di.did and d.did is not null and di.did is null(sql隨便寫的，也沒(méi)實(shí)際執(zhí)行，可能是錯(cuò)誤的，大概可以理解意思就行)
這樣一來(lái)的話速度就更快了，因?yàn)閳?zhí)行時(shí)可以直接對(duì)比索引文件里的數(shù)據(jù)是否關(guān)聯(lián)的上，把關(guān)聯(lián)不上的數(shù)量取出來(lái)就完成了，可以省略掉先查出 SELECT did FROM doctor_intro 這步了

具體上mysql我目前很少用，內(nèi)部做了哪些優(yōu)化也不清楚，我上面說(shuō)的是建立在沒(méi)有優(yōu)化的基礎(chǔ)上，實(shí)際上涉及到sql編譯優(yōu)化后問(wèn)題就復(fù)雜了很多，我目前也是還沒(méi)學(xué)完屬于基本不懂的狀態(tài)，這方面就不多說(shuō)什么了

首頁(yè) 上一頁(yè) 49 50 51 52 53 54 55 56 57 下一頁(yè) 尾頁(yè)