肯定是落地于 db，不然 如何持久化。那是你rmb 換來(lái)的啊，存在內(nèi)存中電腦斷電不就好玩了
只不過(guò) 充值啊，消耗積分這些不一定在你每次 操作之后 就存儲(chǔ) 在 DB 中
可能利用其他技術(shù) 延遲放入 數(shù)據(jù)庫(kù)中，只要保證 數(shù)據(jù)庫(kù)最終一致性 就可以了

MySQL的索引主要指的是BTree索引，需要遵循最左前綴原則，常規(guī)的做法會(huì)根據(jù)select語(yǔ)句對(duì)索引進(jìn)行定制，像這種后臺(tái)管理的場(chǎng)景，sql基本是拼接的，可以說(shuō)沒(méi)有固定索引，這種情況，可以使用以下方案進(jìn)行優(yōu)化：

1. 暫時(shí)不建索引，把MySQL的慢查詢打開，對(duì)系統(tǒng)中的慢查詢進(jìn)行統(tǒng)計(jì)分析，然后有針對(duì)性的進(jìn)行索引優(yōu)化
2. 使用MySQL主從架構(gòu)，在從庫(kù)上進(jìn)行查詢，系統(tǒng)會(huì)慢，但保證不對(duì)主庫(kù)造成影響
3. 放棄MySQL，使用搜索引擎技術(shù)，及基于lucene的Solr或es

select * from table_1 RIGHT JOIN table_2 ON table_1.id = table_2.uid
where table_1.status = 1 AND table_2.level_id = 1 AND table_2.level_id = 2

這段代碼意思是同一條table2的記錄同時(shí)是等級(jí)1和等級(jí)2，是個(gè)假命題。。
改的話需要right join兩次table2

select table_1.* from table_1 
RIGHT JOIN table_2 t2Lv1 ON table_1.id = t2Lv1.uid ON t2Lv1.level_id = 1
RIGHT JOIN table_2 t2Lv2 ON table_1.id = t2Lv2.uid ON t2Lv2.level_id = 2
where table_1.status = 1
GROUP BY table_1.id

大致思路就是這樣

https://www.cnblogs.com/usual...

你的this，在渲染的時(shí)候，已經(jīng)丟失了吧……這里也許在click的時(shí)候應(yīng)該使用箭頭函數(shù)才能把this帶過(guò)去

有可能是并發(fā)或者鎖表，語(yǔ)句主要集中在 1~2 分鐘之內(nèi)

完全沒(méi)必要啊，直接用腳本調(diào)用mongodump + mongorestore不就搞定的事情？何必寫一個(gè)python程序？

mysql5.7支持json

你們公司有 DBA 嗎，沒(méi)有的話分庫(kù)分表堆機(jī)器用錢砸。

這取決于你所選擇的引擎和文件系統(tǒng)。

MyISAM 在 MySQL 5.0 之后單表上限取決于文件系統(tǒng)。
Innodb 在 共享表空間存儲(chǔ)方式 的情況下單表上限（不是單文件）為 64TB 左右，其中包含索引等相關(guān)數(shù)據(jù)；
在 獨(dú)享表空間存儲(chǔ)方式 的情況下單表上限由文件系統(tǒng)決定。

以上相關(guān)信息由百度結(jié)果 mysql單表大小的限制 - CSDN （該文發(fā)布于 2015年01月18日） 得來(lái)，關(guān)鍵字為 MySQL 單表上限，最新的數(shù)據(jù)應(yīng)以官網(wǎng)為準(zhǔn)。

加粗文字

加粗文字

列表項(xiàng)目

最大的有符號(hào) BIGINT值是9223372036854775807,檢查一下有沒(méi)有溢出
參考官方問(wèn)題解釋

https://dev.mysql.com/doc/refman/8.0/en/out-of-range-and-overflow.html

間隔2天的寫法：

SELECT * FROM `dates` WHERE DATEDIFF(`date`, '2018-01-01') % 2 = 0;

前30天的應(yīng)該自己會(huì)寫了吧 ^_^

select * from table order by TIME desc

首先作為畢設(shè) , 我感覺(jué)這個(gè)表設(shè)計(jì)本身沒(méi)啥硬傷 .
其次是 , 百度云是用的mongodb , 一次mongodb的分享會(huì)上聽過(guò)百度云的人分享過(guò)一些技術(shù) .

關(guān)于MongoDB
首先是警告不是錯(cuò)誤，并不會(huì)造成你不能運(yùn)行；
其次警告的內(nèi)容是不是自己先理解一下，看看有什么不懂的地方？

關(guān)于NodeJS
可能要說(shuō)英文不好，那我們來(lái)一個(gè)詞一個(gè)詞讀讀

app crashed - waiting for file changes before starting...
應(yīng)用崩潰了 - 等待文件變更 在重啟之前...

意思是不是很明白？由于某種錯(cuò)誤應(yīng)用不能成功啟動(dòng)，那么現(xiàn)在能重試嗎？不管怎么重試還是會(huì)失敗對(duì)不對(duì)？所以nodemon要等待文件有變更后再重試是不是更有道理一些呢？
那到底是什么問(wèn)題？看日志啊，沒(méi)有日志鬼知道什么問(wèn)題。

無(wú)關(guān)的話：建議樓主看到一大堆英文就算很崩潰還是讀一下，并沒(méi)有你想象的那么難。永遠(yuǎn)不讀就永遠(yuǎn)不會(huì)懂，讀一讀，慢慢就越來(lái)越容易。

給guid字段添加普通索引

這是我測(cè)試數(shù)據(jù)：

加索引id執(zhí)行計(jì)劃：

explain SELECT * FROM qxd.qxd_community where id = '540a1cb9-04cc-ce17-9933-81bb115328bb'

未加索引id執(zhí)行計(jì)劃：

mycat 慎用 感覺(jué)領(lǐng)導(dǎo)者在搞傳銷一樣 加群你就知道了 天天做培訓(xùn) 問(wèn)個(gè)問(wèn)題 都要紅包

僅從MongoDB的角度說(shuō)明這種東西可以怎么存。至于別人到底是怎么存，我們是不知道的。

關(guān)系模型存法

不多介紹，可以按照范式設(shè)計(jì)成跟關(guān)系數(shù)據(jù)庫(kù)一樣的表結(jié)構(gòu)來(lái)存儲(chǔ)，大概是：

{
    _id: ObjectId(...),
    comment: "...",
    time: ISODate(...),
    user: "...",
    musicId: "...",
    ...
}

如果用慣關(guān)系數(shù)據(jù)庫(kù)的用戶，這樣的做法簡(jiǎn)單自然。在現(xiàn)在討論的場(chǎng)景下，這樣沒(méi)有太大的問(wèn)題，在數(shù)據(jù)量大時(shí)可以使用分片來(lái)達(dá)到水平擴(kuò)展以應(yīng)對(duì)數(shù)據(jù)量的增長(zhǎng)。
不過(guò)仍有可以改進(jìn)的地方。這要從MongoDB的模型設(shè)計(jì)來(lái)講起。簡(jiǎn)單地說(shuō)，MongoDB是實(shí)用主義，怎么方便怎么來(lái)，怎么快怎么來(lái)，完全不應(yīng)該受范式的約束。但這也意味著你的模型要從應(yīng)用的需求出發(fā)。僅從上面截圖的信息，可能有2個(gè)不同的需求：

1. 評(píng)論
2. 點(diǎn)贊

考慮到評(píng)論和點(diǎn)贊都有可能上萬(wàn)甚至上十萬(wàn)百萬(wàn)，它們以單獨(dú)的集合來(lái)存放會(huì)比較合適。但是為了讀取和存儲(chǔ)效率，我會(huì)考慮把多條評(píng)論壓縮到一起，這種方式通常稱為分桶(bucket)。

非關(guān)系模型存法

{
    _id: ObjectId(...),
    musicId: "...",
    // 根據(jù)需要可能將音樂(lè)本身的一些數(shù)據(jù)冗余進(jìn)來(lái)
    musicName: "...",
    comments: [
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        ...
    ],
    count: 10, // 該桶內(nèi)已有10條comments
}

comments的數(shù)據(jù)量我會(huì)考慮一頁(yè)會(huì)展示多少評(píng)論（比如30條），那么在添加評(píng)論時(shí)可以有：

db.comments.updateOne({
    musicId: "...",
    count: {$lt: 30}
}, {
    $push: {
        comments: {content: "...", time: ISODate(...), user: "..."}
    },
    $inc: { count: 1 }
}, {
    upsert: true
});
// 優(yōu)化查詢速度會(huì)使用到索引：
db.comments.createIndex({
    musicId: 1,
    count: 1
});

在查詢時(shí)總是只需要最多取最新的2條記錄就可以查到第一頁(yè)：

db.comments.find({
    musicId: "..."
}).sort({_id: -1}).limit(2)
// 這個(gè)查詢需要索引
db.comments.createIndex({
    musicId: 1,
    _id: -1
});

注意_id的高4位是時(shí)間，所以是可以排序的，其順序就是時(shí)間順序。
點(diǎn)贊的問(wèn)題可以通過(guò)類似的方式實(shí)現(xiàn)，就留給你自己思考了。

可以的。
微信授權(quán)之后拿到openid，檢測(cè)openid是不是在系統(tǒng)中，如果在，就用openid登錄，完了返回token。
如果沒(méi)在系統(tǒng)中，那么插入新用戶之后再返回tokken