寫成goods就行，或者mongoose.model('good', xxxSchema, 'good')，

這兩個(gè)瀏覽器偏偏就是解決不了的
可以去msdn查看新的media接口

簡單地說，不能命中任何索引的查詢需要進(jìn)行全表掃描，這個(gè)過程當(dāng)然是很慢的。你需要添加合適的索引。

select * from TBL where 字段 in (select 語句結(jié)果集)

從你代碼來看， 在構(gòu)造函數(shù)中是獲取不到li的寬度的，因?yàn)樵跇?gòu)造函數(shù)中 你只做了把li插入到ul中 而ul并沒有插入到DOM中，故 li也就沒有插入到DOM中 所以你獲取不到，考慮換個(gè)思路 實(shí)現(xiàn)你的需求。

INSERT INTO dede_addonarticle VALUES (12345,3,"This is the content","http://url.com","xxx","yyy")

慢慢拼吧，建議活用str.format語句。

await query.exec(function (err, users) {
        if (!err) {
            res = users
            // console.log(res) // 這里可以打印出數(shù)據(jù)
        }
    })

你這里要寫成 同步方式 而不是 異步語法

select a_v+b_v+c_v+...
from (select 
        case when a is null then 1 else 0 end a_v,
        case when b is null then 1 else 0 end b_v,
        ...
      from table
      where ...) aa;

這樣看的話也暫時(shí)看不出啥問題，至少語句是沒有問題的。那么你說一直沒有更新成功，那么你是否先去看一下你的數(shù)據(jù)是否和你現(xiàn)在更新的一模一樣，如果你的一模一樣，這樣的話，影響行是不會(huì)變動(dòng)的。

The downside to locking the tables is that no session can update a READ-locked table (including the one holding the lock) and no session can access a WRITE-locked table other than the one holding the lock.

醉了。。。你咋老邀請我，，翻文檔看看吧
https://dev.mysql.com/doc/ref...

1。小程序后臺可以用mongo。
2。小程序和html一樣，前后端分離，后臺不管你是aps還是php還是java還是node。小程序只會(huì)關(guān)心你后臺返回的數(shù)據(jù)。
3。小程序只支持https域名。
4。小程序要本地調(diào)試。只需要在本地hosts解析[你修改后的Request URL]

裝了閹割版或者其它精簡版的了，換一個(gè)就好了，建議裝個(gè)2008 R2

一個(gè)游標(biāo)只能執(zhí)行一個(gè)SQL，把cursor = conn.cursor()放入循環(huán)就可以了

你把最后執(zhí)行的sql打印出來看看。

已解決，原始id也要加上去

我覺得樓上的兩種做法欠妥，因?yàn)?code>count的實(shí)現(xiàn)是這樣的

> db.tasks.count
function ( x ){
    return this.find( x ).count();
}

這是在mongodb的cli里面輸出的。
一句話概述就是count其實(shí)還是調(diào)用的find。
所以這種查兩次數(shù)據(jù)庫的方法我認(rèn)為是欠妥的。

思維死角了...
一直糾結(jié)數(shù)據(jù)庫該怎么操作,其實(shí)可以在程序中對兩個(gè)字段的值進(jìn)行hash操作,然后把這個(gè)hash過的值設(shè)置在數(shù)據(jù)庫中設(shè)置為唯一,這樣就解決了問題...

題外話，MongoDB歷史上出現(xiàn)過master/slave復(fù)制（其實(shí)現(xiàn)在也還存在）。嚴(yán)格地說，主備通常指的是那個(gè)東西。而我們現(xiàn)在用的基本上是復(fù)制集（replica set）。

再說你這種情況，其實(shí)是正常的。原理跟你的磁盤用久了會(huì)有碎片是一個(gè)道理。特別是你曾經(jīng)大規(guī)模刪除過數(shù)據(jù)的情況下。簡單地解釋下，假設(shè)你的表中有doc1/doc2/doc3/doc4一共4個(gè)文檔，在磁盤上的存儲(chǔ)順序是：
doc1|doc2|doc3|doc4
現(xiàn)在你刪除了doc2，磁盤上的空間使用情況變成：
doc1|(空白)|doc3|doc4
系統(tǒng)是沒有辦法釋放這個(gè)空白空間的，除非你進(jìn)行磁盤整理，把空白空間移到最后：
doc1|doc3|doc4|(空白)
然后系統(tǒng)才可以截?cái)辔募膊康目瞻祝尫诺暨@個(gè)空間。可以看出來，要把空白移動(dòng)到文件尾是個(gè)相當(dāng)費(fèi)時(shí)費(fèi)力的操作，最簡單的辦法是：把后面所有的文檔順序前移來填補(bǔ)doc2留下的空白（如上所示doc3/doc4被前移）。但是這樣涉及到大量的磁盤I/O，會(huì)對性能造成嚴(yán)重影響。當(dāng)然不乏其他整理磁盤碎片的方法，但是無論哪一個(gè)，都會(huì)造成比較嚴(yán)重的I/O影響，因此一般我們是不會(huì)進(jìn)行這樣的整理的。進(jìn)行碎片整理的方式就是：compact命令。如前所述，因?yàn)樗鼤?huì)對性能造成嚴(yán)重的影響，因此一般只會(huì)在維護(hù)時(shí)間進(jìn)行這個(gè)操作。而就算你不進(jìn)行這個(gè)操作，系統(tǒng)也知道哪些地方是空白的，在有新文檔進(jìn)來的時(shí)候，會(huì)嘗試重新使用這些空白的部分從而最大化空間利用率。只是，無論再好的算法，空間重復(fù)利用一定不可能是100%的，因?yàn)樾逻M(jìn)來的文檔永遠(yuǎn)沒有辦法正好跟之前被刪除的文檔一樣大，所以只能找一個(gè)比新文檔更大的空間來利用，這樣就會(huì)留下一個(gè)更小的、更難重復(fù)利用的碎片。
另外一種變通的方案是把節(jié)點(diǎn)內(nèi)容刪除，重新進(jìn)行一次同步。因?yàn)橥綍r(shí)相當(dāng)于把所有文檔全部抓取一遍，并一個(gè)接一個(gè)重新寫到磁盤上，因此同步完成之后文檔在磁盤上是緊湊排列的，相當(dāng)于進(jìn)行了碎片整理。而且在這個(gè)過程中，受影響的是從節(jié)點(diǎn)，它在同步過程中并不對外提供服務(wù)，所以對線上的影響是最小的。但是注意，它同樣會(huì)對主節(jié)點(diǎn)造成影響，因?yàn)樗阎鞴?jié)點(diǎn)上的全部數(shù)據(jù)都讀一遍，主節(jié)點(diǎn)I/O升高是無法避免的。

最后回到你的問題，為什么從節(jié)點(diǎn)比主節(jié)點(diǎn)小，上面應(yīng)該已經(jīng)解釋清楚了。

沒學(xué)過

salt只是用來防止 字典攻擊