你看下這樣行不行。
把input的value用數(shù)組表示，然后后臺(tái)接收到的所有input在一個(gè)數(shù)組中

$hotels = array();
$arr = $_POST['arr'];

foreach ($arr as $k => $v) {
    if($k%3 == 0){
        if($v){
            if(!$arr[$k+1] || !$arr[$k+2]){
                echo json_encode(array(
                    "code" => -1,
                    "msg"  => "如果填酒店名，就必須填金額，時(shí)間",
                ));
                die;
            }
            $hotels[] = array(
                "name" => $v,
                "cost" => $arr[$k+1],
                "time" => $arr[$k+2],
            );
        }else{
            $hotels[] = array(0, 0, 0);
        }
    }
}
echo json_encode(array(
    "code" => 0,
    "msg"  => "success",
));

看場(chǎng)景：

1. 日志是否需要實(shí)時(shí)分析？

如果不需要實(shí)時(shí)分析，可以用文件形式，固定格式存儲(chǔ)，然后進(jìn)行離線分析。

1. 是否一直都需要所有日志？

如果不需要所有日志，只需要部分日志，那么可以給一定時(shí)間之前的日志刪掉。

現(xiàn)在一般的做法都是，近期日志存在mongodb這種數(shù)據(jù)庫(kù)中，長(zhǎng)期日志存儲(chǔ)在大數(shù)據(jù)平臺(tái)。

分組第一條線排序再分組，取出的就是分組第一條。調(diào)整排序方式獲取最后一條。應(yīng)該是沒(méi)辦法同時(shí)獲取第一條最后一條

間隙鎖是為了防止幻讀
MySQL InnoDB 鎖——官方文檔
https://segmentfault.com/a/11...

下次記得把原始查詢也發(fā)出來(lái)，我們看著更方便些。從執(zhí)行計(jì)劃來(lái)反推，查詢大約是

db.webDevice.find({
    lid: {
        $in: [
            "40CnwyHkVmnA9kbScMLNLneaxuS4Tcj",
            "140CnwyHkVmnA9kbScMLNLneaxuS4Tcj"
        ]
    }
}).sort({createTime: -1}).limit(1);

因?yàn)槊兴饕?，這個(gè)查詢獲取數(shù)據(jù)的速度實(shí)際上比較快，你也提到在一段時(shí)間內(nèi)第二次查詢就快了，這是一個(gè)很明顯的特點(diǎn)，代表內(nèi)存不足。MongoDB和其他數(shù)據(jù)庫(kù)一樣，都會(huì)使用空閑內(nèi)存緩沖索引和數(shù)據(jù)，當(dāng)內(nèi)存不足時(shí)就會(huì)使用LRU算法清理舊數(shù)據(jù)換入新數(shù)據(jù)再繼續(xù)查詢。因?yàn)檫@個(gè)過(guò)程涉及到磁盤數(shù)據(jù)交換，速度會(huì)大大降低。發(fā)生這種情況有一個(gè)特點(diǎn)，就是一段時(shí)間內(nèi)第二次執(zhí)行時(shí)速度就快了（因?yàn)閿?shù)據(jù)已經(jīng)在內(nèi)存中）。但是如果過(guò)一段時(shí)間再執(zhí)行，速度又會(huì)變慢（因?yàn)橛直粨Q出內(nèi)存了）。所以你的情況實(shí)際上就是受限于硬件。
既然如此最直接的解決辦法就是：

1. 使用更快的硬盤；
2. 使用更大的內(nèi)存；

如果不能從硬件方面解決，有一點(diǎn)可以嘗試就是用CPU換內(nèi)存。做法是盡可能調(diào)小cacheSizeGB（是的沒(méi)錯(cuò)，是調(diào)?。??？臻e出來(lái)的內(nèi)存操作系統(tǒng)會(huì)用來(lái)緩沖磁盤數(shù)據(jù)，而磁盤數(shù)據(jù)是經(jīng)過(guò)壓縮的，體積更小，因此可以緩沖更多數(shù)據(jù)到內(nèi)存中。但作為交換，在使用這些數(shù)據(jù)時(shí)需要經(jīng)過(guò)CPU再進(jìn)行一次解壓從而額外消耗CPU。即使這樣，效果也比從磁盤讀取要好很多。整個(gè)過(guò)程是自動(dòng)進(jìn)行的，你需要做的只是調(diào)小cacheSizeGB。
這種做法可以在一定程度上緩解內(nèi)存不足的問(wèn)題，但不是萬(wàn)能的：

• 首先它會(huì)增加CPU消耗，如果你的系統(tǒng)本身已經(jīng)沒(méi)有剩余的CPU資源，這種做法就不合適；
• 其次受制于壓縮率，這樣做之后內(nèi)存能容納的數(shù)據(jù)并不會(huì)比以前多很多，所以并不是萬(wàn)能的；

補(bǔ)充回答

基于你的新的疑問(wèn)，以下幾點(diǎn)補(bǔ)充：

疑問(wèn)1: 按照你說(shuō)的方式調(diào)小cacheSizeGB,應(yīng)該怎么調(diào)整比較合理

我在上面有提到，這樣做的效果有限，是受制于壓縮率的限制。所以多容納的數(shù)據(jù)實(shí)際就是壓縮的數(shù)據(jù)。比如1G的內(nèi)存能放多少數(shù)據(jù)？

• 如果不壓縮（壓縮率100%），1G內(nèi)存能放1GB數(shù)據(jù)；
• 如果壓縮率90%，1G內(nèi)存可以放10/9GB~=1.11數(shù)據(jù)；
• 如果壓縮率80%，1G內(nèi)存可以放10/8 = 1.25GB數(shù)據(jù)；
• 以此類推……

所以調(diào)到多少，其實(shí)要看你想往內(nèi)存里放多少數(shù)據(jù)，而這往往是一個(gè)不確定的數(shù)值。這里會(huì)有另外一個(gè)概念叫做工作集（working set），就是你經(jīng)常用到的那些數(shù)據(jù)。比如你的數(shù)據(jù)庫(kù)共有100GB數(shù)據(jù)，但是你經(jīng)常用到的部分只有10GB，那么你的內(nèi)存只要能裝下10GB數(shù)據(jù)，應(yīng)用在大部分時(shí)候就可以非?？?，剩下的情況忽略就好了。
基于上面這些分析，你應(yīng)該可以算一下，你的工作集有多大，數(shù)據(jù)壓縮率有多大，那么需要把cacheSizeGB調(diào)到多小才能容納下工作集（又或者調(diào)到多小都不可能容納下工作集）。你的情況是內(nèi)存不足CPU空閑，所以如果懶得算，直接把cacheSizeGB調(diào)到最小值就好了。

疑問(wèn)2: config只用了1.5GB內(nèi)存(限制了CacheSizeGB3GB).可以說(shuō)明索引都加載到了內(nèi)存中嗎?

這說(shuō)明config數(shù)據(jù)庫(kù)（元數(shù)據(jù)）的索引和數(shù)據(jù)都加載到內(nèi)存中了。注意數(shù)據(jù)的索引肯定是在shard中，與config無(wú)關(guān)。而且大頭是在shard上面。
順便提一下，如果不是實(shí)驗(yàn)?zāi)康?，根本沒(méi)必要分這么多片。因?yàn)樵谝慌_(tái)機(jī)器上分再多片，硬件資源也只有這么多，對(duì)于性能沒(méi)有什么意義，反而還會(huì)有額外的傳輸開(kāi)銷。

疑問(wèn)3: mongodb remove數(shù)據(jù)后,查詢卻越來(lái)越慢是什么情況?

remove之后跟查詢沒(méi)有本質(zhì)上的聯(lián)系，可能只是湊巧發(fā)生在一起。如果你有足夠的證據(jù)覺(jué)得這兩者確實(shí)有聯(lián)系，請(qǐng)另開(kāi)問(wèn)題描述清楚問(wèn)題的上下文以及你發(fā)現(xiàn)的情況，必要的時(shí)候也可以求助于MongoDB JIRA。如果一定要做一個(gè)無(wú)根據(jù)的猜測(cè)，我覺(jué)得可能是remove時(shí)導(dǎo)致熱數(shù)據(jù)被換出內(nèi)存（注意remove也需要先找到滿足條件的數(shù)據(jù)然后才能刪除），引起后面的查詢需要重新從磁盤上加載數(shù)據(jù)造成的。

1.數(shù)據(jù)庫(kù)字段類型約束 選用無(wú)符號(hào)類型

2.程序代碼去約束

3.錄入價(jià)格的時(shí)候效驗(yàn)

其實(shí)這個(gè)問(wèn)題可以看成是數(shù)學(xué)上集合的的問(wèn)題
你的這個(gè)sql：

select * from user where name = 'A' or sex = '1' 

可以等價(jià)成下面這個(gè)sql

select * from user where name = 'A' AND sex = 1 
UNION ALL
SELECT * FROM user WHERE name = 'A' AND sex != 1
UNION ALL
SELECT * FROM user WHERE name != 'A' AND sex = 1

拆解成三部分,可以自由調(diào)整顯示順序
謝謝。

把SQL貼出來(lái)。

先看看update時(shí)有沒(méi)有deadlock異常，再看下事物，多少條commit一次，再用show processlist等操作看看數(shù)據(jù)庫(kù)執(zhí)行的sql狀況。

select * from t2 LEFT JOIN t1 ON t2. m_top_user_list like '%t1. user_id%'

找到問(wèn)題，每種編程語(yǔ)言都有規(guī)定字長(zhǎng)。jsdouble類型字長(zhǎng)超過(guò)15位之后的數(shù)值都不顯示歸零。

目錄放一張表就行了
id name bookid acticleid pid
一級(jí)目錄pid為0 二級(jí)目錄pid為一級(jí)目錄的id

另外mysql字段類型占用大小
https://dev.mysql.com/doc/ref...
直接看看文檔吧

如果字段都是一樣的話，可以考慮把多個(gè)結(jié)果集用union連起來(lái)，然后再排序

我在微信群里也回答你了，先查一下Keepalive。參考這個(gè)Q&A：https://docs.mongodb.com/manu...

點(diǎn)最后一個(gè)按鈕

用

set names utf8

設(shè)置一下編碼試試

--testtable

delimiter //
create trigger insertTrigger before insert on testtable
for each row set new.w = new.a + new.b + new.c + new.d;
//

create trigger updateTrigger before update on testtable
for each row set new.w = new.a + new.b + new.c + new.d;
//

delimiter ;

一般來(lái)說(shuō)就是把前后端解耦，前端一套可以部署到靜態(tài)服務(wù)器獨(dú)立跑，需要數(shù)據(jù)時(shí)再AJAX訪問(wèn)后端提供的相應(yīng)接口拿東西。

你說(shuō)的這種，還是以實(shí)際業(yè)務(wù)需求（產(chǎn)品人員）為準(zhǔn)吧。需求不一樣，做法不一樣。

第一種的bug就是所有消息都標(biāo)記已讀（可能會(huì)出現(xiàn)未看到的消息也標(biāo)記，但性能會(huì)更優(yōu)）
第二種，無(wú)第一種bug，但性能會(huì)稍有影響。

決定權(quán)由需求方?jīng)Q定。你是簡(jiǎn)單問(wèn)題復(fù)雜化了。

以上方法不考慮其他方案解決性能問(wèn)題（如nosql等）

提供一個(gè)思路好了，用正則表達(dá)式，你可以試試如下的代碼：

SELECT
    *
FROM
    CLASS_TEST
WHERE
    CONTENT REGEXP  '>[^<]*class[^>]*<'
;

具體意思就是，CONTENT的內(nèi)容需要包含一個(gè)>和<當(dāng)中有class，且當(dāng)中不能有其他標(biāo)簽。
可以看看教程，剛開(kāi)始看有些云里霧里，熟練之后就好了。

希望能幫助到你。