你只是想返回一個(gè)結(jié)果，但使用 throw 一般是拋出異常。
很多時(shí)候返回 status 為0，其實(shí)并不是異常。
我覺(jué)得這些時(shí)候使用 throw 是不合適的。
所謂的異常，應(yīng)該是“它本來(lái)應(yīng)該是這樣的，但結(jié)果卻不是”，才需要拋出異常。
比如你要處理一張圖片，傳的參數(shù)指向的文件存在，文件后綴也存在，但讀取數(shù)據(jù)后卻不能正確處理，這時(shí)拋個(gè)異常是可以理解的，但我個(gè)人覺(jué)得這還不夠好。

因?yàn)槲揖陀龅竭^(guò)，使用 thinkPHP 3.2 的圖片處理類(lèi)，遇到不能處理的圖片，直接拋出了異常，但其實(shí)對(duì)我來(lái)說(shuō)，如果處理圖片有問(wèn)題 ，是可以直接跳過(guò)去的。

也就是說(shuō)：只有“這一步如果出錯(cuò)，后面的代碼執(zhí)行就完全沒(méi)有意義或者完全不能執(zhí)行”的時(shí)候才去拋出異常，否則只需要返回結(jié)果，給使用者（可能是控制器）去處理就好了。

對(duì)于樓主的需求，ThinkPHP 是有內(nèi)置的方法的，比如控制器中有 success() 和 error() 兩種方法來(lái)滿(mǎn)足樓主的需要，當(dāng)然，我個(gè)人比較喜歡 ThinkPHP 3.2的處理方式，比如簡(jiǎn)潔，ThinkPHP 5中的這兩個(gè)方法添加了不必要的參數(shù)，寫(xiě)起來(lái)倒挺麻煩的。
但這兩個(gè)方法只在控制器中有，模型中默認(rèn)是沒(méi)有的，當(dāng)然，如果你喜歡的話(huà)，也可以加到模型中去。
但我個(gè)人同樣不太推薦。處理返回結(jié)果或頁(yè)面跳轉(zhuǎn)的任務(wù)還是交給控制器會(huì)比較好。

模型中，其實(shí)可以自己定義個(gè)類(lèi)似的方法，比如：

function succ($data="",$status=1){
      return array(
       'status'=>$status,
       'info'=>$data,
    );
}

function error($msg=""){
  return succ($msg,0);
}

你在模型中直接 return succ($data);或 return error($msg);即可。

控制器中根據(jù)返回的數(shù)組，再使用$this->success()或$this->error();當(dāng)然，如果你在使用ThinkPHP 5,也像我一樣比較喜歡 ThinkPHP 3.2 的風(fēng)格，這兩個(gè)方法你是可以改成3.2的風(fēng)格的。

說(shuō)回樓主和你看到的大神的代碼，基本思想都差不多，只不過(guò)你直接返回一個(gè)數(shù)組，而“大神”卻直接拋出異常，我不喜歡這位大神的風(fēng)格。
但你和“大神”都喜歡寫(xiě)重復(fù)的 "status'=>1,"msg"=>......，我則比較喜歡把它裝進(jìn)函數(shù)或方法中，畢竟這兩個(gè)操作是使用非常頻繁的。

關(guān)于代碼中較多 if/else 的情況，我一般使用兩種方法解決：

1. 短的判斷可以用三目運(yùn)算符代替；
2. 很多時(shí)候 if 時(shí)使用了return ，后面就可以不寫(xiě) else 了 。

補(bǔ)充：

概括一下：

1. 模型中建議使用 return ，而不是拋出異常，return 的數(shù)據(jù)可以自己封裝個(gè)函數(shù)或方法；(當(dāng)然，要結(jié)合業(yè)務(wù)的具體需求！)
2. 拋出異常意味著程序的終止，在非必須的情況下不要這樣做；
3. 控制器中直接使用 success 和 error 或 ajaxReturn 方法即可。

但如果把樓主看到的“大神”的代碼從模型中移到控制器的話(huà)，應(yīng)該是合理的（除了重復(fù)的代碼有點(diǎn)多外）。
我個(gè)人是不太喜歡使用 throw，但我查看了一下 ThinkPHP 5 和 ThinkPHP 3.2 的源碼，其中的 success和 error 方法除了使用參數(shù)復(fù)雜性不同外，還有一點(diǎn)區(qū)別就是 3.2直接使用 exit()結(jié)束程序，而 5.0 版本中使用的是 throw 一個(gè)異常類(lèi)。

應(yīng)該有理由相信，使用 throw 可能會(huì)比如說(shuō) exit 更好。
于是，我找到一種說(shuō)法：

PHP調(diào)用exit退出腳本執(zhí)行不會(huì)導(dǎo)致PHP服務(wù)退出。
https://segmentfault.com/q/10...

我不了解底層的機(jī)制，但我覺(jué)得這種說(shuō)法是比較可信的。

查詢(xún)近三個(gè)月的訂單就到近三個(gè)月訂單表查詢(xún)，查詢(xún)上一年的就到上一年的訂單表查詢(xún)

哈？？
你面的京東，京東真這么干的？

……你這個(gè)思路方向有點(diǎn)不太對(duì)的感覺(jué)。并發(fā)不是一種代碼操作而是一種現(xiàn)象描述吧？
mysql就是個(gè)庫(kù)，java多線(xiàn)程寫(xiě)入、自然就并發(fā)了。
mysql要面對(duì)的問(wèn)題反而是……并發(fā)了以后如何保證數(shù)據(jù)不亂不出錯(cuò)……
牽扯的知識(shí)點(diǎn)有讀寫(xiě)鎖、鎖粒度之類(lèi)的……

換了netbeans後已成功連線(xiàn)QQ

這樣的 json 結(jié)果，需要你用 Python 的數(shù)據(jù)庫(kù)類(lèi)里設(shè)置好相應(yīng)的輸出 json 函數(shù)。

不敢再發(fā)我的項(xiàng)目鏈接，老是被那些不認(rèn)真，不仔細(xì)，或者說(shuō)一知半解的人舉報(bào)。

如果你想學(xué)習(xí) sql to sqlalchemy，你可以查看我的資料，然后找到相關(guān) github 項(xiàng)目的鏈接。

數(shù)據(jù)庫(kù)分表：將冗余在單庫(kù)中的單個(gè)業(yè)務(wù)表拆分為N個(gè)"邏輯相關(guān)"的業(yè)務(wù)子表；
數(shù)據(jù)庫(kù)分庫(kù)：將原單個(gè)數(shù)據(jù)庫(kù)中業(yè)務(wù)表按照一些算法分不到N個(gè)"邏輯相關(guān)"數(shù)據(jù)庫(kù)中；
數(shù)據(jù)庫(kù)分區(qū): 將原先存儲(chǔ)在單個(gè)物理存儲(chǔ)區(qū)域的數(shù)據(jù)庫(kù)，分不到N個(gè)的物理存儲(chǔ)區(qū)域。

有點(diǎn)混亂，我一點(diǎn)點(diǎn)說(shuō)：

目測(cè)還挺正常的，提出了warning但是查了一下大概就是說(shuō)我沒(méi)用戶(hù)名密碼本地?cái)?shù)據(jù)庫(kù)什么的。

沒(méi)錯(cuò)，這里只是警告，告訴你有一些運(yùn)行風(fēng)險(xiǎn)，不符合最佳實(shí)踐，但是不影響你使用。只是上生產(chǎn)環(huán)境之前應(yīng)該考慮解決掉這些問(wèn)題。

配置文件沒(méi)有問(wèn)題，你的截圖中已經(jīng)進(jìn)入了mongo shell，可以開(kāi)始執(zhí)行mongo的CRUD命令了（就跟進(jìn)入了mysql shell一樣）。但是你又在mongo shell里面執(zhí)行mongo，不明白是什么意思。mongo.exe是一個(gè)bash命令，運(yùn)行它之后就是進(jìn)入mongo shell而已，而你已經(jīng)在shell里面了。你是怎么進(jìn)入這個(gè)shell的？不就是執(zhí)行了mongo嗎？

再來(lái)說(shuō)chrome連接localhost:27017，好多人犯這樣的錯(cuò)誤，可能都是來(lái)自于一些教程的誤導(dǎo)。舉個(gè)例子，MySQL默認(rèn)監(jiān)聽(tīng)localhost:3306，SQLServer默認(rèn)監(jiān)聽(tīng)localhost:1433，你會(huì)在影響器里面去連接localhost:1433/localhost:3306嗎？連接之后會(huì)有什么效果？同樣會(huì)出現(xiàn)截圖里面的錯(cuò)誤。這樣去連接沒(méi)有意義。要連接27017端口應(yīng)該使用mongo shell，也就是mongo.exe：mongo.exe --host localhost:27017

最后說(shuō)Python的問(wèn)題。你前面已經(jīng)通過(guò)shell連接上了MongoDB，所以服務(wù)器運(yùn)行是沒(méi)有問(wèn)題的。而Python連接不上，可能原因是localhost這個(gè)域名的解析有問(wèn)題。你可以改用：

MongoClient('127.0.0.1', '27017')

試一下看看是什么結(jié)果。

附加在響應(yīng)頭里面

... ... ORDER BY city, company

運(yùn)行的是cmd，不是mysqldump，
"mysqldump -h localhost -u root -p -t lailr_js_pay wx_sp > f:/test.sql"
這一句是cmd的參數(shù)

$str = '{"aa":" [[123123,123123123],[123123123,123123],[123,123123]]"}';
// 先轉(zhuǎn)一次碼農(nóng)宅
$arr = json_decode($str,true);

print_r(trim($arr['aa']));

$sql = "INSERT INTO table_student VALUES($stuId,$stuName,'$stuChinese','$stuMath','$stuEnglish')"; 中的$stuId,$stuName都是加上單引號(hào)試一試

是不是配置時(shí)沒(méi)有把wordpress這個(gè)目錄包括進(jìn)去？

另外，樣式不能正確顯示，還可能是你引用 了http的css文件。

因?yàn)槲沂褂玫氖潜容^舊的版本，所以我目前的處理方法是，把<el-select>封裝一下

評(píng)論和回答應(yīng)該是分表的。
評(píng)論表應(yīng)該會(huì)有這些字段：
id 自增
content 評(píng)論的內(nèi)容
uid 誰(shuí)寫(xiě)的評(píng)論
type 類(lèi)型，是問(wèn)題的評(píng)論，還是回答的評(píng)論
qid/answer_id 問(wèn)題或回答的id,當(dāng)然，也可以把問(wèn)題評(píng)論和回答的評(píng)論分成不同的表，這樣，type字段就可以不要了。
time 添加時(shí)間
zan 獲得的點(diǎn)贊數(shù)
pid 回復(fù)的對(duì)象，如果沒(méi)有則為0
status 狀態(tài)，正常，還是被刪除，或者是用戶(hù)自己刪除（刪除方式，segmentfault 不一定有區(qū)分)

相關(guān)聯(lián)的表應(yīng)該有：
用戶(hù)表，與uid關(guān)聯(lián)
問(wèn)題表，與qid關(guān)聯(lián)
回答表，與answer_id關(guān)聯(lián)（與qid二選一)
贊同表，每一個(gè)贊同應(yīng)該都是有紀(jì)錄的，所有應(yīng)該有個(gè)獨(dú)立的表，但它們之間的關(guān)系一般是“同時(shí)”，與上面幾個(gè)的“關(guān)聯(lián)”不太一樣。

是我的話(huà)，差不多會(huì)這樣設(shè)計(jì)。

sql有問(wèn)題？

試試這個(gè)

SELECT
s.id,
s.name,
s.price,
s.unit
from sample as s where id = 20205

EDITED

應(yīng)該MySQL的bug

https://bugs.mysql.com/bug.ph...
https://bugs.mysql.com/bug.ph...

與你的報(bào)錯(cuò)很類(lèi)似

terribly wrong...
7ff744872571    mysqld.exe!pow()[pow.asm:1616]
7ff743d8da3a    mysqld.exe!get_sweep_read_cost()[handler.cc:7200]
7ff74434f3a7    mysqld.exe!ror_intersect_add()[opt_range.cc:5440]
7ff7443453a9    mysqld.exe!get_best_ror_intersect()[opt_range.cc:5621]

建議提交Bug

model/blog.js 里找 toLowerCase

select 姓名,學(xué)科 from 姓名表 left join 學(xué)科表 on 學(xué)科表.id=姓名表.id and 學(xué)科表.狀態(tài)='選修'

• 從populate文檔來(lái)看至少應(yīng)該不是$lookup

MongoDB has the join-like $lookup aggregation operator in versions >= 3.2. Mongoose has a more powerful alternative called populate(), which lets you reference documents in other collections.

而DBRef只能根據(jù)ObjectId，并且有固定的格式要求，所以我傾向于認(rèn)為它是構(gòu)造了查詢(xún)，在得到數(shù)據(jù)對(duì)象的時(shí)候再根據(jù)引用條件查詢(xún)一次得到引用的對(duì)象。這樣就造成一個(gè)不可避免的問(wèn)題，如果一次查詢(xún)返回結(jié)果集有10條記錄，那么除了這些記錄外還要進(jìn)行10次額外的查詢(xún)來(lái)獲取引用它們的對(duì)象。性能上面肯定是大打折扣的。

• $lookup的性能比DBRef好，它只進(jìn)行一次查詢(xún)來(lái)獲取所有結(jié)果。但是這個(gè)運(yùn)算符目前只能在復(fù)制集中使用，分片集暫不支持。
• 程序?qū)τ贛ongoDB查詢(xún)用了多少時(shí)間，當(dāng)然要從程序端來(lái)監(jiān)控。MongoDB端只會(huì)給出查詢(xún)用了多少時(shí)間，很多時(shí)候消耗的大頭還可能發(fā)生在網(wǎng)絡(luò)上面。如果對(duì)數(shù)據(jù)庫(kù)執(zhí)行程序花了多長(zhǎng)時(shí)間感興趣，可以參考一下database profiler。但應(yīng)該避免在生產(chǎn)環(huán)境進(jìn)行profiling，因?yàn)樗赡軙?huì)對(duì)性能造成比較可觀(guān)的影響。

總結(jié)一下，無(wú)論是$lookup還是DBRef，都是建議盡量避免的。我在這個(gè)問(wèn)題里解釋了正確的處理方式及原因，請(qǐng)參考。

mongo 服務(wù)器啟動(dòng)了？要先執(zhí)行 mongod 指令啟動(dòng)服務(wù)器，再執(zhí)行 mongo 指令連接