兩種做法：

1、在創(chuàng)建數(shù)組模型的時(shí)候去掉_id的選項(xiàng)。

//定義
const userChildSchema = new Schema(
    { memos: { type: String } },
    { _id: false } //子對(duì)象里去掉_id
);

const userSchema = new Schema({
    name: { type: String },
    clubnumber: { type: String },
    memo: [userChildSchema]
});

//查詢
userModel.findOne({ name: "nameeeeee" },
    { "memo": 1 },  //select
    null,
    function (err, cursor) {
        console.log(cursor.toJSON().memo)
    }
);

返回結(jié)果：

2、mongo里可以只返回匹配的數(shù)組中的記錄。

具體做法參考：mongo官網(wǎng)

注：

• 以上是本機(jī)運(yùn)行的結(jié)果。
• 使用的mongoose版本為：5.2.5
• mongo版本為：3.4

$elemMatch才是代表使用同一個(gè)數(shù)組元素同時(shí)匹配多個(gè)條件。否則可能是多個(gè)數(shù)組元素匹配不同的條件，$也就沒有意義了。

db.test.updateOne(
{
    _id: ObjectId("5ac1ff4c87c0fc67c0f4fe60"),
    workerStats: {
        $elemMatch: {
            stage: "LABEL",
            idOfWorker: "admin"
        }
    }
},
{
    $inc: {
        "workerStats.$.stats.labeledItems": 1
    }
})

那你就不要按逗號(hào)嘛，按"],"不就可以了

你用了同一個(gè)key：‘.$4’，key是標(biāo)識(shí)，不能重復(fù)

應(yīng)該是tbl_user表里沒有test這個(gè)列，但MySQL又無法知道test是你要的一個(gè)列還是別名還是什么函數(shù)，所以只能報(bào)一個(gè)籠統(tǒng)的錯(cuò)誤了。詳情參閱：

https://stackoverflow.com/que...

MyISAM引擎下會(huì)有自動(dòng)維護(hù)這個(gè)的，可以更快。

1.id 主鍵 2.user_id加索引
2.在數(shù)據(jù)表結(jié)構(gòu)優(yōu)化，增加臨時(shí)表，專門存儲(chǔ)兩個(gè)表的id，并將user. user_name,order.order_number存儲(chǔ)在臨時(shí)表內(nèi)

直接全部替換唄，何必這么麻煩。。。

或者：用第三方的唯一id來判斷

鎖是解決并發(fā)問題的經(jīng)典方案，對(duì)于簡(jiǎn)單并發(fā)問題，使用鎖就可以了。但對(duì)于事務(wù)這種復(fù)雜問題，光有鎖是不行的，比如兩個(gè)事務(wù)，他們是否能看到對(duì)方修改的數(shù)據(jù)，是否需要確保一個(gè)事務(wù)內(nèi)的讀是可重復(fù)的，這些問題的不同解決方案都會(huì)影響復(fù)雜應(yīng)用在并發(fā)時(shí)的邏輯和執(zhí)行結(jié)果，稍不注意就會(huì)導(dǎo)致錯(cuò)誤的結(jié)果，所以引入了隔離級(jí)別這個(gè)概念來對(duì)事務(wù)的隔離性進(jìn)行規(guī)范，也就是說隔離級(jí)別實(shí)際上是應(yīng)對(duì)事務(wù)這個(gè)復(fù)雜問題而引入的，如果僅有并發(fā)而沒有事務(wù)就無所謂的隔離級(jí)別了。

簡(jiǎn)單的說，鎖是并發(fā)控制的基礎(chǔ)，隔離級(jí)別是更高層次上的應(yīng)對(duì)事務(wù)的整體解決方案。

就那串?dāng)?shù)據(jù)插入到一個(gè)臨時(shí)表中，然后執(zhí)行 inner join操作來查詢

不是union all的問題吧。
sql語句最后有g(shù)roup by語句， 相同的studyCenterName,grade只保留一條，去掉看是否你想要的結(jié)果。

另外，這個(gè)sql的寫法，使用group by之后，在select語句中非group by的字段沒用聚合函數(shù)，在myslq高版本或其他數(shù)據(jù)庫會(huì)報(bào)錯(cuò)的。

一樣有隊(duì)列，但是WiredTiger的鎖是文檔級(jí)的，所以只有當(dāng)請(qǐng)求嘗試更新同一個(gè)文檔的時(shí)候，才會(huì)有實(shí)際的“鎖”存在。其余時(shí)候都是盡可能快地寫入數(shù)據(jù)庫。一般情況下除非硬件限制，隊(duì)列都不可能太長，經(jīng)驗(yàn)值來看大部分情況下都在10以內(nèi)。所以WT內(nèi)部只有128個(gè)讀和128個(gè)寫的Ticket，只有拿到Ticket的請(qǐng)求才有可能進(jìn)行讀寫。

如果catalog 里有id=1,2,3,4的, GROUP_CONCAT(id)返回 '1,2,3,4',
CONCAT_WS(',',10,GROUP_CONCAT(id))將返回 '10,1,2,3,4',注意這里都是帶引號(hào)的,意味著這是字符串

相當(dāng)于是

select * from article  where article.catalog_id IN (
    '10,1,2,3,4'
);

顯示這里引號(hào)起了副作用

改成這個(gè)試試?

select * from article  where article.catalog_id IN (
select 10 union
select id from catalog where catalog.top_id=10
);

因?yàn)椴皇呛芮宄愕谋斫Y(jié)構(gòu)和數(shù)據(jù), 也許這并不是你想要的 ;)

我的是這樣 通過mysql命令行或者管理工具可以連接，但是通過啟動(dòng)java項(xiàng)目就連接報(bào)錯(cuò)(如圖) 額，什么 鬼呢？

1.不建議使用中文
2.使用trim()函數(shù)清楚$_SESSION['usr_name']內(nèi)容是否存在留空情況

假設(shè)他們之間有外鍵外鏈可以用連接查詢
select a.C1,b.C2,c.C3 form B1 as a join B2 b on a.id=b.aid join B3 c on c.id=a.cid

你理解的左連接是錯(cuò)誤的，左連接是會(huì)匹配所有滿足條件的數(shù)據(jù)，如果 trd_goods 中有記錄在 trd_goods_tag_relation 匹配不到數(shù)據(jù)還是會(huì)產(chǎn)生一條記錄，只不過查詢中 trd_goods_tag_relation 中的字段是 null， 這就是以左邊的表為主。

綜合考慮效率和難易程度，我覺得你這樣寫法沒有問題，除此之外我也沒有想出來特別好的替代方案。不知道你說的『更簡(jiǎn)潔』的寫法是不是aggregation中g(shù)roup+$push的寫法。如果是的話那樣的寫法不如現(xiàn)在的效率好，并且有返回結(jié)果過大時(shí)異常的可能性。
不過有些額外的問題我想說明一下。即使是一批更新的數(shù)據(jù)，timestamp不見得一樣吧；或者說不是一批更新的文檔timestamp不見得不一樣。要區(qū)分『一批更新』這個(gè)概念，同一批更新的文檔必須要有一個(gè)唯一的『批次號(hào)』，可以是ObjectId或是GUID。建議ObjectId，它比較短所以性能略好。

你還有一個(gè)最關(guān)鍵的問題：
<a href="aa.bb.com">cc.dd.com</a>你準(zhǔn)備咋去替換？

得具體需求具體分析。

你好，一般來說正常的項(xiàng)目都是使用xml，維護(hù)起來方便，對(duì)于性能的話，應(yīng)該使用xml的形式或比注解sql后，因?yàn)楣俜揭彩峭扑]使用xml，且注解方式拼接動(dòng)態(tài) sql 功能有限，對(duì)于項(xiàng)目而言，sql與java（項(xiàng)目主編程語言）應(yīng)該區(qū)分開來，不要混合在一起，且拼接sql易爆炸·····，xml是我比較支持與推薦的，對(duì)于后期維護(hù)還有升級(jí)版本而言，不過簡(jiǎn)單輕松的項(xiàng)目也可以用sql來完成。