where('shop_id',$shop_id)->where('pay_status',1)->where('pay_time','>','2017-11-03')

把錯(cuò)誤貼出來看看

可以看看這個(gè)項(xiàng)目配置模擬qq空間評(píng)論

電商系統(tǒng)經(jīng)常遇到的屬性變動(dòng)問題

數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候由于未來需求經(jīng)常改變。
所以設(shè)計(jì)的時(shí)候需要把原本是列的變成行數(shù)據(jù)，到時(shí)候要改列的時(shí)候通過插入行數(shù)據(jù)來實(shí)現(xiàn)。
舉個(gè)例子。

我有個(gè)手機(jī)。
有名稱價(jià)格，翻蓋還是滑蓋，智能機(jī)還是非智能機(jī)等屬性。

如果按照列的設(shè)計(jì)。

那么，每個(gè)手機(jī)的值如下

ID 名稱，價(jià)格，翻蓋/滑蓋/直板，是否智能機(jī)
1，諾基亞，1000，翻蓋，否
2. 蘋果，4000，直板，是
3. 安卓，2000，直板，是

如果要增加操作系統(tǒng)字段，需要更改表結(jié)構(gòu)添加字段。

采用行設(shè)計(jì)

屬性表

ID,屬性名
1. 操作系統(tǒng)
2. 直板/滑蓋/翻蓋
。。。

商品表

ID,名稱，價(jià)格
1 諾基亞，1000
2 蘋果 4000
3 安卓 2000

商品屬性
商品ID ，屬性ID，屬性值
1 1 塞班
1 2 直板
2 1 ios
2 2 直板

這樣，如果要加屬性。添加屬性表的數(shù)據(jù)和商品屬性表數(shù)據(jù)即可，不需要改結(jié)構(gòu)

不同客戶之間功能不同問題

首先，程序只有一套，數(shù)據(jù)庫(kù)只有一個(gè)。

1. 所以，客戶需要實(shí)現(xiàn)的功能，我們程序必須實(shí)現(xiàn)，每個(gè)功能加到一個(gè)功能表，參照屬性表設(shè)置
2. 然后需要開通該功能的客戶，添加一個(gè)表，參考商品屬性表，

功能

ID，功能名稱
1 廣告功能
2 可以自定義微信公眾號(hào)
...

客戶功能
客戶ID，功能名稱
1 1
1 2

做好緩存，那么我讀取到客戶1的時(shí)候會(huì)發(fā)現(xiàn)客戶1有廣告功能和微信功能，那么程序根據(jù)這個(gè)該顯示頁(yè)面的添加頁(yè)面顯示，后臺(tái)可以操作的，后臺(tái)也顯示出來

需要看一下執(zhí)行計(jì)劃：

db.<表>.explain(true).count(<條件>);

從中可以了解到count時(shí)是否可以用到索引，用到哪條索引。
{background: true}的索引只是在初次創(chuàng)建時(shí)不阻塞前臺(tái)線程，并不是指異步創(chuàng)建索引，所以不存在你說的問題。
可能性較大的是這9條索引中有一個(gè)或多個(gè)是部分索引，而執(zhí)行計(jì)劃選中的是這個(gè)索引。可以查看索引配置：

db.<表>.getIndexes();

通常MongoDB不太可能選擇這樣的索引來count，所以也可能是特定版本的bug，希望看到你的服務(wù)端版本來確認(rèn)：

db.serverBuildVersion();

綜上，我們需要看到：

• 執(zhí)行計(jì)劃
• 9條索引的配置
• MongoDB版本

不要直接拼接字符串，如果你的內(nèi)容包括以下符號(hào) ' -- [ ] 等 ，可能會(huì)報(bào)錯(cuò)，
例如本來你想查詢 select * from table where name = '${var1}';， 如果你的變量var1 是 Mr.W'O，那么拼接后你的語(yǔ)句就變成了 select * from table where name = 'Mr.W'O'; 語(yǔ)句中出現(xiàn)了三個(gè) ' 當(dāng)然會(huì)報(bào)語(yǔ)法錯(cuò)誤。 報(bào)錯(cuò)還是小事情，被黑客利用而進(jìn)行sql注入就麻煩了。
建議你用node的模塊mysql或mysql2 對(duì)變量進(jìn)行編碼，可能你的寫法就變成了這樣

var sql = `insert into article_list
          (title,author,summary,is_top,catalog_alias,content)
           values
            (?,?,?,?,?,?)`;
let result = mysql.query(sql, [req.body.title, req.body.author,req.body.summary,req.body.is_top])

因?yàn)槲乙彩莿倓倢W(xué)習(xí)這個(gè)。。。
body-parser這個(gè)中間件的問題
post需要用這個(gè)

寫上端口！命令行默認(rèn)3306，sequel pro并不會(huì)給你默認(rèn)

方案三：能不能加一個(gè)埋點(diǎn)處理呢？也就是，在可能發(fā)生有效銷售情況的地方，做一個(gè)埋點(diǎn)處理，然后就不會(huì)讓0銷售的數(shù)據(jù)，進(jìn)入處理中間表了呢？

終于搞明白了

使用Docker用相同的鏡像創(chuàng)建兩個(gè)不同的實(shí)例就可以，如果沒有Docker可以使用不同的配置文件啟動(dòng)兩個(gè)，前提是兩個(gè)的端口號(hào)都不能重復(fù)。

1、外鍵首先是鍵，有鍵即意味邏輯上的引用關(guān)系，通常會(huì)有索引，查詢會(huì)更快;
2、其次是約束， 避免插入一些不合理的數(shù)據(jù)，需要另一個(gè)表的ID, 但另一表里沒有數(shù)據(jù)，如果允許這樣的話，應(yīng)用層面需要做不斷地做檢查;
3、可以實(shí)現(xiàn)一些高級(jí)操作，如級(jí)聯(lián)更新和級(jí)聯(lián)刪除等，這也正是外鍵帶來的好處;
4、一些ORM框架自動(dòng)為外鍵生成相應(yīng)的增刪改查的對(duì)應(yīng)函數(shù)，方便和簡(jiǎn)化數(shù)據(jù)庫(kù)的使用;
5、批量導(dǎo)入數(shù)據(jù)時(shí)自動(dòng)會(huì)檢查，但要注意表的引用關(guān)系和導(dǎo)入的先后順序，如果有循環(huán)引用或自指，要先停掉約束檢查，這是外鍵帶來的不方便的副作用。

至于題主說的沒外鍵也能按一定條件查到數(shù)據(jù)，這沒有什么好奇怪的吧，只要是合乎sql的語(yǔ)法，什么條件數(shù)據(jù)庫(kù)都會(huì)接受，不管在業(yè)務(wù)邏輯上是否存在合理性。正如題主的例子，user.id=product.id也沒什么可怕的，如果能給個(gè)解釋的話...

json_encode了解一下

1. 看硬件
2. 看索引
3. 多數(shù)情況下沒那么容易因?yàn)槁?lián)表查詢而導(dǎo)致性能瓶頸，如果有，先檢查前面兩個(gè)，然后優(yōu)化表結(jié)構(gòu)、SQL語(yǔ)句、引擎參數(shù)
4. 實(shí)在要避免聯(lián)表，那只能單表拿數(shù)據(jù)自己在應(yīng)用層做合并，但是這樣你不能保證內(nèi)存中每個(gè)表的數(shù)據(jù)都是最新的。

一般來說是連表快一點(diǎn)，但是要注意的是連表的索引要做好，不然數(shù)據(jù)量一大反而會(huì)比循環(huán)查詢慢

請(qǐng)把應(yīng)用中的MySQL連接字符串貼出來

聯(lián)表查詢盡量少用

in 也很吃資源 少用

不動(dòng)表結(jié)構(gòu)的話優(yōu)化起來很困難啊

/^(\d+\.{1})/

確認(rèn)下mysql服務(wù)有沒有啟動(dòng)

Windows：
開始--運(yùn)行--輸入"services.msc"--Mysql--右鍵"啟動(dòng)"

Mac:
系統(tǒng)設(shè)置--MySQL--開啟Server

因?yàn)镮nnoDB其他方面的優(yōu)點(diǎn)可以完全碾壓MyISAM，比如崩潰恢復(fù)快，支持事務(wù)，支持行級(jí)鎖，支持真正的熱備份等等。多了這么多功能當(dāng)然更耗資源羅
可以看看這本書 https://segmentfault.com/a/11...；