如果排序涉及的數(shù)據(jù)量很大，那么肯定是交給數(shù)據(jù)庫比較好。因為排序的最終目的是分頁輸出，數(shù)據(jù)庫可以使用索引來更快的達到這一目的。

salt只是用來防止 字典攻擊

讀寫分離當然就選balance=1啊，等于0就是不開啟讀寫分離了，并且雙主模式建議寫不是真的非常高的話writeType=0，只寫一個主master1，避免一些網(wǎng)絡(luò)或者其他不可預(yù)知的bug導致數(shù)據(jù)不一致的情況，讀寫分離就用另一個master2和剩下的slave分擔讀請求，這時候讀請求在master2和slave上沒有誰比誰優(yōu)先的問題
另外如果網(wǎng)絡(luò)或者磁盤io跟不上導致主從延遲的情況，而讀請求又要求比較高的實時性，那就使用事務(wù)控制吧，mycat會把事務(wù)發(fā)送到負責寫的主庫上。我的配置：

<dataHost name="db1" maxCon="2000" minCon="50" balance="1" writeType="0" dbType="mysql" dbDriver="native" >

原則上不支持在不同的版本之間dump/restore數(shù)據(jù)，特別是3.4以后BSON規(guī)范做了修改，更可能會失敗。
另外你可以檢查一下bs/topicData_wellness.bson是不是完整，看錯誤提示有可能是這個文件不完整導致的。
試一下：

    bsondump bs/topicData_wellness.bson | tail -n 10

看看會不會正確輸出結(jié)果。

可以先把表做關(guān)聯(lián)，然后用left join 查詢連接到一起。

用include

&&左邊會隱式轉(zhuǎn)換為boolean

function verify() {
    return 123
}

let result = verify && verify();// -> true && verify() -> verify() -> 123

1、性別這樣的檢索，不適合加索引；
2、like的考慮全文索引，如果簡單的就借助存儲引擎的，復雜的話就用solr全文檢索

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

CUBE的用法和Postgres數(shù)組了解一下。

with usr as (
    select user_id, array_agg(distinct product_id) as prds
    from (values('A',1),('A',1),('B',1),('C',2),('A',2),('A',3),('B',2),
        ('C',2),('D',1)) as order_list(product_id, user_id)
    group by user_id),
cmbs as ( -- combinations
    select array_remove(array[a,b,c,d], null) as cmb
    from (values('A', 'B', 'C', 'D')) as prd(a,b,c,d)
    group by cube (a,b,c,d))
select
    array_to_string(cmb, ' ') as prod,
    array_agg(user_id) as users,
    count(user_id) as tally
from cmbs inner join usr on cmb <@ prds
where array_length(cmb, 1) > 0
group by cmb

int類型的（包括tinyint,smallint...)后面括號內(nèi)的數(shù)字，一般情況下是不需要專門設(shè)置的，默認的就好了。
因為它只與顯示有關(guān)，和占用的空間無關(guān)。

而只有一種情況下，我們需要用到：
當數(shù)字的長度小于指定位數(shù)時，用0補齊。這時需要結(jié)合zerofill使用
比如 tinyint(2) zerofill
如果是3，則顯示為 03
如果是122，則顯示為 122

如果你不使用zerofill，而括號內(nèi)的數(shù)字隨便寫，效果是一樣的。

B+樹的葉節(jié)點是有序的。當它用于聚集索引的時候，葉節(jié)點本身既是索引又是真實值。當它用于非聚集索引的時候，葉節(jié)點僅僅是索引，索引的指針指向的才是真實值。由于此時索引是有序的，因此其指向通常是無序的，所以兩個連續(xù)的索引值可能對應(yīng)的真實值所在的行可能會離得很遠。

舉個例子，一個表用整數(shù)id作為主鍵，且將主鍵當做聚集索引。此時再用表中的另一列age當做非聚集索引。由于表的行本身就是按主鍵排序的，因此age是無序的，所以age=10的行可能在第八行，而age=11的行卻可能位于第三十行，差別很大。所以在插入的時候就無法做到連續(xù)的索引插入到連續(xù)的行中，而只能一條一條地定位和插入

4000次的循環(huán)本身并不大，如果循環(huán)里僅僅是對內(nèi)存的操作其實很快就應(yīng)該完成，但是你在循環(huán)里做了很多次數(shù)據(jù)庫操作，這應(yīng)該就是造成性能問題的根本原因。盡管每條sql執(zhí)行都很快，但是你忽略了每次執(zhí)行所帶來的網(wǎng)絡(luò)io開銷時間。我才想4000次的循環(huán)里如此多的數(shù)據(jù)庫操作足以是你的腳本超時了，當你所提到超時時，我認為你的php運行在fast cgi模式下。那么你有兩種方法來解決
1，將sql操作合并，一次或幾次在循環(huán)之外一口氣得到所有的數(shù)據(jù)，再在循環(huán)中進行分門別類。我相信這樣做會立竿見影的提升效率。
2， 如果這個操作不是及時性的，那么可以嘗試放在cli模式下運行，你不用修改代碼，盡管效率同樣低，但cli模式下腳本不會超時。

另外如果你所獲得到數(shù)據(jù)總量很大，那么還要考慮php本身為腳本所分配的最大可用內(nèi)存，如果這個值低于你獲取的數(shù)據(jù)所需要的內(nèi)存，那么即便在cli模式腳本還是得崩。這個配置好像是在php.ini里一個叫max_memory_size定義的，名字可能不準確，我記不太清了

前端

axios.post('/post',{data:表1數(shù)據(jù),data2:表2數(shù)據(jù)});

后端（KOA為例，需要koa-bodyparser中間件）

const {data,data2} = ctx.request.body;
const [model,model2] = await Promise.all([Model.create(data),Model2.create(data2)]);

方案一: 目標表new_table不存在，因為在插入時會自動創(chuàng)建表new_table，

SELECT `id`, `name`, `class` INTO new_table FROM old_table

方案二: 目標表new_table必須存在

INSERT INTO new_table(`id`, `name`, `class`) SELECT `id`, `name`, `class` FROM old_table

https://dev.mysql.com/doc/ref...

樹莓派的系統(tǒng)，估計已經(jīng)精減到底了，很多依賴都沒有，所以，只能按照提示，慢慢裝了，就算你打算從源碼編譯，也會要求添加好多依賴的

理了一下啊，首先是在這個頁面提交找回賬號密碼，

然后跳轉(zhuǎn)到j(luò)avasript的views函數(shù)

然后跳轉(zhuǎn)到SEMCMS_Remail.php的find方法

這里又跳轉(zhuǎn)到include/web_email.php的fintpassword方法

然后就到了一開始提問截圖的地方了，沒看到這些文件做了什么處理，只能理解是php本身做了什么處理，但我這個版本的php沒有magic_quotes啊

用echo是這樣的

要不嘗試重啟mongo服務(wù)

除了行數(shù)相同，兩個表的行間沒有任何關(guān)聯(lián)關(guān)系，用D替換C的說法就不明確了?？梢钥紤]強制給一個排序順序row_number() over (order by)作為id進行替換。但是這樣做的結(jié)果有什么意義只有題主自己把握了。

連新建表的權(quán)限也沒有，可以先insert

insert into T1 select A, B, D + '<<INSERTED>>' C from
    (select row_number() over (order by A,B,C) id, * from T1) S1 
    inner join
    (select row_number() over (order by D) id, * from T2) S2
    on S1.id = S2.id

再delete

delete T1 where C not like '%<<INSERTED>>'

當然最后還需要把C列update一下，去掉后綴<<INSERTED>>。

這個我記得必須是做雙重查詢嵌套的……以前也碰上過類似需求，2表聯(lián)查但是后表數(shù)據(jù)需要做個排序什么的。試了很多方案都不行只能老老實實嵌套……