Git 多賬號(hào)配置

用新版本的生成器，yield

1.首先報(bào)錯(cuò)無效數(shù)字的話，確定了是字段格式不匹配，對(duì)于sql語句比我這個(gè)還復(fù)雜的，也是照樣，講語句分解開來

2.分解開后，去查詢出數(shù)據(jù)，首先關(guān)注關(guān)聯(lián)查詢的字段，其次重點(diǎn)去關(guān)注number類型的，再去找varchar類型的（varchar類型的需要關(guān)注是否超出了長(zhǎng)度）

3.查詢出數(shù)據(jù)，定位到錯(cuò)誤的數(shù)據(jù)，再看后期是改數(shù)據(jù)還是添加過濾或者改表了

--有個(gè)笨辦法，可以借用二分查找法來定位，如10個(gè)字段，先注釋后面5個(gè)字段，看是否報(bào)錯(cuò)，如不是，再注釋前5個(gè)字段，排查后5個(gè)字段，以此類推，定位到某個(gè)字段，記住這個(gè)報(bào)錯(cuò)，下次再碰到的時(shí)候，一眼就可以定位，如定位不了，那就再看二眼

》了解一下《

dir(manager)查看所有方法和屬性，有時(shí)候同樣的庫(kù)，版本不一樣，方法也會(huì)不同

請(qǐng)問問題解決了嗎

1. 你最后幾個(gè)and查詢，“最小下單次數(shù)、最大下單次數(shù)、下單總金額”，如果你的需求真的是這樣的話，那么可以考慮在cs_member里加幾個(gè)字段進(jìn)行存儲(chǔ)，數(shù)據(jù)變化的時(shí)候，再更新這幾個(gè)字段，這樣，查詢速度會(huì)快不少
2. 查一下表關(guān)聯(lián)字段的索引，是否建立了，如果沒有的話，建立相關(guān)的索引
3. 查詢字段“下單總數(shù)量、付款訂單數(shù)量、付款訂單總金額、最后下單時(shí)間”，不要在這里查詢，等待需要的指定條數(shù)的數(shù)據(jù)查出后，再遍歷查詢，這樣也會(huì)快很多。

excel使用這個(gè)phpexcel

至于數(shù)據(jù)就需要分片寫入excel文件，一次寫入1000條或者2000條啊，一次數(shù)據(jù)太多，會(huì)導(dǎo)致內(nèi)存溢出導(dǎo)致錯(cuò)誤，每一1000位一個(gè)文件，最后在合并文件就可以了，一次寫入50000條，這種做法是不支持的（除非你服務(wù)器很好）

可以進(jìn)行分批處理，寫一個(gè)batch的處理方法就行了，每次處理一部分?jǐn)?shù)據(jù)，比如1w，這樣的話，不會(huì)隨著數(shù)據(jù)量的增大導(dǎo)致gc，最多只是處理時(shí)間變長(zhǎng)而已

刪除前是否要先查詢一次，這個(gè)個(gè)人覺得應(yīng)視業(yè)務(wù)而定。正常情況是沒有這個(gè)必要，刪除通常按主鍵刪除，性能不是問題，但如果刪除的數(shù)據(jù)部分字段有緩存的話，應(yīng)該先查一下，主要是為了方便清理緩存。舉個(gè)栗子：假如要?jiǎng)h除一個(gè)用戶，用戶的手機(jī)號(hào)存在于緩存中(比如已注冊(cè)手機(jī)號(hào)集合)，此時(shí)直接刪除數(shù)據(jù)的話，緩存里的手機(jī)號(hào)就不會(huì)被移除，導(dǎo)致后來的人再也不能用這個(gè)手機(jī)號(hào)注冊(cè)，所以應(yīng)先查詢，再刪除，查詢只是為了處理附加業(yè)務(wù)。

我只是從業(yè)務(wù)角度來講的，與性能無關(guān)。

addEventListener可以多次綁定并不會(huì)覆蓋上一個(gè)事件啊，是否是其他地方影響到了？
像這種事件監(jiān)聽我的做法是在根組件監(jiān)聽然后用$on $emit分發(fā)事件
根組件監(jiān)聽并分發(fā)

window.addEventListener('popstate', () => {
  this.$root.$emit('popstate')
})

各級(jí)子組件的任意位置監(jiān)聽

this.$root.$on('popstate', () => {

})

請(qǐng)查閱Mysql的數(shù)據(jù)類型

不明白你說的這個(gè)鎖指什么？請(qǐng)說明下你的業(yè)務(wù)需求？

一般來說，加鎖應(yīng)該業(yè)務(wù)層應(yīng)用程序去控制，效率高且可控制。

問題原因是使用事務(wù)時(shí)，缺少 rollback 或 commit，使用以下代碼可穩(wěn)定復(fù)現(xiàn)這個(gè)錯(cuò)誤：

let mysql = require("mysql");

function createConn() {
    return mysql.createConnection({
        host     : '192.168.1.100',
        user     : 'yangqiang',
        password : '123456',
        database : 'node_mysql_demo'
    });
}

function transactionWithoutCommit(conn) {
    conn.beginTransaction(function (err) {
        if (err) {
            throw err;
        }
        conn.query('SELECT * from user where name="jonny"', function (error, results, fields) {
            if (error) {
                return conn.rollback(function () {
                    throw error;
                })
            } else {
                // 缺少 commit，引發(fā)錯(cuò)誤
            }
        });
    });
}

function transactionWithCommit(conn) {
    conn.beginTransaction(function (err) {
        if (err) {
            throw err;
        }
        conn.query('SELECT * from user where name="jonny"', function (error, results, fields) {
            if (error) {
                return conn.rollback(function () {
                    throw error;
                })
            } else {
                conn.commit(function (err) {
                    if (err) {
                        return conn.rollback(function(){ throw err;})
                    } else {
                        console.log('transaction committed');
                    }
                });
            }
        });
    });
}

function write(conn) {
    conn.query('INSERT INTO user (name) VALUES ("Mei");', function (error, results, fields) {
        if (error) throw error;
        console.log(JSON.stringify(results));
    });
}


var connection = createConn();
connection.connect();

transactionWithoutCommit(connection); // 引發(fā)錯(cuò)誤
// transactionWithCommit(connection); // 正確的方法
write(connection);

如果你不在意數(shù)據(jù)的話直接刪除數(shù)據(jù)
1 停止MySQL
2 刪除 MySQL的數(shù)據(jù) /var/lib/mysql
3 修改該 lower_case_table_names = 1
4 啟動(dòng) mysql
4 搞定

你的想法是可以的，但是沒有擴(kuò)展性，若以后需要新增新的產(chǎn)品不屬于課程，你查找訂單的時(shí)候需要連的表就多了，建表的時(shí)候最好考慮三范式，除非業(yè)務(wù)需求快速查詢，不然最好是不要在表中添加多余的字段

你為什么 把 phpmyadmin 和 wp 放在同一個(gè)目錄？

sudo lnmp vhost del

刪除你的域名

sudo lnmp vhost add

然后重新添加就行

或者修改你的 domain.conf 里面的 root 為你 wp 的目錄，完了重啟下 nginx

你說的這個(gè)在MySQL里不是主從，而是雙主（因?yàn)橐粫?huì)兒寫A，一會(huì)兒寫B(tài)），主從的意思是寫永遠(yuǎn)都寫主，再異步同步到從。

實(shí)際項(xiàng)目中一般不用雙主（可靠性和可維護(hù)性不如主從），主從的應(yīng)用卻很廣泛，而且一般主從也夠了，因?yàn)橹鲝哪Ｊ揭呀?jīng)很好的分擔(dān)掉讀操作，大部分應(yīng)用都是寫少讀多，從我個(gè)人的經(jīng)驗(yàn)，不建議使用MySQL的多主。

我的理解這算是數(shù)據(jù)分析的需求了，OLAP的需求依賴一條數(shù)據(jù)庫(kù)查詢直接產(chǎn)出結(jié)果不是很容易，如果是SQL可能會(huì)考慮存儲(chǔ)過程，MongoDB可選的方法有Map/Reduce和Aggregation，優(yōu)先選擇后者。性能問題在這里先不討論，先看看是否能達(dá)到你想要的效果。第二種數(shù)據(jù)結(jié)構(gòu)應(yīng)該沒有問題，第一種結(jié)構(gòu)我的解決方案如下：

db.test.aggregate([
    {$project: {brands: "$brands", brands2: "$brands"}},
    {$unwind: "$brands"},
    {$unwind: "$brands2"},
    {$project: {pair: ["$brands", "$brands2"]}},
    {$group: {_id: "$pair", count: {$sum: 1}}}
]);

這種方式先復(fù)制一個(gè)brands出來，然后做$unwind相當(dāng)于brands集合自己與自己排列，而你需要的是組合。比如你的示例數(shù)據(jù)：

{"brands" : [ "西門子", "ABB", "GE" ]}

出來的結(jié)果是：

{ "_id" : [ "GE", "GE" ], "count" : 1 }
{ "_id" : [ "GE", "ABB" ], "count" : 1 }
{ "_id" : [ "GE", "西門子" ], "count" : 1 }
{ "_id" : [ "ABB", "ABB" ], "count" : 1 }
{ "_id" : [ "ABB", "西門子" ], "count" : 1 }
{ "_id" : [ "ABB", "GE" ], "count" : 1 }
{ "_id" : [ "西門子", "GE" ], "count" : 1 }
{ "_id" : [ "西門子", "ABB" ], "count" : 1 }
{ "_id" : [ "西門子", "西門子" ], "count" : 1 }

有些額外的數(shù)據(jù)，比如[ "ABB", "ABB" ]，[ "西門子", "ABB" ]/[ "ABB", "西門子" ]。我暫時(shí)還沒想到很好的辦法直接在aggregation pipeline中直接過濾掉這些數(shù)據(jù)，不過應(yīng)該不影響你使用。如果有想到更徹底的辦法我再回來補(bǔ)充。

補(bǔ)充回答

求助了一下場(chǎng)外觀眾，aggregation確實(shí)很強(qiáng)大。你可能需要查一下：$map, $reduce, $let, $range這些操作符的用法

db.test.aggregate({
    $project: {
        tuples: {
            $reduce: {
                initialValue: [],
                input: {
                    $range: [0, {
                        $subtract: [{
                            $size: "$brands"
                        }, 1]
                    }]
                },
                in: {
                    $let: {
                        vars: {
                            i1: "$$this"
                        },
                        in: {
                            $concatArrays: ["$$value", {
                                $map: {
                                    input: {
                                        $range: [{
                                            $add: [1, "$$i1"]
                                        }, {
                                            $size: "$brands"
                                        }]
                                    },
                                    in: [{
                                        $arrayElemAt: ["$brands", "$$i1"]
                                    }, {
                                        $arrayElemAt: ["$brands", "$$this"]
                                    }]
                                }
                            }]
                        }
                    }
                }
            }
        }
    }
}, {
    $unwind: "$tuples"
}, {
    $sortByCount: {
        $setUnion: "$tuples"
    }
})

這個(gè)管道操作本質(zhì)上的意義就是：

for(var i = 0; i < array.length - 1; i++)
  for(var j = i + 1; j < array.length - 1; j++) {...}

執(zhí)行結(jié)果：

{ "_id" : [ "GE", "西門子" ], "count" : 1 }
{ "_id" : [ "ABB", "GE" ], "count" : 1 }
{ "_id" : [ "ABB", "西門子" ], "count" : 1 }

你這個(gè)問題太大了，硬件方面，我就不多說了，比如memcache及redis等NOSQL數(shù)據(jù)庫(kù)，對(duì)內(nèi)存要求都比較高，redis如果使用ssd的硬盤肯定比sas盤好多了。關(guān)于你說的網(wǎng)絡(luò)延遲和抵用應(yīng)用程序：我這里拿redis舉例了：
當(dāng)用戶連接到Redis通過TCP/IP連接或Unix域連接，千兆網(wǎng)絡(luò)的典型延遲可能達(dá)到200us，而Unix域socket可能低到30us，當(dāng)然這個(gè)跟你的硬件網(wǎng)卡有關(guān)系的，而且redis的屬于典型的C/S架構(gòu)，調(diào)用Redis時(shí)，通常是以發(fā)送-應(yīng)答-再發(fā)送-再應(yīng)答的模式進(jìn)行的，而每一次發(fā)送與應(yīng)答，都需要數(shù)據(jù)從客戶端到服務(wù)端飛一次，當(dāng)需要使用Redis處理多個(gè)命令時(shí)，這樣時(shí)間都消耗到網(wǎng)絡(luò)延遲上可能就不劃算了，當(dāng)然也可以對(duì)redis進(jìn)行優(yōu)化緩解網(wǎng)絡(luò)延遲問題，所有的不管是關(guān)系型數(shù)據(jù)庫(kù)還是nosql數(shù)據(jù)庫(kù)肯定都與調(diào)用該數(shù)據(jù)庫(kù)的程序有關(guān)系，比如大批量的查，大批量的寫等這些操作都會(huì)對(duì)數(shù)據(jù)庫(kù)帶來壓力。畢竟數(shù)據(jù)庫(kù)是這個(gè)服務(wù)的瓶頸，這個(gè)目前好的辦法是在數(shù)據(jù)庫(kù)前加緩存，對(duì)數(shù)據(jù)庫(kù)實(shí)現(xiàn)讀寫分離，同時(shí)拆庫(kù)優(yōu)化。這里我只描述redis，其他的nosql數(shù)據(jù)庫(kù)不太了解，不敢亂說。

//大概這樣，只是個(gè)大概：
if($supplier !==0 ){ //當(dāng)供應(yīng)商不為0時(shí)，goods_id使用供應(yīng)商的goods_id

    $where = 'goods_id=supplier_goods';

}else($dealer !== 0){ //當(dāng)經(jīng)銷商不為0時(shí)，goods_id使用經(jīng)銷商的goods_id

    $where = 'goods_id=dealer_goods'; 

}
$data = $mysql->query("select * from table where {$where}");
建議將判斷邏輯放在前面，讓SQL一目了然