咦? 你圖中的示例 不也是 執(zhí)行不同的函數(shù)返回不同的session 嗎 ? flask 里的 sqlalchemy 和 python自己安裝的sqlalchemy 不是一樣的嗎..?

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

select * from test1 where find_in_set(id,(select ids_str from test2));

SELECT Child.user_id, Child.Lft, Child.Rgt,Child.Level
            FROM kt_relation as Child, kt_relation as Parent
                WHERE
                  Child.Level = 3+1
                  -- AND Child.Lft+Child.Rgt <= Parent.Lft +Parent.Rgt   -- 左區(qū)
                                    
                                    AND Child.Lft+Child.Rgt > Parent.Lft +Parent.Rgt    -- 右區(qū)
                  
                                    AND Parent.user_id = 10001
                                    
                                    AND Child.Lft+Child.Rgt <= 12 +25

搞出來(lái)了一個(gè)sql語(yǔ)句，可以實(shí)現(xiàn)。前提是確認(rèn)這個(gè)節(jié)點(diǎn)是最頂層節(jié)點(diǎn)10001的哪個(gè)區(qū)域，然后查10001的右區(qū)，再加個(gè)條件，查詢10003的左區(qū)，12+25就能代表10003了。
這種自連接，搞的我有點(diǎn)暈乎！速度還可以，可能是有索引的原因。
php里面就是，先取得待查的節(jié)點(diǎn)10003的記錄，取出他的，左右值。
然后計(jì)算出，應(yīng)該查以根節(jié)點(diǎn)開始的哪層。比如這個(gè)10003，要查他開始的第3層，那實(shí)際查的應(yīng)該是，10001的第4層。因?yàn)?0003與10001差1層。所以是，3+1層。什么亂七八糟的。

搞出來(lái)個(gè)簡(jiǎn)單的，先查出這個(gè)節(jié)點(diǎn)的所有子孫節(jié)點(diǎn)，加條件，和值小于自身，再限定定層。就出來(lái)了。
SELECT * FROM Tree WHERE Lft > 1 AND Lft < 26 AND Lft + Rgt <= 1 + 26 AND Level = 4

為什么，我把問(wèn)題寫出來(lái)，然后不久，自己就解決了問(wèn)題，好怪。不寫就整不出來(lái)。其實(shí)我就是個(gè)菜b

已經(jīng)有人問(wèn)過(guò)了：mongodb分組查詢，取各班第1名

1. 將checkbox的value賦值為 permission_id
2. 監(jiān)控checkbox的check動(dòng)作，一旦點(diǎn)按 修改value，在原理persission_id基礎(chǔ)上，添加1（表示checked）或0， 最終格式形如 <input value="23-1"....>
3. 服務(wù)端拿到value值后，若發(fā)現(xiàn)其中含有-說(shuō)明這個(gè)值發(fā)生了變化，變化的結(jié)果是后面跟著的1或者0.

哇 中文表名 ，第一次見(jiàn)

數(shù)據(jù)庫(kù)里面用事務(wù)和鎖來(lái)防止重復(fù)就行

其他的方法也可以，比如設(shè)置一個(gè)請(qǐng)求隊(duì)列，先進(jìn)先出，這樣就可以按照順序發(fā)馬甲了

InnoDB是Inno Database的縮寫。

Innobase Oy是芬蘭的一家公司，InnoDB其實(shí)就是以公司名命名的了。

1。為什么不能使用默認(rèn)id
2。如果自定義id，那么默認(rèn)id也會(huì)自動(dòng)生成
3。要使用自定義id查詢，就用自定義的字段名稱就好，默認(rèn)id當(dāng)然同樣是可以繼續(xù)使用的

1. 檢查密碼中是不是有特殊符號(hào)，比如@，:之類的
2. 從堆棧中看用的是SCRAM-SHA-1認(rèn)證，檢查一下你的賬號(hào)是不是MONGODB-CR：

use admin
db.system.users.find()

題主可以逆向思考這個(gè)秒殺問(wèn)題，由于Redis的list數(shù)據(jù)結(jié)構(gòu)是不可能到達(dá)“負(fù)”長(zhǎng)度的，所以可以把需要被秒殺的商品信息和一個(gè)唯一編號(hào)預(yù)先放到指定商品類型的唯一隊(duì)列中，用戶請(qǐng)求時(shí)直接lpop出結(jié)果，不可能出現(xiàn)超量的問(wèn)題，很多東西都免了。

如果能給些測(cè)試條件別人會(huì)更容易理解你的問(wèn)題。
首先說(shuō)$eq，這個(gè)運(yùn)算符大部分時(shí)候沒(méi)有必要寫。所以你的查詢等價(jià)于：

db.SEC_2018_05_12.aggregate([
    { $match : { fyear : 2018, fmonth: 5, fday: 12, fhour: 17, fmin: 8 } }, 
    { $group: { _id: {dev_id: "$dev_id", data_id: "$data_id"}, maxTimeValue: { $max: "$fdate" } } }  ]).pretty()

然后你的要求是取到第一條數(shù)據(jù)，而不僅僅是最大那個(gè)fdate值?？梢該Q個(gè)思路來(lái)理解這個(gè)問(wèn)題：

按dev_id asc, data_id asc, fdate desc三者來(lái)排序，然后取每個(gè)分組的第一條數(shù)據(jù)

按照這個(gè)思路，查詢應(yīng)該是：

db.SEC_2018_05_12.aggregate([
    { $match : { fyear : 2018, fmonth: 5, fday: 12, fhour: 17, fmin: 8 } }, 
    { $sort: { dev_id: 1, data_id: 1, fdate: -1} },
    { $group: { _id: {dev_id: "$dev_id", data_id: "$data_id"}, maxDoc: { $first: "$$ROOT" } } }  ]).pretty()

最后說(shuō)說(shuō)數(shù)據(jù)模型設(shè)計(jì)的問(wèn)題。$match這里其實(shí)就是一個(gè)時(shí)間，但是被你拆成了很多部分來(lái)存儲(chǔ)。除非有明確的理由支持，個(gè)人并不是十分贊成這樣的做法。

1. 本來(lái)一個(gè)時(shí)間只有4 bytes，你這么一來(lái)變成了5 x 4 = 20 bytes，注意存儲(chǔ)空間；
2. $match/$sort需要索引的支持，所以原來(lái)一個(gè)索引現(xiàn)在將會(huì)變成5個(gè)字段的聯(lián)合索引，同樣是浪費(fèi)空間和效率；

在數(shù)據(jù)量大的情況下，上面的查詢是需要索引支持的。換你現(xiàn)在的寫法，索引應(yīng)該是：

{
  fyear: 1,
  fmonth: 1,
  fday: 1,
  fhour: 1,
  fmin: 1,
  dev_id: 1,
  data_id: 1,
  fdate: -1
}

看上去就夠驚悚了不是嗎？但其實(shí)前面那一堆時(shí)間本身只是一個(gè)時(shí)間而已。

name是主鍵？？？？

不推薦存數(shù)據(jù)庫(kù)中，假如站點(diǎn)訪問(wèn)量大的時(shí)候，對(duì)數(shù)據(jù)庫(kù)會(huì)頻繁寫入,頻繁讀取，從而影響數(shù)據(jù)庫(kù)性能。一般用redis memcache存更好些。而且維護(hù)過(guò)期時(shí)間等也方便。設(shè)置key過(guò)期時(shí)間就好。

不建議在數(shù)據(jù)庫(kù)端運(yùn)行這樣的邏輯。并且，這跟在NodeJS端定義一個(gè)這樣的函數(shù)也沒(méi)有什么區(qū)別，為什么一定要放到MongoDB里面？
描述一下具體的使用場(chǎng)景可能有助于我們分析問(wèn)題。

用 Column 對(duì)象 的 in_ 方法。
filter需要傳遞的參數(shù)為表達(dá)式，此處剛好。
filter_by需要傳遞關(guān)鍵字參數(shù)，所以此處in_沒(méi)法使用。

in_在OOP和非OOP兩種模式中的使用-demo:

# 通用
from sqlalchemy import (
    create_engine,
    Column,
    Integer,
    String
)

# oop方式所需
from sqlalchemy.orm import sessionmaker
from sqlalchemy.ext.declarative import declarative_base

# 非oop方式所需
from sqlalchemy import (
    Table,
    MetaData,
)
from sqlalchemy.sql import func


Base = declarative_base()

class Table1(Base):
    __tablename__ = 'table1'

    id = Column(Integer, primary_key=True, autoincrement=True)
    name = Column(String(55))

    def __init__(self, name):
        super(Table1, self).__init__()
        self.id = None
        self.name = name

    def __repr__(self):
        return '<Table1 {0}>'.format(self.id if not self.id is None else '')

uri = 'sqlite:///:memory:'
engine = create_engine(uri)
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine, autocommit=False)

############# 添加對(duì)象, 填充測(cè)試數(shù)據(jù)
session = Session()
for name in 'zhang,wang,li,gong,chen,zhao'.split(','):
    obj = Table1(name)
    session.add(obj)
session.commit()

lst_filter = ['wang', 'li', 'zhao']
############# OOP方式查詢
# 查詢總數(shù)
Q = session.query(Table1)
print(Q.count())
# 篩選
Q = Q.filter(Table1.name.in_(lst_filter))
result = Q.all()
print(result)
session.close()

############# 非OOP方式查詢
metadata = MetaData(bind=engine)
table = Table('table1', metadata, autoload=True)

# 查詢總數(shù)
stmt = func.count(table).select()
print(stmt.execute().fetchone())
# 篩選
stmt = table.select().where(table.c.name.in_(lst_filter))
rp = stmt.execute()
result = rp.fetchall()
# print(result)
print(len(result))

engine.dispose()

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

6
[<Table1 2>, <Table1 3>, <Table1 6>]
(6,)
3

參考:

• in_

  Implement the in operator.
  In a column context, produces the clause a IN other. “other” may be a tuple/list of column expressions, or a select() construct.

• filter

  apply the given filtering criterion to a copy of this Query, using SQL expressions.

• filter_by

  apply the given filtering criterion to a copy of this Query, using keyword expressions.

原因

$lookup 首先進(jìn)行的是左外連接查詢。 當(dāng)匹配到多個(gè)滿足外鍵條件的記錄時(shí)，會(huì)放到數(shù)組子集合里。 再之后你的match2,match3,match4,match5針對(duì)子集合查詢。 而mongo這里的子集合匹配，只要子集合中有一條滿足，就會(huì)全部整條記錄滿足。

解決方法

1. 如果是mongodb V3.2、V3.4版本的$lookup提供的解決方案是先$unwind一下。
2. 如果是mongodb V3.6及以上的版本，$lookup提供了pipeline字段。具體參考$lookup官方文檔

你說(shuō)的這個(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的多主。

如果有富文本的話，可以用html、uub、markdown等格式用文本編碼，保存在數(shù)據(jù)庫(kù)的TEXT(即CLOB)類型的屬性里。
文章中有圖片、視頻的話，可以在上述文本中嵌入圖片鏈接，設(shè)計(jì)另一張表去管理這些鏈接。