主鍵選擇我有大約650排，5 MB數據長度，60 KB的索引長度MEMORY表（因此它是相當小的）。它有一個SMALLINT主鍵（散列）和大約90個其他列（整數，變量，日期時間，無斑點或文本）。 （編輯：這裏還有一個BIGINT列的哈希鍵）。簡單恆定在小MEMORY表很慢
我運行此查詢（從PHP）經常（每秒約10次）：
SELECT * FROM userek其中id = {} CONST_ID和kitiltva = 0和 kitiltva_meddig < 「{} CONST_DATETIME」 和inaktiv = 0
注：id是主鍵。我需要*，因爲結果被用在很多不同的地方，基本上所有的列都在這裏或那裏使用。
我的問題是：查詢得到異常緩慢的定期。關於0.5s平均來說，8s最大。大部分時間都非常快：75%的運行速度比3ms，85%的運行速度要快。但15%它比平均速度慢，13%慢於1s。所以它有一個長尾巴。
而且我也絕對不知道什麼可能導致它。任何想法的人？
對不起，回答我的問題，但至少我有一個答案。我試圖以對其他人有幫助的方式編寫它。
因爲它是一個MEMORY表，我排除了I/O問題。
接下來，查詢是一個簡單的（常數）由主密鑰選擇，所以它不能成爲一個索引問題無論是。
下一個猜測是鎖定。在我的應用程序中有/很慢的選擇在這張桌子上。這可能是一個問題：慢選擇延遲更新，延遲其他選擇，所以最終這個非常簡單和快速的選擇可以被延遲。
我檢查了slow query log，發現用這種特殊的表（和其他人一樣）有兩個常見的和緩慢的選擇。原因是一個嚴重的加入形成對案件：中
A left join B on case
when A.x=1 then B.id=A.id2
when A.x=2 then B.id=A.id3
else B.id=0
end
代替
A left join B on B.id = case
when A.x=1 then A.id2
when A.x=2 then A.id3
else 0
end
均可以得到相同的結果，但後者可以使用B.id的指數，前者不能。
一旦我糾正這些查詢的原查詢的性能大大增強：5ms，而不是500ms平均。和98%快於平均水平。
寓意：
slow query log，分析它，並提高查詢速度慢
表中沒有其他索引，PK除外？ –
哦，在BIGINT列上還有另一個散列索引。而已。 – Cucu
'（id，kitiltva，inaktiv，kitiltva_meddig）'上的BTREE索引將是最適合此查詢的。但是我沒有使用MEMORY表，所以如果這個（添加索引）適合做這種情況，那麼有更多經驗的人可能會建議。 –